Hace un año, te contábamos que, pese a ser aún un desconocido entre muchos usuarios (hoy en día cuenta con tan sólo 10 años de historia a sus espaldas), el lenguaje de programación Rust, era el más querido por los programadores, y se posicionaba como un candidato a sustituir C/C++ gracias a su gestión mejorada de memoria. Más recientemente, supimos que Mozilla iniciaba una nueva etapa con una reestructuración de su brazo comercial que dejaría en la calle a 250 empleados.
Comentarios
Yo si fuera la fundación pediría un patrocinio a Burgos, y sería Mozilla de Burgos.
#2 pues sí, y el firefox comiendo morzilla.
#4 No hacía falta explicar el chiste...
#2 ¿Y si se lo piden a Gnutella?
#8 Muy fino, muy fino...
#17 Cuestión de usar bien el cuchillo con el pan.
#2 caballero, su positivo
#2 Con cebolla.
#2 positivo, aunque la única morcilla auténtica es la de Matachana (aka morcilla de León)
#2 Sútil, muy sútil. Bravo.
#2 la otra opción es pedir la subvención a Nutrexpa
Me he leído todos los comentarios destacados de ese hilo y no se de donde sacas esas conclusiones de que lo ponen a caldo más allá de que yo dominio C++ y no necesito Rust.
¡Con casinos! !Y furcias!
#1 Ya estaban preparando la fundación desde al menos principios de año o pasados del anterior. Todo el rollo se ha precipitado con lo del coronavirus y la falta de ingresos por sus nuevos servicios (VPN y demás).
Rust tiene muy buena salud y mucho futuro y esto servirá para garantizar puestos de trabajo de los desarrolladores del lenguaje y ecosistema y hacerlo más independiente de los vaivenes financieros de mozilla.
#25 #24 Es el eterno problema: si no ofreces una API estable, vas a andar rompiendo miles de extensiones cada vez que saques una versión nueva (baste ver lo que pasa con Gnome Shell... y hablo por experiencia porque mantengo un par de extensiones). Pero con una API estable una de dos: o es tan extensa que te permite hacer de todo, pero a costa de atarte a la hora de cambiar cosas internas, o es lo suficientemente limitada como para darte libertad para cambiar lo que quieras internamente, pero a costa de no dejarte hacer muchas cosas "interesantes" en extensiones. Firefox en origen ofreció una API estable y muy extensa, lo que, a la larga, limitaba a los programadores tanto que, prácticamente, estancó el desarrollo del navegador.
En otras palabras, puedes tener:
- API externa estable
- API externa extensa
- Desarrollo del producto rápido y ágil
pero sólo puedes escoger un máximo de dos opciones, nunca las tres. En origen Mozilla escogió las dos primeras, pero para poder competir con Chrome tuvo que cambiar a la primera y la tercera.
#24 #28 Firefox ESR mantiene la compatibilidad con todo durante aproximadamente un año. A quien le interese mantener una extensión y no andarse con cambios cada poco tiempo debería probar con esta versión.
Por ejemplo, Foxscape era un tema chulísimo que te daba la total apariencia del Netscape 4.x, pero hace unos años dejó de dar soporte precisamente por tantos cambios entre versiones (y de no ser por eso aún seguiría usándolo, una pena). Seguramente también les habría afectado el webextensions ese. Si se amoldasen solamente a las versiones ESR ese problema quizá hubiese sido mucho más llevadero.
Aquí se puede ver, entre otras, una captura del Foxscape: https://www.giz.ro/internet/teme-pentru-firefox-cele-mai-bune-teme-pentru-firefox-13745/
#27 - Mozilla se bajó los pantalones cuando aún era relevante y tragó con la estandarización del DRM para la web, convirtiendo a Mozilla ahora y siempre en un navegador peor para multimedia.
¿O sea, que preferirías que no existiese un estandar abierto de DRM y que para ver Netflix y similares tuviesemos que usar un plugin Flash en 2020?
#35 Sí.
Al menos en ese caso todos los navegadores estarían en igualdad de condiciones. Mozilla a día de hoy no puede implementar de ninguna manera EME a su nivel más estricto. Lo que le hace el navegador objetivamente inferior para ver Amazon Prime Video y similares.
Mozilla la cagó pensando que EME le permitiría ser más relevante, en realidad le hizo incluso más irrelevante.
#35 Pues si te soy sincero, no me gusta nada un estándar como EME donde solo hay dos proveedores (Google y Apple), y no es accesible más que para algunos navegadores (los grandes):
https://boingboing.net/2020/01/08/rip-open-web-platform.html
Hay estándares que son malignos por definición: para tener el control de la industria (tan complejos que no se pueden implementar más que por las empresas más grandes), y que no permiten otras alternativas (ya está el estándar).
Te invito a que eches un vistazo al link anterior
#18 Ese era el del mes pasado. A ver cuál toca en diciembre.
#21 RustScript
#18 No, go tiene recolector de basura y no es adecuado para sustituir a C.
#21
Y así es como un lenguaje prometedor se ve en apuros...
Que pena.
Rust es el legítimo heredero del lenguaje C y una de las mejores cosas que han pasado en el mundo de la informática en los últimos años.
#7 ¿Ese no era Go?
#7 Yo creo que hay tantos programadores convencidos con Rust que es imposible que caiga. No sé si ralentizará algo su evolucion, tal vez era Mozilla quien ralentizada a rust. Sin embargo, en sus inicios Mozilla fue muy importante para Rust y puede hoy no lo tuviesemos sin Mozilla.
Ahora seguro que puede emanciparse sin problemas.
Alguno puede contar las virtudes y la pegas que le encuentra a Rust.
#55 Golang al menos no pretende ser un sustituto de otros y está encontrando su nicho, ya hay un montón de aplicaciones en uso en la vida real que usan Go. Rust no conozco ninguna. La verdad es que me recuerda al hype que hubo con haskell hace unos años.
#58 Exacto, justo el otro día le estaba comentando acerca de Haskell a un compañero de trabajo para compararlo con Rust en este sentido.
Con Rust lo único que veo es a un montón de frikis asegurar que Rust es la polla, que Rust es superseguro, que Rust es lo mejor que hay, que Rust es el futuro... y a la hora de la verdad cuando entras a buscar crates para cualquier tontería sólo ves morralla hecha por aficionados, la mayor parte de ella abandonada y que claramente no cumple unas mínimas expectativas. Después te vas a Go y ves montones de proyectos sólidos, librerías cojonudas... Evidentemente queda más que claro qué lenguaje se está usando en el Mundo Real y qué lenguaje no.
Además de que Rust, por más que se empecinen, no es un sustituto de C, sino que más bien lo que pretendían es que fuera un sustituto de C++. Y desde luego no lo están consiguiendo.
C++20 no tiene rival.
Se siente.
#9
Ah, y ojalá en Moñéame hubiera hilos como éste donde se pone a Rust a caldo: https://developers.slashdot.org/story/19/04/21/2049259/why-modern-c-still-isnt-as-safe-as-memory-safe-languages-like-rust-and-swift
Las modas son pasajeras.
#10 sí, por eso ya se puede escribir módulos del kernel de Linux en rust y no en C++ y Google acaba de sacar un invento para poder reemplazar poco a poco partes de Chrome en Rust.
Ese hilo que pones es de hace más de un año. Totalmente obsoleto en el mundo Rust.
#11 y Microsoft también le está poniendo ojitos a Rust, como solución a la mayoría de bugs de gestión de memoria de sus productos.
Estaría interesante conocer el coste real de usar C/C++ teniendo en cuenta estas cosas, parece que a ellos no les compensa.
Una pena que salga de la Fundación Mozilla, pero seguro que pretendientes y sponsors no le van a faltar a la nueva fundación. Además, puede que sea hasta beneficioso para el futuro del lenguaje a medio-largo plazo (mira a Python, que no depende directamente de ninguna compañía; o incluso los propios C/C++).
#11
No, no se puede escribir módulos de Linux en Rust (lo de kernel de Linux no sé a qué viene, Linux es un kernel, no existe eso de kernel de Linux).
Linus Torvalds ha permitido testear Rust y ver cómo se comporta. Pero eso no significa que haya sido aceptado ni que se vaya a usar.
Así que guárdate el fanboyismo de Rust y la bilis en contra de C++.
De obsoleto nada, es un hilo plenamente vigente, porque los motivos esgrimidos a favor y en contra siguen siendo exactamente los mismos. En todo caso lo que se puede quedar obsoleto son las críticas a C++, cuyo estándar está en constante evolución. Y digo estándar, no un lenguaje que pertenece a una compañía o fundación.
Rust intenta ser el heredero del lenguaje C++. El heredero de C es Go.
#14 bueno un poco cogido con pinzas. Go es una cosa que ya veremos en su momento como se trata.
Una cosa que hace binarios de 50MB nunca puede ser substituto de C.
#22 #33 https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
Y nada más que añadir.
#14 Una de las principales no características de C es que no posee recolector de memoria. Go lo tiene, no lo veo sustituyendo a C.
#33 Osea que el sustituo de C no puede tener cosas que C no tenga?
#46 Exacto, pero no que no tenga, sino que no pueda. Si quieres reemplazar a C, primero debes alcanzarle.
#33 Correcto: Go es para la programación de sistemas o de servidores web. Rust es para programar a bajo nivel: Kernels, drivers, sistemas embebidos, etc.
#14 A diferencia de Rust, Go no lo usa ni el Tato.
#52 Qué poquita idea tienes, ¿no? En realidad es justo al revés: los desarrolladores de sistemas modernos están apostando por Go y Rust no deja de ser el eterno hype que a la hora de la verdad no gasta ni Cristo y encima tiene un ecosistema que es mitad abandonware y mitad mierda de cuatro frikis probando el lenguaje.
Rust no es nada hoy en día, mientras que Go ya tiene proyectos importantísimos como Docker, Kubernetes, Terraform...
#52 Está por encima de Rust en Tiobe. Y subiendo del 20 al 11 en un año
https://www.tiobe.com/tiobe-index/
#29 Ese es un tema diferente. No conozco la API así que ahí no puedo opinar, pero sí puedo entender perfectamente los motivos que tuvo Mozilla para cambiar. De hecho, recomiendo leer el artículo que enlazo. Créeme, como programador, se perfectamente de lo que hablan.
También es cierto que no sería mala idea ampliar la API, aunque ello suponga que haya extensiones "Only for Firefox". Pero también es cierto que, quizás, sería mejor establecer un estándar para extensiones dentro del propio W3C, de manera que se amplíe igual que se hace con HTML5.
#48 joder, negativo por error. Perdón, iba a poner positivo.
#54 Bah, sin problema, un par de positivos en algún comentario mío y como si nada
Que manía con sustituir cosas.... cada uno ira por su camino.
Ya se ha tocado techo en tecnología (al menos a nivel de usuario) y salvo errores todo que existe es plenamente valido
#15 "Ya se ha tocado techo en tecnología (al menos a nivel de usuario)"
Que quieres decir?
#47 que sigo usando un ordenador de hace 10 años para tareas de usuario común y casi los mismos programas
#61 Que me quieres decir? Has citado el comentario correcto?
La tendencia monopolista del sistema capitalista neoliberal acabará con las empresas más pequeñas que acabarán siendo fagocitadas por las grandes, que en el fondo comparten dueños a través de entidades diseñadas para imposibilitar su rastreo, y estas 'crisis' son aprovechadas y alimentadas precisamente para facilitar este proceso, como ya explicó Marx.
Y qué pasa con D?
Lo ha hecho la propia fundación mozilla. Eso fortalece el lenguaje al garantizar que va a seguir vivo pase lo que pase.
Si, Mozilla cobra 450M $ al año de Google menos impuestos, no son tanto para una empresa como Mozilla,y aunque tampoco veo exactamente donde están todos los gastos, si veo que gran parte de su "workforce" estaba en Estados Unidos entonces, si pusieramos una media de 140.000$/año (Visto en Glassdoor) por los 1000 empleados que tenían, ahora son 750 o así, esto solo sería 140M$/año (Probablemente más). Pero luego tenemos que pensar en contratos externos, oficinas, perks de empleados... Y luego en tiempos de pandemia tienes que tener un buen buffer de dinero ahorrado... porque además Google es el 90% o así de sus beneficios, si Firefox baja demasiado su cuota de Mercado, Google puede bajar el contrato (tendrán que seguir pagando para que no se les acuse de Monopolio, pero las cifras pueden bajar)...
Hora de cortar la grasa Mozilla.
No es posible que tengan un producto tan mediocre (durante años, mejorando solo recientemente) con tanta gente empleada.
#5 Precisamente acabo de terminar de leer un artículo que explica por qué era tan "mediocre": básicamente, la manera de escribir extensiones para Firefox implicaba que el código de la extensión podía tocar cualquier parte del código de Firefox. Aunque en origen parecía buena idea, pues daba una potencia y versatilidad tremenda a las extensiones, con el tiempo se encontraron con que si no querían "romper" cientos de extensiones cada vez que sacaban una versión nueva de Firefox, tenían que andar con mucho cuidado a la hora de hacer cambios internos, y eso era tiempo de desarrollo "perdido".
Afortunadamente, cuando añadieron soporte de WebExtensions pudieron romper con eso, y ya pueden tocar todo lo que quieran dentro del código sin riesgo de romper nada. Por eso hoy en día va mucho más rápido el desarrollo.
El artículo: https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/
#20 Que curioso, Yo, el día que se cargaron las extensiones, que tenía algunas muy buenas y muy útiles, dejó de tener utilidad para mi. Que era más rápido? si, claro, como a un acorazado al que lo hacen más rápido a base de quitarle todo el armamento y el blindaje.
No, para mi, en mi opinión, es al revés. A la gente dejó de interesarle cuando dejó de ser customizable a tope. A los que les basta con el básico, ya tenían mucho mejor el chrome.
#20 La contrapartida es que mozilla mató el ecosit de extensiones (múltiples veces) sin ofrecer nada que lo reemplazarse. Además Mozilla "de serie" ya era lento comparado con Chrome durante años.
De un desarrollador de una extensión muy popular:
https://www.downthemall.org/re-downthemall-and-webextensions-or-why-why-i-am-done-with-mozilla/
#20 Si no fuese que la API es una mierda, basada en la de Chrome (por mucho que Mozilla diga que no) y super-limitada en funciones. Todas las extensiones de descarga o para gestionar descargas se las han cargado, porqué la API de descargas de Chrome limita la descarga a una sola carpeta (supuestamente por seguridad, yo tengo mis dudas de eso). Y ver locuras como ya vi de extensiones que te permiten descargar por lotes, en teoría, pero que te abran cien cuadros de diálogo para guardar el archivo, eso es inviable totalmente.
Saludos.
#5 Es una comparación injusta. Mozilla es una organización pequeña mientras que Google es un gigante tecnológico. La mayor parte de la financiación de Mozilla es la calderilla que le suelta Google todo los años.
De todas formas, aunque Firefox sea un poco más lento que Chrome y no soporta todas las tecnologías (altamente experimentales) que Chrome sí, no es tan malo:
-Es un navegador centrado en la privacidad, incluso si no es perfecto en ese aspecto es muchísimo mejor que Chrome
-Chrome capa APIs de extensiones antipublicidad (y, por extensión, anti-espias y noscript), Mozilla no.
https://www.xda-developers.com/google-chrome-manifest-v3-ad-blocker-extension-api/
-Chrome se ha aprovechado de su posición dominante para cambiar el comportamiento de tecnologias asentadas, rompiendo webs, o utilizando tecnologias no estandarizadas que solo Chrome en youtube y similares, perjudicando a los otros navegadores.
Aunque preferiría que se olvidasen de servicios no relacionados (como su VPN de pago) y se centrasen exclusivamente en el navegador, esos servicios tienen el objetivo de financiar Mozilla y ofrecer servicios como Opera.
#23
- Mozilla corp ha violado la confianza y privacidad del usuario en múltiples ocasiones. Lo sigue haciendo vía sus "servicios añadidos" que, al menos, parecen opcionales.
- Mozilla se bajó los pantalones cuando aún era relevante y tragó con la estandarización del DRM para la web, convirtiendo a Mozilla ahora y siempre en un navegador peor para multimedia.
Mozilla no es un angelito, aunque Google fuese peor.
#5 ¿Un producto mediocre? son los únicos aparte de google y apple que son capaces de mantener un navegador completo (que hoy en día es casi como un sistema operativo completo). Los demás han tenido que tirar del trabajo de la propia google para poder sobrevivir y están atados a ella... los demás si tienen un producto mediocre, que no aporta nada al resto.
#41 se han esforzado, pero es un producto mediocre, mejorando pero mediocre. Toda la pasta y personal tirado a la basura en sandeces varias como Firefox OS podrían haber sido usados en su producto base, Firefox. Además de abandonar proyectos que mejorarían su producto base (hola Servo!)
Y quizás deberías preguntarte por qué nadie se plantea o ha planteado usar el motor de Mozilla para sus navegadores y librerías. Opera, Brave, Vivaldi, Edge, Qt... Todos parasitando Chrome, por qué no Mozilla?
#44 "Y quizás deberías preguntarte por qué nadie se plantea o ha planteado usar el motor de Mozilla para sus navegadores y librerías."
No se ha planteado no porque sea mediocre, sino porque no es el mejor, chromium es el mejor por varias razones, así que todo dios usa el mejor, no el segundo mejor.
Por licencia, ambos tienen licencia libre, pero Chromium tiene licencia bsd, que para terceros es más libre (básicamente puedes hacer con el lo que quieras sin responder ante nadie).
Por uso, Chrome ya tiene el 70% (o más) de uso, firefox un 7%, así que cualquiera que se base en Chrome tiene garantizado una amplia base completamente compatible.
Por respaldo, Firefox está respaldado por una fundación sin ánimo de lucro que además depende sobre todo de donaciones, básicamente un vaso de agua en el mar del mercado digital, mientras que Chrome está respaldado por una empresa además es uno de los mayores gigantes tecnológicos y es una de sus piezas centrales.
Y en todo esto no he puesto ni una palabra de la calidad técnica de los motores. Me encanta Firefox y creo que deben existir varios motores de renderizado, pero si me ponen como responsable de decidir que motor de HTML irá en un producto, yo por responsabilidad lo tendría muy claro.
#44 Firefox OS permitió desarrollar y avanzar en muchos frentes su navegador. Sirvió para testear el uso de múltiples procesos en el renderizado, para probar algunas tecnologías de servo, para desarrollar muchas APIs que luego se incorporaron, como base tecnológica, el usar una web como aplicación fue algo que se implementó primero en Firefox OS.
No cuajó entre otras cosas porque:
1) lo lanzaron aún muy verde y sin aplicaciones, esperando que la gente usara las webs normales como aplicaciones web, 2) basarse en las herramientas de desarrollo y parte de código android aunque les daba mucho trabajo hecho, les limitaba también mucho; el hardware cerrado y el nulo interés por los pocos fabricantes que sacaron móviles firefox os tampoco facilitó tener actualizados los terminales y beneficiarse de las mejoras en el SO, que eran palpables y mejoraban mucho la experiencia
2) no tenía apoyo del software más usado (whatsapp no tenía aún versión web, nunca fructificaron las negociaciones para sacar una versión para firefoxos... recordemos que whatsapp mantenía aún la versión symbian cuando eso)
3) la apuesta era el mercado de entrada y móviles de bajo costo, pero los terminales eran cutres y caros
4) los acuerdos con grandes compañías no fueron continuados en el tiempo y se asociaron con compañías sin visión ni recursos para empujar el desarrollo del sistema.
Pecaron de ambiciosos, pero por lo demás... puedes ver firefox os como un proto chrome os.
Simplemente chrome es mucho más modular porque se desarrolló así desde el principio y es más fácil de usar sus partes por separado y como comentan por ahí, el tema de las licencias (le pasa igual que a GCC vs LLVM), de ahí que se use mucho y efusivamente (por ejemplo, v8 se usó desde el principio para el desarrollo de node.js y compañía). Mozilla diseñó servo como algo mucho más modular que gecko, pero servo es un experimento y ni tenían medios para pasarlo todo a servo, ni tenían medios para cambiarlo todo en gecko. Lo que han ido haciendo es actualizando poco a poco partes del navegador. Una transición complicada, porque a la par han tenido que ir dando soporte a todas las tecnologías del HTML5 mientras rehacían de abajo a arriba el navegador (y aún están en ello). Los resultados se van viendo poco a poco.
Por otro lado, gnome-shell usa el motor de javascript de mozilla, por citar un proyecto relevante que use partes de firefox.
Get woke...