Dejar de usar C y C++ y centrarse en Rust y Java: esto recomienda la Agencia de Seguridad de EE.UU a empresas del mundo

La NSA o Agencia Nacional de Seguridad de Estados Unidos ha publicado una guía en la que anima a las organizaciones a cambiar los lenguajes de programación de C y C++ por alternativas "memoria segura", donde entran otros lenguajes como C#, Rust, Go, Java, Ruby o Swift. "La NSA recomienda que las organizaciones utilicen lenguajes seguros para la memoria siempre que sea posible y refuercen la protección mediante defensas de endurecimiento del código" dice el último comunicado emitido por el organismo.

[#1 Pacman]

Java?

[#5 Desactivado]

#1 #3 Lo dicen para poder entrar a saco hasta la cocina "around the world".

Podrían recomendar extremar la formación en seguridad a los programadores de C y C++. Un gran poder ...

[#21 tednsi]

#5 Prefieren los lenguajes interpretados, donde la NSA ya ha metido su puerta trasera en el intérprete o máquina virtual.

[#23 flixter]

#21 tu sabes que ni java ni rust son interpretados, verdad?

[#29 tednsi]

#23 No. No sabía que creaban ejecutables que directamente se ejecutan sin tener ningún software específico instalado.

[#30 flixter]

#29 rust se compila, con lo que te queda un binario ya listo para ser ejecutado, y java compila a medias, y te queda un binario en lenguaje intermedio que requiere de una java virtual machine en la plataforma.

[#69 Desactivado]

#30 Pues eso, que es interpretado. Interpreta código intermedio, pero es interpretado.

[#73 elgranmago]

#69 Si la NSA mete una puerta trasera en el compilador, cosa que recuerdo ya se ha hecho, estás en las mismas. Tienes un código binario con un troyano que se ejecuta fantásticamente.
El tema de meter puertas traseras te da lo mismo, sea con máquina virtual o con código compilado.

[#91 Desactivado]

#73 Si, siempre que uses una máquina virtual y/o un compilador fiables, todo en orden... http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

Pero no es lo mismo troyano en código compilado (lo metieron al compilarlo) que compilador con troyano. Lo segundo es top top.

[#140 Desactivado]

#73 Java y Rust son código abierto, y están mantenidas por personas y empresas de todo el mundo. Si la NSA puede meter ahí una puerta trasera, también puede meterla en el compilador GCC. Aunque veo más factible que meta una puerta trasera en los compiladores C/C++ de Microsoft o Intel.

[#90 flixter]

#84 #83 #69 Pues mira, despues del primer comentario me entretuve buscando, y resulta que no se consideran ni compilados ni interpretados, justamente por que tienen parte de los dos procesos.

Por cierto, cuando hables a uno que presumiblemente no sabe del tema (como era mi comentario anterior), es mucho mas entendible por esa persona "se compila a medias" que "produce un bytecode, que vendria a ser un codigo intermedio, y blah-blah-blah". O sea que sí: para un no iniciado, java "compila a medias"

[#138 Desactivado]

#30 #69 ese código intermedio se acaba compilando "Just In Time" a código nativo, optimizándose según los puntos calientes en tiempo de ejecución. Por eso en muchas tareas es más rápido que lenguajes compilados como Go.

Pero si tan poco te gustan las máquinas virtuales, desde hace ya años Java se puede compilar "Ahead Of Time" a un ejecutable nativo, obteniendo ciertas ventajas y perdiendo otras, como la optimización JIT.

[#215 jgp3500_6377af12dcaec]

#69 No man, no es interpretado, es un binario que se ejecuta en una máquina virtual (JVM) y luego es esa máquina virtual que se encarga de ejecutar esos bytes code al sistema operativo dónde reside. La desventaja de eso, es el tiempo de ejecución, y las muchísimas ventajas ...investigala

[#84 chavi]

#30 No. Java no "compila a medias".

Java crea un binario para que una JVM lo ejecute

[#45 pedrobz]

#23 Java si es interpretado, al menos en el sentido de seguridad. Java compila, pero genera bytecodes que son un ensamblador genérico, luego la máquina virtual interpreta ésos bytecodes y genera el código máquina en tiempo real (el compilador JIT)

Así que para lo que se quiere si, la NSA puede meter una puerta trasera en el Oracle JRE y espiar todo sin que el código .class se entere

[#46 Desactivado]

#45 OpenJDK. Java es libre desde hace eones, y ahora está el GraalVM en OpenJDK.

[#60 Ovlak]

#45 No tienes por qué usar la JVM de Oracle, hay alternativas Open Source. Si nos ponemos por esas, usando un compilador privativo de C/C++ la NSA te puede estar haciendo lo mismo injectando la puerta trasera en el binario.

[#161 pedrobz]

#60 #45 No tienes porque usar la JVM de Oracle... pero el 90% usa la JVM de Oracle, al menos, es lo que yo he visto en mi trabajo, en todos lados se usa esa máquina, en algún sitio he visto usarse la de IBM, por eso lo de 90%. Con un compilador tendría que atacar el código en el momento que compila, pero en un lenguaje interpretado solo tienes que atacar al intérprete o a la JVM, y lo puedes hacer en cualquier momento.

Todo esto asumiendo esa capacidad de atacar que tiene la NSA, que a efectos prácticos es muy dudoso, y salvo que tengas un nivel de seguridad de grado militar alto, con tener actualizada la JVM ya vale, porque van a ser mucho más importantes otros temas de seguridad como librerías de la app, asignación de permisos correctos y comunicación cifrada entre servicios etc. Me encanta la analogía de las lonchas de queso Gruyere, cada capa tiene agujeros, pero juntas es un bloque muy sólido, tener una JVM, un interprete o un código compilado es solo una loncha de muchas.

[#83 chavi]

#23 Si lo son. Se "compilan" a una máquina virtual que ejecuta el programa.

No producen código máquina nativo.

[#175 aritzg]

#23 pero se ejecutan sobre una máquina virtual. Así que el concepto de #21 sigue aplicando

[#48 Razhan]

#21 El código de OpenJDK es GPL. Si hubiese una puerta trasera, sería visible en el código.

[#98 Desactivado]

#5 No lo dudes. EEUU siempre acusa de espionaje a los chinos sin pruebas, pero es que a ellos les hemos pillado espíando infraganti a empresas y primeros ministros europeos. Y nos ha dado igual.

[#106 Tapii]

#5 como si es fuese un problema. Entiendo que desde donde escribes es un dispositivo que ni software ni hardware ha sido diseñado en Usa

[#107 pax0r]

#5 no, lo dicen porque todo lo escrito en c es vulnerable a un b0f

[#6 Desactivado]

#1 demasiado facilón para ser seguro

[#38 ostiayajoder]

#6 Precisamente por eso es seguro.

Y no te preocupes por JVMs, otra cosa no habra, pero JVMs a montones. Y todas Open Source.

[#9 pascual]

#1 ¿Qué tiene de malo Java? ¿Están equivocadas compañías como Amazon, Netflix, Paypal, Uber... que han basado sus plataformas en ese lenguaje en lugar de hacerlo con el lenguaje de moda de la época?

[#19 Desactivado]

#9 Golang hoy se folla a Java para eso.

[#62 dalton1]

#19 Sólo si Java dice que sí, es que sí.

[#70 woopi]

#62 Es que el chiste era que dejé a la novia por que no sé de Java

[#143 Desactivado]

#19 es muy guay decir "Golang se folla a Java" y quedarse tan ancho. Lo gracioso es que a más de un ingeniero le sirve para tomar una decisión sin mirar nada más.

Yo trabajé en uno de esos llamados hyperscalers (ingesta de terabytes de datos por segundo), y acabamos moviendo nuestros servicios más críticos de Go a Java porque, además de que las librerías de Kafka para Go son una chusta inestable, acabamos mejorando el rendimiento un 15%. Y eso son muchas CPUs en Amazon.

Después de años trabajando con haters de Java y fanboys de Go, cómo moló darles zasca en toda la boca con los datos en la mano

[#22 PauMarí]

#9 eing? No estarás confundiendo Java con Javascript?

[#24 pascual]

#22 No, Javascript es el lenguaje que se ejecuta en tu navegador web. Pero en el servidor, el código que se ejecuta cuando buscas un producto, cuando lo añades a tu cesta y se guarda en base de datos, cuando haces el proceso de compra, cuando se genera el recibo, cuando te llega una notificación por correo electrónico... es Java. Es su principal uso (además de Android) y siempre ha sido así, aunque mucha gente tienda a asociar Java a Applets (que sería algo parecido a Javascript en que se ejecutaba en el navegador).

[#25 PauMarí]

#24 se de sobras la diferencia entre Java y Javascript, así como entre frontend y backend, por eso mi comentario, ninguna de esas empresas (y me atrevería a decir ni ninguna de la mayoría de "nuevas" empresas) montan un backend en java, es infumable...
Sobre Android... Google hace ya bastante tiempo que recomienda no usar Java (en favor de Kotlin).
Que no cuela, que java es un lenguaje engorroso anticuado y que sólo interesa des de un punto de vista "empresarial", nunca des de un punto de vista técnico, y por suerte la mayoría de gente hoy en día ya se ha dado cuenta hace tiempo.
Por cierto, sobre tu último párrafo, sepas que de Java Javascript sólo tiene el nombre (dicho por el propio inventor de Javascript, que le puso es nombre solo por el "gancho" del "lenguaje de moda" de esa época)
Y ningún programador "moderno" te hablará de applets, por favor, es como volver al OCX o al ActiveX

[#27 whatisthat]

#24 A todo lo que te ha dicho #25 (que está bastante completo), habría que añadir que te has colado diciendo que JS no funciona como servidor, cuando hoy en día es una opción especialmente popular.
https://w3techs.com/technologies/details/ws-nodejs

Pero no solo como servidor; también se nutren de diferentes frameworks como electron para crear aplicaciones multiplataforma como el visual studio code, discord...
https://zeke.github.io/electron.atom.io/

[#133 pascual]

#27 A todo lo que te ha dicho #25 (que está bastante completo), habría que añadir que te has colado diciendo que JS no funciona como servidor, cuando hoy en día es una opción especialmente popular.

No me he colado porque en los sitios de los que he hablado, Java es lo que funciona en servidor y Javascript es lo que funciona en cliente. Amazon, Twitter o Linkedin no están hechas con node.js

[#39 ostiayajoder]

#25 Que no cuela, que java es un lenguaje engorroso anticuado y que sólo interesa des de un punto de vista "empresarial", nunca des de un punto de vista técnico, y por suerte la mayoría de gente hoy en día ya se ha dado cuenta hace tiempo.

Ah, vale. Solo de un punto de vista empresarial....



ninguna de esas empresas (y me atrevería a decir ni ninguna de la mayoría de "nuevas" empresas) montan un backend en java, es infumable...



Te falta mundo, cabesa.

[#41 PauMarí]

#39 te aseguro que no me falta mundo, tengo (tenía, mejor dicho, ya que hace unos años) el record europeo de website con más compras simultáneas soportadas... (máquinas virtuales repartidas en diferentes datacenters con un backend NO funcionando en java (pero sí, a mi pesar, con un clúster de SQL Servers)).
Y cuando me refiero a una decisión empresarial me refiero a una ADMINISTRATIVA (tema sueldos programadores y no querer asumir el coste de canviar a un sistema moderno)
Creo que al que le falta mundo no es precisamente a mi....
Por cierto, la tecnología del backend de Netflix es público (de hecho alguien meneó un artículo al respecto por aquí). El front creo que era React, no lo recuerdo ahora mismo pero te aseguro que el Back NO era java, hablas sin conocer de lo que hablas.

[#50 Razhan]

#41 Efectivamente, mucho es publico. Y hay java a patadas. https://netflix.github.io/

[#77 PauMarí]

#50 hadoop? Un proyecto de más de 20 años... Lo dicho, los nuevos proyectos no se hacen con java pero eso no quita (ni niego) que existelan muchos todavía.

[#109 Quepasapollo]

#77 eso es muy discutible, mírate los pliegos que está saliendo de la administración, vas a comer Java por un tubo, y sí, hablo de proyectos from scratch

[#124 aironman]

#77 tu de big data como que ni idea, no? El map reduce de Hadoop está deprecado, pero hdfs y yarn junto con spark/flink es la norma para tener un cluster BigData.

[#57 infraser]

#41 te falta muuucho mundo si te crees que el único por el cual se elige java es administrativo

[#72 PauMarí]

#57 sí papa, sí, lo que digas...

[#75 pawer13]

#41 React es de Facebook, Feign y Zulu es de Netflix y son Java, por ejemplo.
Java está muy lejos de estar anticuado, por mucho que lleguen otros lenguajes más modernos.

[#110 yende]

#61 #49 #41 Por aportar algo, puede servir de ejemplo el uso del COBOL en mainframe en entornos Bancarios y de seguros. Tienen todo la infraestructura montada, con todos los procesos y, lo más importante, funciona. Es mas seguro mantener y evolucionar ese backend que realizar otro en una tecnología mucho más actual. La empresa no se quiere arriesgarse a un cambio de tal mastodonde ya que puede ser muy traumático.

Las pantallitas que ve el cliente o los empleados ya las harán con todas las florecillas que sean necesarias.

Firmado un Ex picador de Cobol.

[#113 Peazo_galgo]

#41 "canviar"??? Mis hogos....

Sí, está claro que no eres de letras....

[#200 ostiayajoder]

#41 Y cuando me refiero a una decisión empresarial me refiero a una ADMINISTRATIVA (tema sueldos programadores y no querer asumir el coste de canviar a un sistema moderno)

O, vaya, fijarse en los costes y en la fiabilidad para desarrollar un proyecto. Locuron.

Lo de netflix... es que me da igual.... Si me pongo a mirar bigtechs no me van a faltar ejemplos de cosas hechas en Java, espero que no haga falta ponerme a buscar, pero no se.... gmail? Es mas, si quieres te informo de que en Netflix estan contratando a un monton de gente para java:

https://jobs.netflix.com/search?q=java

Y startups... no se... he hecho varias entrevistas para puestos en java, a nivel nacional e internacional y trabajo en una internacional, ahora mismo...

Y si. Se utiliza para cosas viejas y para cosas nuevas pq:

1- Montones de personas saben usarlo. Lo cual es BUENO para poder tener desarrolladoress cuando necesites que sean rapidamente productivos.
2- Es muy versatil: Puedes hacer monolitos, sistemas complejos distribuidos, SOAs, eventdriven, lo que quieras y ademas....
3- Existen soluciones Open Source para TODO, y muy usadas. Es muy robusto.
4- No hay un nuevo framework cada 2 semanas.

Encima en java 19 le van a dar una vuelta a la asincronia del copon....

Y eso por no hablar de los benchmarks de consumo de energia en los que solo C, C++, RUST y. Ada consumian menos (adjunto foto)

Y eso por no hablar de GraalVMs que te hace AOT en nativo disparando el tiempo de arranque, la velocidad de ejecucion y reduciendo bestialmente la memoria utilizada...

Luego, si, estan las aplicaciones empresariales con J2EE y java 6 u 8, pero pretender que eso es el ecosistema de java...

PD: si te hubiera dicho a la cara mi anterior test no te habria sentado mal pq lo decia como expresion hecha, no despectivamente y las sonrisas era para mostrar ironia pero no maldad.

Mea culpa eso.

[#54 Razhan]

#25 la mayoría de los servicios de AWS tienen Java por detrás

[#74 PauMarí]

#54 y ahora es cuando viene lo de que Facebook está hecho en php?

[#81 Razhan]

#74 busca mis comentarios. Mi LinkedIn está ahí. Cuando veas quién soy y en que trabajo te darás cuenta que estoy en una posición privilegiada para entender el uso de Java en AWS. Es más, creo que puedo decir con confianza que es la posición más privilegiada que existe.

[#86 PauMarí]

#81 y eso en que invalida mi comentario?

[#93 Razhan]

#86 decías anteriormente que ninguna de esas empresas (incluyendo Amazon) montaría un backend usando Java, y luego has intentado compararlo con el uso de PHP en Facebook, que hace años reemplazó PHP por Hack y distintos lenguajes para backend

[#101 PauMarí]

#93 precisamente, estoy diciendo que nadie empieza un proyecto nuevo con java, pero eso no quita que todavía exista y se mantenga, como ocurrió con php en Facebook (o java en Android). Pero todo el mundo empieza los nuevos proyectos con otras herramientas hoy en día.

[#160 enriquefriki]

#93 Disculpar que tercie. Intuyo que no alcanzo vuestro nivel, pero en presente digo que todo el ecosistema de AWS es fantástico. Estoy muy satisfecho con él mismo. Hoy por hoy creo que es la mejor plataforma de servicios cloud que existe.
Yo -por cuestiones de edad- soy del mundo LAMP -Linux, Apache, MySQL y PHP- y el mundo Java lo vivi en primera persona currando hace años en una cárnica de esas que en función de un requerimiento de una administración pública, pidió un portal con un CMS basado en Java Liferay La cuestión es que había que alojarlo en un servidor Apache.
A mi siempre me pareció demasiado recursivo todo eso. Compilar sobre compilar. Y no veas los tiempos de implementación...meses.
Mi impresión personal, a lo mejor equivocada, es que desde el mundo de la universidad la gente sale preparada precisamente en este lenguaje de programación Java Y si añadimos que las distintas administraciones públicas insisten en la implementación de soluciones basadas en este lenguaje, pues el campo está muy muy tasado.
Y ya para terminar. Creo que RoR, el mismo PHP, y muchos de los lenguajes de programación Open Source son además de escaladles, fáciles de implementar, elásticos y sobretodo están sobradamente documentados gracias a la comunidad que los soportan. Java es uno de ellos...pero creo que lleva demasiados años y lo considero un poco obsoleto.
Pero bueno...el software jamás es un producto terminado.

[#224 selina_kyle]

#81 lo he buscado y ole tú!!!

[#61 FooDev]

#25 Cuánta soberbia.

No quiero hacer de abogado del diablo porque a mí tampoco me gusta Java (efectivamente muy engorroso), pero de ahí a descartarlo sin contemplaciones a día de hoy como una opción plausible para el back... Pues mira, tampoco.

El punto de vista que tú llamas empresarial es en realidad el punto de vista técnico aplicado en la industria. Hay que tener en cuanto todos los pros (seguridad, estabilidad, soporte... comunidad) y contras (los aquí ya expuestos). Y desde luego hay aspectos más importantes que el syntactic sugar.

Vamos, que todos lo queremos ver muerto pero le sobran razones para seguir vivo y coleando.

[#71 PauMarí]

#61 soberbia? Dime algún NUEVO proyecto que se base en java? Tenéis ganas de discutir obviedades? Ya nadie se lo plantea....

[#183 FooDev]

#71 En mi empresa mismamente. Todos los proyectos nuevos van en Java. Precisamente porque prima la estabilidad y seguridad del ecosistema.

[#67 Enfin...]

#25 La mayoría del backend de Netflix sigue escrito en Java

[#167 llorencs]

#67 No tenía mucha cosa Netflix en backend escrita en Python, también?

[#87 chavi]

#25 ninguna de esas empresas (y me atrevería a decir ni ninguna de la mayoría de "nuevas" empresas) montan un backend en java
Java es un gran lenguaje de servidor y probablemente el MAS utilizado para aplicaciones de alta demanda y rendimiento.

Java no es ni anticuado ni engorroso. En qué te basas para sostener esa afirmación?

Por qué dices que "solo interesa desde el punto de vista empresarial"?

[#88 PauMarí]

#87 igual que cobol lo fue en los bancos, y por el mismo motivo que tardaron tanto en substituirlo. Lo cortés no quita lo valiente.

[#97 chavi]

#88 Ni de coña. No es para nada comparable.

[#127 pascual]

#25 Ningún programador a día de hoy habla de applets pero es lo que uno responde cuando se pone en duda que esas compañías usen Java y si no te estarás confundiendo con Javascript. Pues sí lo usan, otra cosa es que a ti no te guste o te parezca una basura, que es una opinión muy respetable, sin embargo los ingenieros que están detrás de Amazon tenían otra opinión y aunque Java no interesa "desde un punto de vista técnico" han conseguido hacer una plataforma que vende en todo el mundo con una disponibilidad de casi el 100%. Seguramente tú lo hubieses hecho en la mitad de tiempo y sin ningún bug programándolo en Javascript, pero en esas empresas no tenían tu currículo cuando empezó todo

#31 No, no ando liado, conozco perfectamente la diferencia entre Java y Javascript y sé lo que usan esas compañias como backend, y también sé que no están migrando a nada, como ya te han dicho por ahí

[#156 SaulBadman]

#25 Dios, los ActiveX junto a Internet Explorer 6 me traen malísimos recuerdos

[#165 llorencs]

#c-25" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3749542/order/25">#25 En la empresa que trabajo hay servicios que aún se siguen montando sobre Java, incluso nuevos servicios...

Pero otros servicios se montan con GO, C#,... Dependiendo del equipo

[#193 frutosm]

#25 Hace años que estoy desconectado de Java y no estoy a la última, pero siempre me ha parecido un lenguaje de programación excelente por su fuerte soporte a la POO, su seguridad en la gestión de la memoria y el soporte comunitario. ¿Qué ha cambiado? ¿O en qué no ha mejorado?

[#31 Pacman]

#9 andas liado, como dice #22
Y todas esas compañías están migrando a otras cosas.

[#40 ostiayajoder]

#31 Si claro, cambian lo que les da un monton de pasta for the lols

[#99 chavi]

#31 Como cuales?

[#102 Pacman]

#99 Rust, Kotlin, Go

Google, por ejemplo, dice que sólo va a usar Go
Es una pura acción empresarial, quieren que se expanda por razones obvias (es suyo), pero ya estas dejando atrás a otros, como al que tratamos ahora.

[#100 hrundil]

#22 #31 #55 Yo estuve un tiempo currando en Amazon y confirmo que la mayor parte del código era Java. Sí, hay miles de microservices pero el 90% era Java.

Y no están migrando a nada. Como mucho estaban pensando cambiar el framework propio y empezar a usar Spring. Si aún había cosas críticas en Perl porque era el lenguaje de moda cuando la compañía estaba en sus inicios dudo que vayan a migrar masivamente a otro lenguaje 😂

[#121 KaisserSozze]

#100 No niego que la mayor parte del desarrollo interno pueda estar en java. Normalmente una empresa para desarrollos internos tiende en a estandarizar y usar solo ciertas tecnologías por temas de eficiencia. Pero también son conscientes que cada tecnología tiene sus pros y sus contras, y que ciertas cosas es mejor hacerlas con una tecnología u otra. Siempre digo que no puedes usar un martillo para poner tornillos.
Pero en toda gran empresa siempre hay productos de otros que usas que estarán hechos en la tecnología que el otro haya querido. Para eso están los acuerdos de interfaz, las integraciones y los integradores, las APIs, etc. para tener precisamente esa capa de abstracción en cuanto a tecnologías.
Yo trabajé también un tiempo para otra gran tecnológica, que para que te hagas idea hace hasta sus propios sistemas operativos, su propio sistema de comunicaciones internas (estilo skype), motores de bases de datos y sus propios drivers (ya que son también productores de dispositivos), y un largo etc. a ese nivel hablo. Y aún así se usan productos de terceros, por ejemplo para monitorización, o un GIS, o un gestor documental, o el webcache, o el gestor de colas, o herramientas de BI.
Es prácticamente imposible que una empresa aún siendo muy grande, cuyo producto o servicio no sea solo software y exclusivamente software, estilo Microsoft u Oracle, decir que todos los sistemas que usan están desarrollados internamente y completamente por ellos. Incluso la mayor farmacéutica retail del mundo, para la que trabajé en un proyecto de integración, usa software de terceros.
Hablando de Perl, para que te hagas idea, trabajé unos años con un facturador telco cuyo back era principalmente C. pero también con mucho bash, PL/SQL, con un cliente en Visual C y un BPM en Java. El caso es que llego un tema de integración de ficheros de terceros y debido a que Perl tiene un excelente tratamiento de cadenas y a veces teníamos que hacer postprocesos de los ficheros ya que estos podían cambiar (no le puedes pedir, hasta cierto punto, a una tercera gran compañía, que te impacte en todos sus cambios de software) tuvimos que meter Mongo con lo contentos que estábamos con nuestro Oracle.

[#52 la_gusa]

#9 Es lo que tienen las modas. Hay software usado muy a lo bestia funcionando en Java, como Confluent o Presto, pero como es antiguo puede ser bueno ni molar. La gente es así

[#55 KaisserSozze]

#9 Permite me que lo dude ¿De donde sacas la idea de que el back de esas empresas está en java? Primero, supongo que será una amalgama de lenguajes. Por ejemplo, si que se que Ebay está principalmente en PHP por qué lo dijeron cuando desarrollaron los microservicios. Pero si de verdad crees que el back de esas empresas es sólo una aplicación monolítica hecha en java y no varias decenas montadas en SOA con ESBs y Middlewares (software hecho mayoritariamente en C) o mejor aún cientos de microservicios cada uno de su padre y de su madre según convenga, o que ellos usan solo software propio y no de terceros, es que no has trabajado en una empresa medianamente grande. Seguramente la pasarela de pago este hecha en un lenguaje y con una tecnología, la logística en otra u otras, el control de almacenes en otra, la facturación en otra, el esb en otra, cada una con su repositorio de código en otra, con su gestor documental en otra, cada una con su motor de base de datos en otra, y con sus ETLs en otra, con su análisis de datos en otra, con su BI en otra, etc y eso simplificando mucho el tema.

[#131 pascual]

#55 Normalmente esas cosas se saben porque en muchas empresas hay blogs de desarrolladores, o también conferencias que se pueden ver online, donde los ingenieros hablan sobre las tecnologías que se usan en su empresa o cómo es su arquitectura. Un ejemplo de otra compañía que basó su aplicación en Java https://blog.linkedin.com/2008/06/24/linkedin-is-99-java-but-100-mac

Pero no he dicho en ningún lugar que en esas empresas sólo haya un monolito, sino que es la tecnología principal que se usa, sean microservicios u otra cosa.

[#92 Pacman]

#9 como dicen algunos talibanes, si se mueve el ratón no estás programando

[#96 Zade]

#9 La mayoría de esas empresas usan también los “lenguajes de moda” incluso en el lado servidor. Por ejemplo hay servicios de Prime Video implementados con Swift de lado servidor porque es más rápido que el resto de alternativas.

[#44 Polarin]

#1 eh... nosotros tambien tenemos corazoncitos... aunque nos hayan hecho usar "ese" "lenguaje".

[#65 Vensier]

#1 hay muchos lenguajes modernos que usan la máquina virtual de java, como kotlin, Scala, Apache Groovy o Clojure

[#85 ur_quan_master]

#1 Java sigue siendo muy bueno para lo que es.
Por otro lado, como dice la coplilla: C y C++ son de la famila... Y a Rust lo encontré en la calle.

[#119 Toponotomalasuerte]

#1 hasta ahí mismo llegue yo, ni el enlace pulso. Jijijiji

[#153 enriquefriki]

#1 me lo has quitado de la tecla

[#3 diablejo]

yo lo que no sé es si fiarme de lo que dice USA en materia de seguridad.

[#4 frg]

#3 Espero más Rush en el kernel de linux. Solventa muchos de los problemas existentes con drivers de todo tipo y condición.

[#42 meneandro]

#4 Las prisas no son buenas...

[#59 prejudice]

#4 git también está escrito en C
Aunque tiene menos complejidad que el kernel de Linux y la verdad no creo que necesite mejoras, ya es un herramienta perfecta

[#66 Razhan]

#59 para mi git es lo que realmente demuestra la genialidad de Linus como desarrollador.

[#129 neo1999]

#66 Debería delegar su responsabilidad en el kernel y crear o colaborar más en otros proyectos que falta les hace.

[#223 frg]

#59 No se, git es importante, pero cualquier driver del kernel te puede tirar una máquina por una mala gestión de un puntero.

[#7 Fingolfin]

#3 Pues en este caso no les falta razón

[#14 tpm1]

#3 Pues deberías saber que esta gente tiene, o tenía, manuales bastante buenos para el público de como asegurar equipos linux y Windows.

[#190 ochoceros]

#3 Es como cuando te dice el del banco que inviertas en algo, hay que hacer exactamente lo mismo: Lo contrario.

[#8 Desactivado]

Para mi es de obligatorio aprendizaje C .
Luego a nivel empresarial o personal, cada uno que elija lo que quiera, pero C es obligatorio para entender el sistema en el que programas

[#12 Aeren]

#8 C está muy bien para aprender las bases del desarrollo de software y para cacharritoso como arduino y otros controladores robóticos. Luego ya con esa base puedes ir aprendiendo el lenguaje que toque según las necesidades de la empresa. Luego en las entrevistas de trabajo ya te pueden pedir 15 años de experiencia en ruby, .net, o lo que sea que esté de moda, que leyendo un par de libros te puedes apañar en una semana.

[#18 Desactivado]

#12 Sin C no hay Unix,ni iOS, ni Android, ni Linux, ni BSD, ni Mac OS.

[#35 tul]

#18 ni windows

[#64 j0seant]

#18 tampoco tendríamos los interpretes, compiladores o maquinas virtuales de otros lenguajes, ya que la grandísima mayoría están escritos en C/C++

[#144 Desactivado]

#18 ¿y? has necesitado alguna vez leer o modificar el código de esos sistemas?

[#162 MaesK]

#18 No está diciendo que C no sea o haya sido útil ni esté en desuso. Sólo dice que para el común de los mortales no hace tanta falta. Creo que el contexto del mensaje se entiende bien sin necesidad de sentirse ofendido.

[#115 Powertrip]

#12 no conozco a nadie que leyendo un par de libros de java en una semana sea programador java. Me tenéis hasta las ***** los que os creéis gurús del C, ensamblador y código binario y lo demás es m**rda

[#118 Jesulisto]

#8 C te enseña a pensar como un programador "de verdad", en el día a día puedes usar lo que sea pero hay un antes y un después de aprender y programar en C.

[#10 abnog]

Si lo recomienda la NSA, ya sé lo que NO tengo que hacer.

[#58 gynovin]

#10 recomiendan cambiar a lenguajes más lentos porque así te cambias a una CPU más moderna y ahí está “su magia”.

[#146 Desactivado]

#58 Rust es equivalente a C/C++ en cuanto a rendimiento.

Java es más rápido que otros lenguajes de más alto nivel, incluído Go.

[#43 superhiperdimensional]

La NSA dando consejos de seguridad tiene la credibilidad del oso Yogi dando consejos sobre donde guardar los emparedados..

[#209 dnnd]

#43 Quiero ver aquí al comentario ese de que lo que dices es un argumento poco técnico. A ver si lo intentan.

[#17 Leni14]

Razón de más para usar C y C++.

[#149 Desactivado]

#17 buen argumento técnico. Sí señor.

[#2 Socavador]

Es que así no hay quién espíe tranquilo...

[#34 Desactivado]

#32 https://github.com/gorhill/uBlock/wiki/Does-uBlock-Origin-block-ads-or-just-hide-them%3F

Despejando dudas.

Sí, bloquea las peticiones. Lo mejor para ello es ir a los ajustes de UBo y descargar los recomendados y actualizarlos.

[#80 Desactivado]

Esto es como si el lobo viniera a decirle al pastor como guardar las ovejas.

[#76 overhead]

De Rust no tengo ni idea de como funciona, pero de Java lo que quieren es enchufar la puerta trasera en la maquina virtual que es de Oracle (curiosamente empresa americana que abre el culo si se lo pide la NSA) y controlar todo sin que puedas hacer nada por evitarlo. Se les ve el plumero a kilómetros de distancia.

[#151 Desactivado]

#76 ninguna empresa en las que he trabajado usan la máquina virtual de Oracle. Tienes muchas de alternativas de código abierto con un rendimiento tan bueno como la de Oracle (que también tiene sus versiones de código abierto): https://en.wikipedia.org/wiki/List_of_Java_virtual_machines#Active

[#28 Desactivado]

#16 Lo importante es que era la única opción para poner gráficos y animaciones en la web.

¿lento? Vale.

[#94 Azrapse]

Al margen de que esté hablando de putas La Tacones (NSA), el hecho es que Rust tiene el mismo escenario de uso que C/C++, pero su gestión de memoria es más robusta y no le deja al programador pegarse un tiro en el pie con tanto entusiasmo como C/C++ lo hacen. Y es igual de rápido.

Por muy buenos que hayan sido C/C++, y sean los cimientos de casi todo, son lenguajes anticuados, que han sido "actualizados" una y otra vez de la forma más ortopédica y frankenstein imaginable. Un programa moderno en C++ da asco leerlo, por la cantidad de "ruido" absurdo que conlleva hacer las cosas bien sin que ser vaya todo al garete en temas de librerías, referencias, gestión de memoria, etc.

Me recuerda a la programación en PHP y Javascript modernas, que para tener algo decente y robusto, te tienes que montar un pifostio en andamiaje y seguir unas prácticas a rajatabla. O si no, el caos.

[#139 neo1999]

#94 Cual sería la alternativa a PHP y JavaScript al estilo Rust? Existe algo similar?

[#178 jimyx17]

#c-94" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3749542/order/94">#94 Si.... pero. Rust no está listo. Sencillamente no esta listo. Hay partes del propio lenguaje que están literalmente a medias. Solo hay que mirar cuando lo quieres usar a bajo nivel, como los commits para la versión 6.1 del kernel de linux, es prácticamente imposible programar algo en la versión estable del toolchain, hay que irse siempre a features adicionales o directamente a la nightly.
Que lo va a reemplazar, estoy casi seguro, pero le queda todavía.

Si tuviese que llevar un proyecto nuevo ahora mismo, probablemente tendría que usar C en vez de Rust.

Con respecto a la mención de java, no creo que se refieran a java en sí, sino a lenguajes con GC sin más. No creo que les importe si es java, o go, o C#, o ...

[#11 Aeren]

¿Pero Java no lleva 10 años obsoleto?

Yo me alegro de que cada vez se use menos en la web, por que vaya porculo cada vez que fallaba la versión concreta y exclusiva que había decidido utilizar el becario cutre para tál página de la administración. Entre flash y java retrasaron el avance de internet unos 10 años.

[#13 Desactivado]

#11 No. Lo actualizan.

¿Quizás hablas de Java para hacer snippets web? Ese es un uso residual de Java. Siempre lo han sido. En la actualidad es uno de los lenguajes más usados.


Por cierto, quizás sin flash hoy el uso de Internet en el mundo sería sensiblemente inferior. Gracias a flash se llevaron las animaciones, los gráficos y los juegos a la web. Tampoco retrasó nada, su problema fue de agujeros de seguridad

[#16 Desactivado]

#13 Flash era una mierda para invidentes y algunas animaciones bajo ADSL tardaban la vida en tirar. Yo era el rarito usando Lynx/Links, no lo niego, incluso Opera a veces. Pero mucha gente con RDSI las pasaba putas por esa peste.

Ahora las webs siguen tirando mierda, pero al menos con UBlock Origin reduces, literalmente, el ancho de banda de anuncios en un 90%.

He probado un navegador de terminal con soporte de JS via QuickJS. Bien, gracias a un fichero de /etc/hosts capando publi y demás cosas, Menéame tira a 2.7 KBPS. Hacer eso mismo en un fichero de /hosts hace que en vez de tardar unos 10-15 segundos en el cacheo inicial se tire mucho más haciendo imposible leer nada.

Pero es que incluso con fibra se satura la conexión con los anuncios. Imagina un mundo con anuncios Y Flash.

[#32 mecha]

#16 "con UBlock Origin reduces, literalmente, el ancho de banda de anuncios en un 90%."

¿Sabes que los anuncios se descargan igual en gran medida y que ublock solo hace que no los veas?

[#33 Desactivado]

#32 Creo que UBlock Origin también bloqueaba conexiones.

https://github.com/gorhill/uBlock/wiki/Strict-blocking

Definitvamente si lo pones en ajustes avanzados nada debería conectarse.

Yo por lo menos tengo bloquadas las peticiones a terceros.

[#36 tul]

#32 ein, no, para nada, no llegas a descargarlos.

[#37 Desactivado]

#36 Puede ser que #32 confunda Adblock con Ublock Origin. Y no, UBo trabaja de forma diferente.

[#95 vorotas]

#16 Prueba con una raspberry y Pi hole, y si quieres enfrascarte más Pihole + Unbound. UBlock lo tengo también, pero el PI Hole discrimina por dominio al usarlo como servido DNS.

[#204 Desactivado]

#95 Unbound lo conozco antes que los de Linux porque llevo años en OpenBSD. No te preocupes, tengo un fichero de hosts añadido con sed sin problema.

https://github.com/stevenblack/hosts

[#15 tpm1]

#11 Confundes Java del lado cliente con Java del lado servidor.

[#47 Jajjajajjajajja]

#11 Sin Flash jamás habríamos tenido a Cálico Electrónico o Xiaoxiao

[#114 cubaman]

#11 Tú te refieres a los Java Applets. Si, eso lleva años descontinuado. Pero un montonazo de webs que visitas a diario usan Java en el lado del servidor para generar los datos o el HTML de esas páginas. Java sigue siendo un lenguaje muy popular en backend.

[#148 Desactivado]

#11 el Java asqueroso ese que se ejecutaba en tu navegador y cada día te daba por culo para actualizarse, sí.

Java en servicios sigue tan vivo como siempre.

Java es la base de Android.

Java se sigue usando en algunas aplicaciones de escritorio, como algunos de los entornos de desarrollo más usados.

[#53 lgg2]

Rust lo veo muy "diplodocus" por tamaño de herramientas, verde por como está aún en cuanto a integracion con IDEs y depuradores y que no tenga aún una librería gráfica bien definidas a estas alturas.

También es bastante "caja negra donde opera la magia" con Cargo.

[#117 loko.mdv]

#53 "También es bastante "caja negra donde opera la magia" con Cargo."
¿No lo es igual a usar cualquier libreria en cualquier lenguaje?
Que quede claro que lo digo por si hay algo más con Cargo que se me escape. De rust solo he leido alguna parte del manual para hacer un "hello world" y poco más.

[#163 SaulBadman]

#53 Para mí Cargo es una herramienta muy bien hecha. No he visto ninguna otra capaz de gestionar las opciones de compilación y la gestión de dependencias de forma tan sencilla. CMake se le acerca un poco, pero sigue siendo algo farragoso, especialmente cuando el proyecto se va a compilar en diferentes máquinas o "targets".

[#82 chavi]

Y qué tal aprender a programar y no contratar chapuceros?

[#152 Desactivado]

#82 ¿por qué poner una barandilla en la escalera? Qué tal con tener cuidado para no caerse?

[#20 torrrquemada]

Pues yo opino justo lo contrario a la mayoria.

La NSA ya tiene sus backdoors, y lo que necesita es estabilidad en los programas, ya que los "malotes" son los que buscan los errores de memoria para poder acceder al sistema.

[#68 canduteria]

Entonces c y c+ a saco. 

[#56 Ehorus]

Me quedo más tranquilo sabiendo que no han recomendado Cobol.....

[#79 Meneacer]

En esa lista falta Ada/SPARK que es lo que está usando, por ejemplo, NVIDIA.

https://www.reddit.com/r/programming/comments/yoisjn/nvidia_security_team_what_if_we_just_stopped/

[#78 Desactivado]

Dennis Ritchie estará revolviendose en su tumba.

[#49 Capitan_Centollo]

Lo lógico es que si estás programando en C o C++ sea porque la aplicación necesita un control a bajo nivel del dispositivo, ya sea por velocidad de proceso o por ahorro de recursos. Cuando programas algo a ese nivel se da por sentado que sabes lo que haces y tienes la experiencia necesaria. Lo que no pones es a un novato a hacer microcontroladores para un satélite militar, digo yo.
Ahora, si necesitas un código que se ejecute en un espectro amplio de dispositivos muy dispares entre sí, quizás sí te convenga usar una plataforma de desarrollo a un nivel más alto, que te evite quebraderos de cabeza en el testeo y tener que hacer hacks para dispositivos concretos, sobre todo si no dispones de mucho tiempo o recursos.

[#63 FooDev]

#49 No creo (no soy experto en C/C++) que la cosa se resuelva contratando expertos (en gran parte supongo porque no será tan fácil encontrarlos). De ahí que todas las grandes tecnológicas están preocupados por los exploits de memoría y estén prácticamente alineadas respecto a Rust.

[#120 loko.mdv]

#49 Hombre, por muy experto que sea nadie, al final es humano y puede introducir algun punto sensible a buffer overflow aunque sea por usar una función que se considera segura y al final no lo es o meter sin querer un memory leak.
De lo ultimo, vale, hay herramientas para depurar estas cosas como valgrind, pero yo aún no conozco a nadie que las use en el curro

[#26 ElMag0]

BoF everywhere 

[#51 Desactivado]

Imbéciles. No hay nada más seguro que C.

[#89 chavi]

#51 Desde luego. Si el programa está bien hecho solo el ensamblador lo iguala ..

[#174 NapalMe]

#89 Es gracioso porque tienes razón sin saberlo.