STEM

[Benzino Napaloni]

A mí me gusta mucho la filosofía de diseño que sigue Rust por esto mismo: el compilador te obliga a hacer las cosas bien, lo cual actúa como filtro en muchos casos.

También por eso C++ es el rey de los lenguajes en su segmento de mercado, y (muy) difícilmente será desplazado por otro. Al menos no antes de mucho tiempo.

En C++ no hay más tu tía, no te queda otra que ser un programador prácticamente de primera para que no aparezcan luego fallos inexplicables.

Java en ese sentido es horroroso. Es el preferido de las cárnicas porque... con una "formación" acelerada ya se puede empezar a picar. Aunque el resultado funcione en el mejor de los casos a pedos. Kotlin ha corregido una parte de esa porquería eliminando bastante boilerplate.


Y sobre Kotlin, batallita que conozco de primera mano de cierta empresa de móviles sueca. Su nombre empieza por Eric . Un día el jefe ordenó deshacer todas las migraciones a Kotlin y volver a Java "porque los juniors no pueden con este lenguaje tan complicado". Ni un mes después habían caído unas cuantas dimisiones.

Lo habitual es invertir lo mínimo, y reaccionar sólo después de haber probado a culpar a todos los machacas y haberse comido dimisiones en masa.

[puede ser]

Pero el H2 proviene de energía renovable... (que había que almacenar para no perderla.) Y además, sólo es el primero.

Espero respuestas más elaboradas que una línea con lo primero que hayas oído por ahí.

El H2 hoy por hoy proviene del refinado del petróleo porque no hay actualmente técnicas de producción industrial que escalen de forma eficiente, con lo que la supuesta ventaja inicial ya no existe.

Además de eso, siguen sin resolverse toda la larga lista de problemas que tiene su almacenamiento y transporte. Entre otros muchos inconvenientes, el H2 tiende a corroerlo todo por su alta tendencia a reaccionar con básicamente todo. Mientras no se solucionen esos problemas a escala industrial (y se lleva años intentando), el H2 no vale.

Se ha hablado largo y tendido ya en este mismo hilo. Lo mínimo es saber lo que ya se ha hablado.

https://hidrogeno-verde.es/primera-instalacion-de-produccion-comercial-de-metanol-verde/

Maersk apuesta por convertir el hidrógeno (verde) en metanol (verde). Si sale bien seguirán en Galicia y Andalucía, como se habló.

Esto no tienen ninguna posibilidad de ser rentable. Ya estamos hablando de como mínimo tres procesos intermediarios de conversión de la energía original (petroleo -> hidrógeno -> metanol -> consumo) todos con unas pérdidas considerables por el camino. Saldrá una eficiencia parecida al coche de combustión (20-30%) pero con un proceso mucho más caro.

La idea es sacar el hidrógeno de energías renovables, e imagino que aprovechando las horas en que está es prácticamente gratis (noches con viento, tardes de fin de semana con sol...). El problema moral es que son las horas en que los usuarios normales podemos aprovechar tarifas bajas ( fines de semana...). Hay un peligro cierto de se estén privatizando beneficios y socializando gastos...

[pollo]

A mí me gusta mucho la filosofía de diseño que sigue Rust por esto mismo: el compilador te obliga a hacer las cosas bien, lo cual actúa como filtro en muchos casos.

También por eso C++ es el rey de los lenguajes en su segmento de mercado, y (muy) difícilmente será desplazado por otro. Al menos no antes de mucho tiempo.

En C++ no hay más tu tía, no te queda otra que ser un programador prácticamente de primera para que no aparezcan luego fallos inexplicables.

Java en ese sentido es horroroso. Es el preferido de las cárnicas porque... con una "formación" acelerada ya se puede empezar a picar. Aunque el resultado funcione en el mejor de los casos a pedos. Kotlin ha corregido una parte de esa porquería eliminando bastante boilerplate.


Y sobre Kotlin, batallita que conozco de primera mano de cierta empresa de móviles sueca. Su nombre empieza por Eric . Un día el jefe ordenó deshacer todas las migraciones a Kotlin y volver a Java "porque los juniors no pueden con este lenguaje tan complicado". Ni un mes después habían caído unas cuantas dimisiones.

Lo habitual es invertir lo mínimo, y reaccionar sólo después de haber probado a culpar a todos los machacas y haberse comido dimisiones en masa.

Rust va a acabar con C++ en todo nuevo desarrollo (los antiguos ya es otra historia, aunque en muchos casos se van poco a poco reescribiendo partes críticas), como denotan los movimientos de las grandes (Google, Amazon, Microsoft, etc.). Es absurdo no usarlo pudiendo hacerlo.

https://www.theregister.com/2023/04/27/microsoft_windows_rust/
https://www.businessinsider.es/amazon-facebook-gusta-lenguaje-programacion-rust-804815

El problema es que incluso aunque seas un programador de primera, aparecen fallos inexplicables que en Rust no son posibles (salvo que optes por irte al "unsafe"). El primero de estos dos artículos es imprescindible, y es la explicación a la adopción en masa de Rust por parte de las grandes para todo lo que necesita bajo nivel, complejidad y alto rendimiento:
https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-systems-programming-language/
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/


Es increíble que no se haya aplicado esto por defecto en muchos lenguajes (automatizar ciertas garantías directamente en el compilador). La gente que trabaja con él dice que si compila, es casi seguro que va a funcionar bien.

El hecho de que proporcione un mecanismo que hace imposibles las "race conditions" ya es de un valor incalculable. Conozco muchos casos (propios y de amigos y conocidos) de software interno de empresas con cuelgues inexplicables aleatorios que nadie, ni siquiera los más expertos y gurús del bajo nivel saben arreglar, y se tienen que quedar así.

El caso más llamativo fue para mí la reescritura del motor de CSS de Firefox. Los desarrolladores de Chromium (la base de Chrome) intentaron durante 3 años reescribir el motor de CSS del navegador, para que pudiese aprovechar las capacidades de concurrencia de los procesadores modernos. Tres intentos (uno por año) que fueron infructuosos, ya que en algún momento el programa se les colgaba (hacer concurrencia es notablemente difícil) y no tenían forma de razonar el porqué. Abandonaron el esfuerzo tras los fracasos y reconocer que era un problema demasiado difícil de resolver.

En cambio, la reescritura del motor de CSS de Firefox en paralelo (Stylo) se hizo en un año en Rust y funcionó a la primera, siendo de hecho el que está actualmente en uso en este navegador. Desde entonces Chromium abrió la puerta al uso de Rust en el proyecto, ya que de no hacerlo estarían limitándose.

Personalmente creo que C++ es un truño de proporciones cósmicas y que sólo se tolera porque hay mucho código escrito ya. Y sí, he usado C++ por desgracia. Hablo con conocimiento de causa.

[sudden and sharp]

Pero el H2 proviene de energía renovable... (que había que almacenar para no perderla.) Y además, sólo es el primero.

Espero respuestas más elaboradas que una línea con lo primero que hayas oído por ahí.

El H2 hoy por hoy proviene del refinado del petróleo porque no hay actualmente técnicas de producción industrial que escalen de forma eficiente, con lo que la supuesta ventaja inicial ya no existe.

Además de eso, siguen sin resolverse toda la larga lista de problemas que tiene su almacenamiento y transporte. Entre otros muchos inconvenientes, el H2 tiende a corroerlo todo por su alta tendencia a reaccionar con básicamente todo. Mientras no se solucionen esos problemas a escala industrial (y se lleva años intentando), el H2 no vale.

Se ha hablado largo y tendido ya en este mismo hilo. Lo mínimo es saber lo que ya se ha hablado.

https://hidrogeno-verde.es/primera-instalacion-de-produccion-comercial-de-metanol-verde/

Maersk apuesta por convertir el hidrógeno (verde) en metanol (verde). Si sale bien seguirán en Galicia y Andalucía, como se habló.

Esto no tienen ninguna posibilidad de ser rentable. Ya estamos hablando de como mínimo tres procesos intermediarios de conversión de la energía original (petroleo -> hidrógeno -> metanol -> consumo) todos con unas pérdidas considerables por el camino. Saldrá una eficiencia parecida al coche de combustión (20-30%) pero con un proceso mucho más caro.

Bueno, ya se verá...

Las eléctricas presentan al hidrógeno verde se presenta como una alternativa "verde". Según Iberdrola, esta tecnología se basa en la generación de hidrógeno —un combustible universal, ligero y muy reactivo— a través de un proceso químico conocido como electrólisis. Este método utiliza la corriente eléctrica para separar el hidrógeno del oxígeno que hay en el agua, por lo que, si esa electricidad se obtiene de fuentes renovables, produciremos energía sin emitir dióxido de carbono a la atmósfera. Esta manera de obtener hidrógeno verde, como apunta la AIE, ahorraría los 830 millones de toneladas anuales de CO2 que se originan cuando este gas se produce mediante combustibles fósiles. Asimismo, reemplazar todo el hidrógeno gris mundial significaría 3.000 TWh renovables adicionales al año —similar a la demanda eléctrica actual en Europa—.

¿Qué es el hidrógeno verde con el que Extremadura pretende generar empleo?
https://www.elperiodicoextremadura.com/extremadura/2023/02/09/que-es-hidrogeno-verde-extremadura-81634218.html




Extremadura producirá el 20% del hidrógeno verde del país
https://www.canalextremadura.es/noticias/extremadura/extremadura-producira-el-20-del-hidrogeno-verde-del-pais
La región pretende liderar el desarrollo de esta energía. En la hoja de ruta, la primera planta de hidrógeno verde que se va a instalar en Carmonita y que estará conectada al corredor que ha diseñado la Unión Europea

Extremadura va a ser clave para producir y mover el hidrógeno verde en España.  Una hoja de ruta que arranca con la primera planta de hidrógeno verde que se va a instalar cerca de Mérida, en Carmonita, y que estará conectada al corredor que ha diseñado la Unión Europea, el Corredor del hidrógeno H2MED. Está previsto que la primera fase que se construya en nuestro país sea la parte extremeña. 420 kilómetros que cruzarán de norte a sur la región. Se prevé su construcción en 2025 y 2026 para que comience a funcionar en 2027.

La eolica,  o la solar... también fueron un proyecto en su día.

[sudden and sharp]

Bueno, depende de a qué juegos nos refiramos. Para los triple A, la inmensa mayoría. Pero todavía queda bastante gente que intenta hacer las cosas bien, específicamente en los desarrolladores independientes o hobbistas que pueden hacer las cosas a su manera.

Personalmente, creo (por lo que he podido ver) que estas ineficiencias, a veces muy graves, vienen de una mezcla entre pereza, codicia, moda e ignorancia.

Pereza, porque gente que sabe hacer las cosas bien tira con lo mínimo porque vende igual (y total, el hardware está "sobrado"). La realidad es que no, que es muy fácil hacer que el hardware se sature, muchas veces por efectos colaterales. Por ejemplo los arrays de estructuras propiciadas por la programación orientada a objetos son mucho más lentos en memoria que las estructuras de arrays (orientación a datos), por cómo funcionan las CPU y la memoria cache.

Codicia, porque a las compañías que ponen la pasta les importa cero hacer un truño con tal de vender.

Moda, porque no se atiende a criterios técnicos sino que se siguen las "buzzword" de moda por parte de la caterva directiva, que impone tecnologías sin ton ni son porque es "lo que todo el mundo está usando". Esto es muy muy visible en el mundo web, donde auténticas montañas de mierda de interfaces de usuario en Javascript reimplementan funcionalidad que ya existe con muhca más calidad, eficiencia, accesibilidad y velocidad en el propio navegador. Esto es muy típico hoy día y sólo puede haber sido perpetrado por idiotas o ignorantes.
Hoy día hay oleadas de jóvenes que no saben hacer una web sin javascript (ni siquiera saben a nivel abstracto lo que hay por debajo), lo cual no es triste, es sobre todo muy preocupante sobre la formación que se recibe.

Ignorancia: la causa base de las tres anteriores.

Si has picado Java, te sonará algo que vi en mi primer trabajo. Dos try kilométricos anidados . Pasándose totalmente por el forro el hecho de que una excepción es muy barata de lanzar, pero carísima de capturar.

Otra que viví fue "solucionar" un problema de que el ejecutable era demasiado grande. ¿Solución? Marcar como inmutables toneladas de arrays hardcodeados que se usaban como fuente primaria de configuración.

Vamos, que como bien sabes no se trata tanto de hacer "virguerías" con el código sino de tener sentido crítico y agallas para defenderlo.


Una de las consecuencias finales es que los jefecillos que ya llevan años en esto han aprendido en la práctica que con esta forma de "funcionar" los proyectos mueren cada ciertos años por la absoluta imposibilidad de seguir manteniéndolos. No digamos ya hacer evolutivos. Con lo que sale a cuenta saltar a otro proyecto empezado desde cero.

A mí me gusta mucho la filosofía de diseño que sigue Rust por esto mismo: el compilador te obliga a hacer las cosas bien, lo cual actúa como filtro en muchos casos.

Yo me quedo con C. Llámame anacrónico.

[pollo]

Pero el H2 proviene de energía renovable... (que había que almacenar para no perderla.) Y además, sólo es el primero.

Espero respuestas más elaboradas que una línea con lo primero que hayas oído por ahí.

El H2 hoy por hoy proviene del refinado del petróleo porque no hay actualmente técnicas de producción industrial que escalen de forma eficiente, con lo que la supuesta ventaja inicial ya no existe.

Además de eso, siguen sin resolverse toda la larga lista de problemas que tiene su almacenamiento y transporte. Entre otros muchos inconvenientes, el H2 tiende a corroerlo todo por su alta tendencia a reaccionar con básicamente todo. Mientras no se solucionen esos problemas a escala industrial (y se lleva años intentando), el H2 no vale.

Se ha hablado largo y tendido ya en este mismo hilo. Lo mínimo es saber lo que ya se ha hablado.

https://hidrogeno-verde.es/primera-instalacion-de-produccion-comercial-de-metanol-verde/

Maersk apuesta por convertir el hidrógeno (verde) en metanol (verde). Si sale bien seguirán en Galicia y Andalucía, como se habló.

Esto no tienen ninguna posibilidad de ser rentable. Ya estamos hablando de como mínimo tres procesos intermediarios de conversión de la energía original (petroleo -> hidrógeno -> metanol -> consumo) todos con unas pérdidas considerables por el camino. Saldrá una eficiencia parecida al coche de combustión (20-30%) pero con un proceso mucho más caro.

Bueno, ya se verá...

Las eléctricas presentan al hidrógeno verde se presenta como una alternativa "verde". Según Iberdrola, esta tecnología se basa en la generación de hidrógeno —un combustible universal, ligero y muy reactivo— a través de un proceso químico conocido como electrólisis. Este método utiliza la corriente eléctrica para separar el hidrógeno del oxígeno que hay en el agua, por lo que, si esa electricidad se obtiene de fuentes renovables, produciremos energía sin emitir dióxido de carbono a la atmósfera. Esta manera de obtener hidrógeno verde, como apunta la AIE, ahorraría los 830 millones de toneladas anuales de CO2 que se originan cuando este gas se produce mediante combustibles fósiles. Asimismo, reemplazar todo el hidrógeno gris mundial significaría 3.000 TWh renovables adicionales al año —similar a la demanda eléctrica actual en Europa—.

¿Qué es el hidrógeno verde con el que Extremadura pretende generar empleo?
https://www.elperiodicoextremadura.com/extremadura/2023/02/09/que-es-hidrogeno-verde-extremadura-81634218.html




Extremadura producirá el 20% del hidrógeno verde del país
https://www.canalextremadura.es/noticias/extremadura/extremadura-producira-el-20-del-hidrogeno-verde-del-pais
La región pretende liderar el desarrollo de esta energía. En la hoja de ruta, la primera planta de hidrógeno verde que se va a instalar en Carmonita y que estará conectada al corredor que ha diseñado la Unión Europea

Extremadura va a ser clave para producir y mover el hidrógeno verde en España.  Una hoja de ruta que arranca con la primera planta de hidrógeno verde que se va a instalar cerca de Mérida, en Carmonita, y que estará conectada al corredor que ha diseñado la Unión Europea, el Corredor del hidrógeno H2MED. Está previsto que la primera fase que se construya en nuestro país sea la parte extremeña. 420 kilómetros que cruzarán de norte a sur la región. Se prevé su construcción en 2025 y 2026 para que comience a funcionar en 2027.

La eolica,  o la solar... también fueron un proyecto en su día.

Hay razones físicas sólidas que desaconsejan tirar por este camino, así como el bioetanol y otros sinsentidos energéticos a poco que se echen cuentas.

El hidrógeno lleva en investigación tantos años o más que las renovables, pese a que a mucha gente le suene ahora porque se habla de él, y sigue teniendo demasiados problemas sin una solución, además de que las renovables son producción (permitiendo algunas producir in-situ) y el hidrógeno sólo es transporte, que está por ver si tiene siquiera sentido cuando se produzcan en masa baterías de nueva generación.

Ya de mano el hecho de que el artículo hable de "La región pretende liderar el desarrollo de esta energía" da a entender que no sabe de qué habla y de que se oyen campanas pero sin saber dónde.

El hidrógeno no es una energía. Sólo es un sustituto de unas baterías con la idea de que haga más fácil su transporte como si fuese gasolina o butano. La energía debe producirse en otro sitio.

En el ejemplo del tren, sustituir una catenaria por hidrógeno sólo tiene sentido si no se quiere invertir en infraestructura, que a la larga siempre será más barato, a costa de hacer mucho más caros los trenes y añadirles otros problemas.

Todo esto algunos llevamos años discutiéndolo en este y otros foros, ya en la época de Burbuja.

[pollo]

Bueno, depende de a qué juegos nos refiramos. Para los triple A, la inmensa mayoría. Pero todavía queda bastante gente que intenta hacer las cosas bien, específicamente en los desarrolladores independientes o hobbistas que pueden hacer las cosas a su manera.

Personalmente, creo (por lo que he podido ver) que estas ineficiencias, a veces muy graves, vienen de una mezcla entre pereza, codicia, moda e ignorancia.

Pereza, porque gente que sabe hacer las cosas bien tira con lo mínimo porque vende igual (y total, el hardware está "sobrado"). La realidad es que no, que es muy fácil hacer que el hardware se sature, muchas veces por efectos colaterales. Por ejemplo los arrays de estructuras propiciadas por la programación orientada a objetos son mucho más lentos en memoria que las estructuras de arrays (orientación a datos), por cómo funcionan las CPU y la memoria cache.

Codicia, porque a las compañías que ponen la pasta les importa cero hacer un truño con tal de vender.

Moda, porque no se atiende a criterios técnicos sino que se siguen las "buzzword" de moda por parte de la caterva directiva, que impone tecnologías sin ton ni son porque es "lo que todo el mundo está usando". Esto es muy muy visible en el mundo web, donde auténticas montañas de mierda de interfaces de usuario en Javascript reimplementan funcionalidad que ya existe con muhca más calidad, eficiencia, accesibilidad y velocidad en el propio navegador. Esto es muy típico hoy día y sólo puede haber sido perpetrado por idiotas o ignorantes.
Hoy día hay oleadas de jóvenes que no saben hacer una web sin javascript (ni siquiera saben a nivel abstracto lo que hay por debajo), lo cual no es triste, es sobre todo muy preocupante sobre la formación que se recibe.

Ignorancia: la causa base de las tres anteriores.

Si has picado Java, te sonará algo que vi en mi primer trabajo. Dos try kilométricos anidados . Pasándose totalmente por el forro el hecho de que una excepción es muy barata de lanzar, pero carísima de capturar.

Otra que viví fue "solucionar" un problema de que el ejecutable era demasiado grande. ¿Solución? Marcar como inmutables toneladas de arrays hardcodeados que se usaban como fuente primaria de configuración.

Vamos, que como bien sabes no se trata tanto de hacer "virguerías" con el código sino de tener sentido crítico y agallas para defenderlo.


Una de las consecuencias finales es que los jefecillos que ya llevan años en esto han aprendido en la práctica que con esta forma de "funcionar" los proyectos mueren cada ciertos años por la absoluta imposibilidad de seguir manteniéndolos. No digamos ya hacer evolutivos. Con lo que sale a cuenta saltar a otro proyecto empezado desde cero.

A mí me gusta mucho la filosofía de diseño que sigue Rust por esto mismo: el compilador te obliga a hacer las cosas bien, lo cual actúa como filtro en muchos casos.

Yo me quedo con C. Llámame anacrónico.

C y C++ son los causantes de todas las vulnerabilidades que hay de bajo nivel, ya que no se usa otra cosa.

Para cosas aisladas de la red puede dar el pego, pero hoy día ninguna empresa grande (o proyecto de bajo nivel) si tiene elección va a perder la morteradísima de pasta y quebraderos de cabeza que supone el mantenimiento de C o C++ una vez hecho el desarrollo inicial.

Si se está adoptando por las grandes, e incluso Linus Torvalds lo ha admitido en el núcleo de Linux (cuando no ha admitido ninguna otra cosa hasta la fecha) es por algo.

Entre otras cosas, porque ningún programador o desarrollador es tan bueno o infalible como cree. Especialmente los que creen que lo son.

Es increíblemente ridículo y gracioso a partes iguales cómo los que predican la modernización y el avance de todo son extremadamente resistentes a una de las poquísimas innovaciones que realmente aportan algo en el mundo de los lenguajes, y que precisamente utiliza lo que siempre se anda cacareando por parte del colectivo: que un programa siempre va a ser mejor que un humano para tareas repetitivas, complejas y tediosas, como en este caso es administrar memoria y concurrencia sin cagarla inadvertidamente. Y todo esto lo consigue sin un runtime, sólo en tiempo de compilación.

En el paper de Microsoft al que alude uno de los enlaces que puse arriba (https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-systems-programming-language/) se hace mención al hecho de que no importa la colonia que crean mear los desarrolladores estrella de ninguna de las grandes: el 80% de los bugs persistentes y vulnerabilidades en todo el código son problemas de memoria y concurrencia, de forma universal en todos los proyectos.

Esto indica que los desarrolladores estrellita teóricamente infalibles que saben más que nadie cometen una cantidad de fallos inconscientes que da miedo. cosa lógica por otra parte porque es algo demasiado complejo como para que no se escape ningún detalle, especialmente teniendo en cuenta la inmensa cantidad de arcanismo y normas no escritas que tienen C y C++.

Pero claro, el ego se ve resentido admitiendo esto, y no hay nada mejor que lo que ya conozco.

[sudden and sharp]

[...] Pero claro, el ego se ve resentido admitiendo esto, y no hay nada mejor que lo que ya conozco.

Un onanista elegiría siempre Perl... por puro hedonismo. Pero claro es read-only... como rust.





El problema son los plazos (los Gantt...) pero claro, los que no tenemos prisa, seguimos con C/C++ --este último con precaución--; al estilo de GNU... el problema lo tenéis los profesionales. Los demás, no.

Pero sí, claro, si no te importa usar librería a ciegas... y hay que ganarse la vida... pues ya tienes el berenjenal de Windows. (Que si no me equivoco, yo en esto soy un aficionado, tiene a sus betatesters con un Windows _muy_ y con paquetes a la Debian. Para cada necesidad, su solución.)

[sudden and sharp]

write-only, quería decir.

[el malo]

Que sepáis que teniendo razón (que la tenéis), en el mundo de los resultados las cosas se ven de otra manera.

El técnico siempre tiende a la tecnología (o a lo nuevo, modernísimo, o a lo viejo, conocidísimo) pero muy pocas veces tiene visión comercial.

A mí que un sistema esté desarrollado en el demonizado Java (que os guste o no, funciona, y da menos quebraderos de cabeza que otras tecnologías más modernas y molonas) me parece bien mientras cumpla lo que tiene que hacer. No digo nada si nos metemos en empresas con entornos mucho más restrigidos, donde no dejan instalar nada que no lleve años en mercado por miedo a vulnerabilidades no descubiertas.

No me sirve de nada tener un Ferrari nuevo en el garaje si se pasa la mitad del tiempo en el taller. Si lo que necesito es ir de A a B todos los días, un viejo Toyota (Java) que no rompe motor me sirve más que de sobra. Si encima me lo puede mantener un desarrollador medio junior, pues miel sobre hojuelas.

Vosotros mejor que nadie sabéis que ahí fuera no son todo Metas y Googles, lo gordo de la informática son los millones de sistemas que hacen que la rueda siga girando (cuántos SAP de más de 20 años hay todavía por el mundo llevando las fábricas de muchas empresas del Fortune 500).

Que las nuevas tecnologías están muy bien, y se puden hacer cosas chulísimas y muy mantenibles y con pocos bugs.. pero es comparar  una escudería de F1 con una marca de coches generalista. Mercedes puede hacer un monoplaza que gane carreras o una Viano para el reparto. Decidme cuál de los dos vehículos "mueve el mundo" y pone el dinero en el bolsillo a fin de mes. Con la infomática, lo mismo.

Por cierto, como anécdota, la empresa de un amigo buscaba un desarrollador C para irse a Australia ganando 300,000 dólares australianos al año (casi 190.000 euros) y no fueron capaces de encontrar uno competente. Esto con Franco Java no pasaba. 

[Benzino Napaloni]

El técnico siempre tiende a la tecnología (o a lo nuevo, modernísimo, o a lo viejo, conocidísimo) pero muy pocas veces tiene visión comercial.

A mí que un sistema esté desarrollado en el demonizado Java (que os guste o no, funciona, y da menos quebraderos de cabeza que otras tecnologías más modernas y molonas) me parece bien mientras cumpla lo que tiene que hacer. No digo nada si nos metemos en empresas con entornos mucho más restrigidos, donde no dejan instalar nada que no lleve años en mercado por miedo a vulnerabilidades no descubiertas.

Bueno, algo aprendemos. Por lo menos, los Kotlineros entre los que me incluyo .

Kotlin se pensó desde el principio para ser compatible con Java. Era un must, porque si dices al que tiene un proyecto de no sé cuántas mil clases que hay que tirarlo a la basura y hacerlo nuevo, se ríe en tu cara o te calza un guantazo .

Así, la migración es progresiva. Y sólo por el hecho de quitar verbosidad y mierda, queda un código mucho más legible, y por lo tanto más fácil de mantener. Que esto también es dinero y visión comercial. Claro que para llegar a verlo también hace falta sentido común.

Google lo adoptó en 2017, y ahora, seis años después, el chascarrillo entre los "machacas" es que Java es para la mierda que nadie quiere: mantener sistemas. Camino de ser otro COBOL, si es que no lo es ya. En las entrevistas de trabajo serias con Kotlin se pide Java por la única razón de saber bajar al barro si es necesario. Pero hay consenso en que lo nuevo hay que picarlo en Kotlin directamente, y pasar el mocho de vez en cuando para ir migrando lo que queda.

Kotlin tiene todo lo bueno de Java y eliminando mucho de lo malo.

[pollo]

Que sepáis que teniendo razón (que la tenéis), en el mundo de los resultados las cosas se ven de otra manera.

El técnico siempre tiende a la tecnología (o a lo nuevo, modernísimo, o a lo viejo, conocidísimo) pero muy pocas veces tiene visión comercial.

A mí que un sistema esté desarrollado en el demonizado Java (que os guste o no, funciona, y da menos quebraderos de cabeza que otras tecnologías más modernas y molonas) me parece bien mientras cumpla lo que tiene que hacer. No digo nada si nos metemos en empresas con entornos mucho más restrigidos, donde no dejan instalar nada que no lleve años en mercado por miedo a vulnerabilidades no descubiertas.

No me sirve de nada tener un Ferrari nuevo en el garaje si se pasa la mitad del tiempo en el taller. Si lo que necesito es ir de A a B todos los días, un viejo Toyota (Java) que no rompe motor me sirve más que de sobra. Si encima me lo puede mantener un desarrollador medio junior, pues miel sobre hojuelas.

Vosotros mejor que nadie sabéis que ahí fuera no son todo Metas y Googles, lo gordo de la informática son los millones de sistemas que hacen que la rueda siga girando (cuántos SAP de más de 20 años hay todavía por el mundo llevando las fábricas de muchas empresas del Fortune 500).

Que las nuevas tecnologías están muy bien, y se puden hacer cosas chulísimas y muy mantenibles y con pocos bugs.. pero es comparar  una escudería de F1 con una marca de coches generalista. Mercedes puede hacer un monoplaza que gane carreras o una Viano para el reparto. Decidme cuál de los dos vehículos "mueve el mundo" y pone el dinero en el bolsillo a fin de mes. Con la infomática, lo mismo.

Por cierto, como anécdota, la empresa de un amigo buscaba un desarrollador C para irse a Australia ganando 300,000 dólares australianos al año (casi 190.000 euros) y no fueron capaces de encontrar uno competente. Esto con Franco Java no pasaba. 

La comparación es absurda. La metáfora no se sostiene. La referencia a las grandes tecnológicas es sólo para indicar que en sitios donde tienen a gente muy competente se dan cuenta de los problemas reales de crear todo tipo de software de todas las escalas (en una empresa hay mucho más software internamente que el que se ofrece al público).

Rust no es un Ferrari, ni está diseñado para crear sólo Ferraris. Es un lenguaje open source creado por una gran comunidad de usuarios avanzados que de una puta vez corrige errores garrafales, inexplicables y absolutamente injustificables que se llevan arrastrando en los lenguajes de bajo nivel más populares (C pero sobre todo C++, que sería más cercano a su nicho), y lo hace además de forma que abarata costes, elimina clases enteras de bugs, hace más fácil la vida al que programa (por un montón de cosas demasiado extensas para mencionarlas aquí) y hace más sencillo razonar localmente sobre el código, lo cual es todo un win-win de unas proporciones muy fáciles de subestimar.

Cualquiera puede usarlo para proyectos grandes y pequeños. No tiene ni puto sentido decir que sólo aporta en grandes empresas. Los proyectos de empresas pequeñas pueden ser my complejos y grandes, y aún así no implica que no tenga sentido para proyectos pequeños o programación por hobby (especialmente si se defiende usar C o C++, para los que se podría argumentar exactamente lo mismo).

La filosofía es ser absolutamente explícito en todos los efectos, razonar de forma local en el código, y capturar todos los errores posibles durante la compilación. Esto es simplificando mucho. Es posible incluso hacer irrepresentables determinados errores.

No usarlo en proyectos que necesitarán mantenimiento es absurdo. No es que te importe que esté en Java porque haga lo que tenga que hacer, es que hoy por hoy sólo con los gastos que puede ahorrar es del género tonto ignorarlo si es una buena opción.

Los proyectos de software generan mucho más gasto y trabajo en la fase de mantenimiento que en la de creación. Haces una aplicación en Java (o en otras cosas), y ya de mano se te puede disparar el coste de servidores, puedes tener problemas de concurrencia (se te cuelga, te salen excepciones, etc.), el servidor puede tener picos de RAM, etc. Pero el problema real viene cuando hay que alterar el código para ampliar funcionalidad, corregir errores y otras tantas cosas que salen sobre la marcha.

Todo eso es pasta, tiempo y complejidad, que con el uso de un lenguaje como Rust y un poco de cabeza, simplemente desaparece, permitiendo centrarse en lo que de verdad importa: añadir funcionalidad al código sin romper el ya existente. Simplemente, da la sensación de que habláis sin conocimiento de causa. Mejor investigad y leed un poco sobre cómo funciona y lo que aporta antes de soltar la cuñadez típica "yo no necesito eso".

Si está reeemplazando muchos nuevos proyectos de bajo nivel a C++ (y el que da el salto no vuelve al masoquismo de C++) es por algo. Los principales promotores son los propios programadores.

[pollo]

Para el que tenga curiosidad:


Rust for "modern" C++ devs
http://venge.net/graydon/talks/RustForModernCPPDevs.pdf

Extractos interesantes:

What is good about Rust
• The main selling feature: Safety
• Without performance overheads
• Rust mostly prevents several big, bad classes of bugs
• "Spatial" memory errors: out-of-bounds / wild / null pointers
• "Temporal" memory errors: use-before-init, use-after-free
• Multiple threads racing on same data
• Pretty much all UB

Many minor fixes that prevent ubiquitous C++ bugs:
• Can't write dangling-else, switch-case-fallthrough, or goto
• No silent int-float, signed-unsigned coercions
• Booleans, enums, integers, pointers not mixable
• Can't typo == as =
• Strings guaranteed UTF-8, no random access
• Culture of partial functions that return precise errors

 It also has great, very standardized tooling
• Configuration, building, testing
• Packages, dependencies
• Profiling, fuzzing
• Documentation, code-formatting
• A very good editor / IDE backend

• The compiler has fantastic diagnostics
• With standard, fine-grained control over checks
• The IDE often gives you a push-button fix
• You can opt-in to zillions of extras
• Everything is very documented


Main theme in design: better-behaved pointers
• Steep 60% part of Rust learning curve is internalizing pointer rules
• May seem arbitrary, tyrannical, cruel
• Really just formalize "safe version of C++ idioms"
• But no wiggle room: won't compile if violated
• Once reflexive, fairly smooth sailing
• Other 40% is much less steep, just "work"


C++ pointer-ish types have many ok-ish ingredients
• Owners: unique_ptr<T> and shared_ptr<T>
• Non-owning, transient refs: & and const&
• Owner/transient split has advantages
• Avoids most book-keeping, no tracing GC
• Faster, more deterministic behaviour

But C++ pointer-ish types let you do terrible things!
• const& can point to a mutable value, may change
• I guess it's cool that it stops you from mutating?
• & and const& can point to already-freed memory
• Or something half-initialized, or half-destructed
• Owner-pointers can be nullptr
• Threads can race on all of them

Rust prohibits all of this nonsense
• Eg. Box<T> is like unique_ptr<T> except
• Has no null value, always points to a T
• Is immutable if there's any live immutable &-reference
• Is inaccessible if there's any live mutable &mut-reference
• Can only move between variables, and not while &-referenced
• Thus two threads cannot race on it (more on this later)

Two main (weird) ingredients to the rules
• Move semantics
• Borrow checking
• These two ingredients reinforce each other remarkably well
• Commonly called Rust's "ownership system"

Borrow checking
This is maybe the strangest part
It's "borrow checking" time!

• Everything in Rust is default-immutable
• Mutability is opt-in with mut keyword, unlike C++ immutability opt-in const
• This is true about references too:
• C++ immutable const& is written as just plain & in Rust
• C++ mutable & is written as &mut in Rust
• Except, of course, that the rules are also somewhat different in Rust

Borrow checking enforces two main sets of rules
• "Referent outlives reference" / "lifetimes"
• To avoid dangling/wild pointers
• "Shared xor mutable" / "static reader-writer locking"
• To avoid invalidating one pointer by writing through another
• This is all static, compile-time checking, not runtime mechanisms

First set of rules: referent outlives reference
• Prevents borrows pointing at garbage memory
• You can only borrow something (form a & or &mut reference) if:
• The borrowed thing exists before the borrow starts
• The borrowed thing exists after the borrow is done

This is tracked through extra (static, compile-time) variables called "lifetimes"
• Often inferred / invisible, but sometimes written explicitly
• Written as a name with a leading single quote, after the ampersand
• Like &'a or &'some_lifetime mut
• It can help to give them informative names
• Unfortunately lots of times they get named 'a, 'b, 'c

This is weird and does not read like C++. It's new.
• Here's an example:
struct Foo<'a> {
   x: &'a i32,
   y: &'a mut i64
}
• Nobody likes how this reads and it never gets easier on the eyes

Second set of rules: shared xor mutable
• Means that any memory-write will not invalidate some other pointer
• Most important "at a distance" (other functions, other threads)
• Can even save you "up close" (same function and thread)
• Eg. borrow an enum (variant type) in case X, then set it to case Y, oops

Just getting program past borrow checker can be hard
• Surprising how many aliases were hiding in C++
• Eg. how every non-const method call can change members via this
• If you felt OOP was a little error-prone, now you know why
• Helps to only borrow specific fields, not self as a whole
• Helps to restrict to arg-passing and returns, not store & refs in structs

[sudden and sharp]

Bueno, le he estado echando una ojeada... a Rust.


Es una reimplementación de todo. Desde la command-line hasta la paquetería de aplicaciones... muy del estilo de MS. (Demasiado tal vez.) No dudo que tenga sus ventajas... MS no suele trabajar mal precisamente.

Pero atención a la licencia: MIT y Apache. (Que podrían valer...) pero que incluyen cosas como: LLVM o MSVC (Ojo que esto último es "Microsoft Visual  C++"... vamos que no te libras de C++) y ...

... sabiendo del reciente soporte de Rust en el kernel Linux ... pues blanco, en botella, y etiquetado "MS".

En síntesis, un secuestro a mano armada de todo lo que era libre: gcc, g++, linux, dpkg... etc., para horientarlo en una dirección lo más lejana posible de la licencia GPL, ó LGPL.





----
MS sería una empresa genérica, no necesariamente en la que estás pensando.

[el malo]

Que sepáis que teniendo razón (que la tenéis), en el mundo de los resultados las cosas se ven de otra manera.

El técnico siempre tiende a la tecnología (o a lo nuevo, modernísimo, o a lo viejo, conocidísimo) pero muy pocas veces tiene visión comercial.

A mí que un sistema esté desarrollado en el demonizado Java (que os guste o no, funciona, y da menos quebraderos de cabeza que otras tecnologías más modernas y molonas) me parece bien mientras cumpla lo que tiene que hacer. No digo nada si nos metemos en empresas con entornos mucho más restrigidos, donde no dejan instalar nada que no lleve años en mercado por miedo a vulnerabilidades no descubiertas.

No me sirve de nada tener un Ferrari nuevo en el garaje si se pasa la mitad del tiempo en el taller. Si lo que necesito es ir de A a B todos los días, un viejo Toyota (Java) que no rompe motor me sirve más que de sobra. Si encima me lo puede mantener un desarrollador medio junior, pues miel sobre hojuelas.

Vosotros mejor que nadie sabéis que ahí fuera no son todo Metas y Googles, lo gordo de la informática son los millones de sistemas que hacen que la rueda siga girando (cuántos SAP de más de 20 años hay todavía por el mundo llevando las fábricas de muchas empresas del Fortune 500).

Que las nuevas tecnologías están muy bien, y se puden hacer cosas chulísimas y muy mantenibles y con pocos bugs.. pero es comparar  una escudería de F1 con una marca de coches generalista. Mercedes puede hacer un monoplaza que gane carreras o una Viano para el reparto. Decidme cuál de los dos vehículos "mueve el mundo" y pone el dinero en el bolsillo a fin de mes. Con la infomática, lo mismo.

Por cierto, como anécdota, la empresa de un amigo buscaba un desarrollador C para irse a Australia ganando 300,000 dólares australianos al año (casi 190.000 euros) y no fueron capaces de encontrar uno competente. Esto con Franco Java no pasaba. 

La comparación es absurda. La metáfora no se sostiene. La referencia a las grandes tecnológicas es sólo para indicar que en sitios donde tienen a gente muy competente se dan cuenta de los problemas reales de crear todo tipo de software de todas las escalas (en una empresa hay mucho más software internamente que el que se ofrece al público).

Rust no es un Ferrari, ni está diseñado para crear sólo Ferraris. Es un lenguaje open source creado por una gran comunidad de usuarios avanzados que de una puta vez corrige errores garrafales, inexplicables y absolutamente injustificables que se llevan arrastrando en los lenguajes de bajo nivel más populares (C pero sobre todo C++, que sería más cercano a su nicho), y lo hace además de forma que abarata costes, elimina clases enteras de bugs, hace más fácil la vida al que programa (por un montón de cosas demasiado extensas para mencionarlas aquí) y hace más sencillo razonar localmente sobre el código, lo cual es todo un win-win de unas proporciones muy fáciles de subestimar.

Cualquiera puede usarlo para proyectos grandes y pequeños. No tiene ni puto sentido decir que sólo aporta en grandes empresas. Los proyectos de empresas pequeñas pueden ser my complejos y grandes, y aún así no implica que no tenga sentido para proyectos pequeños o programación por hobby (especialmente si se defiende usar C o C++, para los que se podría argumentar exactamente lo mismo).

La filosofía es ser absolutamente explícito en todos los efectos, razonar de forma local en el código, y capturar todos los errores posibles durante la compilación. Esto es simplificando mucho. Es posible incluso hacer irrepresentables determinados errores.

No usarlo en proyectos que necesitarán mantenimiento es absurdo. No es que te importe que esté en Java porque haga lo que tenga que hacer, es que hoy por hoy sólo con los gastos que puede ahorrar es del género tonto ignorarlo si es una buena opción.

Los proyectos de software generan mucho más gasto y trabajo en la fase de mantenimiento que en la de creación. Haces una aplicación en Java (o en otras cosas), y ya de mano se te puede disparar el coste de servidores, puedes tener problemas de concurrencia (se te cuelga, te salen excepciones, etc.), el servidor puede tener picos de RAM, etc. Pero el problema real viene cuando hay que alterar el código para ampliar funcionalidad, corregir errores y otras tantas cosas que salen sobre la marcha.

Todo eso es pasta, tiempo y complejidad, que con el uso de un lenguaje como Rust y un poco de cabeza, simplemente desaparece, permitiendo centrarse en lo que de verdad importa: añadir funcionalidad al código sin romper el ya existente. Simplemente, da la sensación de que habláis sin conocimiento de causa. Mejor investigad y leed un poco sobre cómo funciona y lo que aporta antes de soltar la cuñadez típica "yo no necesito eso".

Si está reeemplazando muchos nuevos proyectos de bajo nivel a C++ (y el que da el salto no vuelve al masoquismo de C++) es por algo. Los principales promotores son los propios programadores.

Creo que mi mensaje no se ha entendido. No hablo de Rust en concreto ni de ninguna otra tecnología en particular. Lo que digo es que el informático es un técnico que mira su parcela de trabajo desde una perspectiva muy concreta (la técnica) y no ve más alla (porque no se le paga para eso).

Decir que hablo sin conocimiento de causa es muy osado. Va a ser eso, que no conozco la industria

A los informáticos se les suele "olvidar" que los sistemas nunca son un fin último, son herramientas. Y hay veces que por H o por B hay que usar una herramienta arcaica y oxidada, aunque el informático se empeñe en que lo mejor es usar el último rayo láser disponible.

El informático ve su parcela, su (o sus) sistemas. A mí me pagan para ver la foto completa. En una parte de esa foto tengo 54 sistemas de todas las edades, pelajes y equipos de soporte, todos integrados en la misma rueda. Un 70% de ellos son imprescindibles para la rueda siga girando y el otro 30% son eficiencias y nice-to-haves. Y repito, los sitemas son sólo parte de mi foto diaria.

¿que habría que cambiar ese sistema desarrollado en Java que fue desplegado en el 2000? Posiblemente. Pero ese sistema no me ha dado ni un problema en los últimos 5 años, y en la foto tengo otros 53, y algunos sí me dan auténticos dolores de cabeza. Porque al final, lo único que importa es que las herramientas hagan lo que tienen que hacer para que la empresa pueda vender, que es lo que realmente nos paga el sueldo a todos.

No hay nada más "de informático" que ir al jefe y decirle que el sistema que soporta en Java es arcaico y hay que cambiarlo. Y si no, se niega a seguir trabajando y se va. Luego el jefe me viene a mí y nos echamos unas risas mientras le digo que vaya buscando un reemplazo por si acaso. ¿Tiene razón el informático en el tema tecnológico? Sí. ¿Por qué no se hace lo que dice? Por lo que he explicado arriba. A veces explico el por qué, y a veces no, dependiendo del tiempo que tenga y de la confidencialidad del tema.

Claro que hay mucho jefe (intermedio y C-level) que se cree que sabe más que nadie y causa auténticos desastres. Yo tengo historias de terror para todos los gustos.
Lo que os garantizo es que un mundo liderado única y exclusivamente por técnicos, tendríamos unos sitemas robustísimos y perfectos.. y el triple de costes y una fracción de las ventas.