30 años de Java: entrevista con James Gosling, el genio detrás del código que cambió la tecnología

• James Gosling es el creador de Java y es considerado un genio práctico que ha influido en la computación moderna durante 30 años
• En un entorno de pobreza, aprendió a programar armando computadoras con piezas rescatadas de la basura, y ese aprendizaje autodirigido luego se reflejó en su filosofía de diseño de lenguajes
• Su etapa en Sun Microsystems, cuando convivían las bromas y la innovación, se convirtió en la base de la creatividad característica de Gosling y de su forma de construir cultura técnica
• Recientemente expresó un fuerte escepticismo sobre las herramientas de IA generativa y el boom de la IA, y subrayó que la importancia de la educación en programación ha crecido aún más
• El secreto de la supervivencia de Java no fue lo llamativo, sino una filosofía de diseño pragmática enfocada a fondo en la estabilidad, la compatibilidad hacia atrás y la productividad del desarrollador

---

Java at 30: The Genius Behind the Code That Changed Tech

• Java cumple 30 años este 23 de mayo como un lenguaje orientado a objetos, de alto nivel y de propósito general, y sigue siendo una tecnología clave que impulsa sistemas de todos los tamaños
• En la base de la existencia de Java estuvo el sentido práctico de la tecnología y la intuición creativa de James Gosling
• Gosling pasó de ser un adolescente canadiense autosuficiente que armaba computadoras reuniendo piezas de la basura a convertirse en un programador de talla mundial
• La filosofía de “escríbelo una vez, ejecútalo en cualquier parte” es el símbolo de Java, y se convirtió en una filosofía de lenguaje que impulsó un cambio fundamental en la forma de desarrollar software
• A lo largo de su carrera, Gosling combinó excelencia técnica, sentido lúdico y una clara conciencia ética, encarnando un perfil de desarrollador que ha influido de forma continua en la formación de la cultura de la computación moderna

James Gosling: The Brilliant Mind Behind Java

• James Gosling no es solo el “padre de Java”, sino un genio humilde capaz de explicar conceptos complejos de forma intuitiva
• Ahora, 30 años después de crear Java, repasa su recorrido tecnológico y la evolución del lenguaje y de la cultura de desarrollo

The Path To Programming: Resourceful Beginnings

• En una infancia marcada por la pobreza extrema, Gosling tuvo la experiencia de recoger televisores de la basura y desarrollar así su creatividad técnica
• Su primera computadora la ensambló con racks de relés descartados de la compañía telefónica, símbolo de su temprano sentido mecánico y habilidad para construir cosas
• Al visitar el centro de cómputo de la Universidad de Calgary, quedó fascinado por las pantallas, las luces parpadeantes y las unidades de cinta, y ahí comenzó su curiosidad de toda la vida por la programación
• Aprendió por su cuenta revisando tarjetas perforadas para conseguir contraseñas, y en la preparatoria escribió programas de análisis de datos satelitales para el departamento de física de la universidad, acumulando la experiencia de disfrutar programar mientras le pagaban por ello
• Su experiencia inicial en programación abarcó PL/1 en mainframes de IBM, Fortran, ensamblador de PDP-8 y código para CDC 6400. Con su tono sobrio característico, comentó de pasada que “en verano trabajó desarrollando un compilador de COBOL”, una tarea que incluso muchos programadores veteranos encontrarían difícil

Academia to Industry: Finding His Way

• Gosling describió la academia como “un laboratorio que usa estudiantes de posgrado como mano de obra barata”, mostrando una visión directa que prioriza lo práctico sobre lo teórico
• Incluso durante su doctorado en Carnegie Mellon trabajó en startups para ganar experiencia real, y luego terminó el grado, concretando una trayectoria flexible que combinó industria y academia
• Su primer empleo fue en IBM Research, pero la describió como “una empresa dedicada a dispararse en el pie”, manteniendo una actitud de análisis frío sobre la gestión empresarial y la estrategia tecnológica
• Estas experiencias tempranas se convirtieron después en una base de comprensión de una cultura organizacional centrada en la realidad, que influyó en su forma de trabajar en Sun Microsystems

The Sun Days: Innovation and Pranks

• Entre sus recuerdos más divertidos de Sun, Gosling destaca los grandes proyectos de bromas de April Fools’ que se hacían cada año, recordando una cultura organizacional donde convivían creatividad y diversión
• Un ejemplo famoso fue poner a flotar un Ferrari sobre una plataforma en un estanque, caso que mostró sentido del humor apoyado en capacidad de resolver problemas de ingeniería y trabajo en equipo
• Otra broma fue construir en la oficina del CEO un campo de golf de un hoyo con césped artificial, bunker y obstáculo de agua, mencionado como un intento original que combinaba tecnología y juego
• Gosling recuerda a Sun como “un entorno poco común donde se permitían al mismo tiempo la excelencia técnica y la creatividad juguetona”, y eso se convirtió en la base de su enfoque general para resolver problemas y de su actitud hacia la tecnología

Java: Creating a Legacy That Changed Everything

• El recorrido de 30 años de Java es para Gosling su logro más representativo y el punto de inflexión decisivo de su vida tecnológica
• Menciona la profunda satisfacción por el impacto que dejó en el ecosistema de desarrolladores cada vez que alguien en la calle le dice: “Conseguí mi carrera gracias a Java”
• Quiso incluir funciones como lambdas y genéricos desde el principio, pero ajustó su incorporación según la filosofía de diseño de “no meterlas de la manera equivocada”
• Sobre la gestión de Java por parte de Oracle, dijo que “lo hicieron mejor de lo esperado”, y enfatizó que en realidad la participación y la contribución continua de la comunidad han jugado un papel clave
• Java ha evolucionado para optimizarse para entornos cloud y ha alcanzado un nivel técnico “realmente impresionante” en soporte multicore, manejo de memoria y mejoras del GC

Beyond Java: Ventures After Sun

• Después de la adquisición de Sun por Oracle, Gosling descansó un tiempo, entró a Google y renunció seis meses después para irse a Liquid Robotics
• Ahí desarrolló sistemas de control para robots marinos autónomos y vivió condiciones de trabajo únicas que combinaban tecnología y naturaleza, como tareas que requerían hacer snorkel en Hawái
• Participó en proyectos para monitorear temperaturas oceánicas en el Ártico y la Antártida, pero la investigación ambiental tenía poco financiamiento y chocó con la estructura de una startup respaldada por venture capital
• Ante la presión de virar hacia el sector defensa, renunció por razones éticas y luego trabajó en AWS en el proyecto Greengrass y en herramientas de desarrollo, manteniendo una trayectoria que combinó interés técnico y criterios éticos

On Open Source and Industry Trends: Cutting Through the Hype

• El open source se describe como un ecosistema complejo que va más allá de una simple herramienta de colaboración, y funciona también como relación con desarrolladores, estrategia de marketing y modelo de adopción bottom-up
• Sobre la tendencia low-code/no-code, expresó escepticismo diciendo que es una idea repetida desde la época de COBOL, y la ve como un enfoque especializado con límites al aplicarse a dominios complejos
• Sostiene que en IA y machine learning el problema está más en el nombre que en la tecnología, y plantea una crítica terminológica: que “técnicas estadísticas avanzadas” describe mejor la esencia
• Afirma que la IA es solo una herramienta y no debe confundirse con una entidad autónoma, y que debe entenderse como una herramienta avanzada para asistir al trabajo humano, no para amenazarlo

Developer Tools and Preferences: Embracing Progress

• Gosling usa NetBeans IDE como herramienta principal de desarrollo y muestra apoyo al open source bajo licencia Apache y a una comunidad activa
• Respecto a quienes siguen aferrados a Vi o a herramientas de los 70 y 80, expresó cierta frustración ante una actitud que rechaza el progreso tecnológico
• Aunque a veces usa Vi porque puede ejecutarse en cualquier lugar, apoya con fuerza el uso de IDE modernos para entornos de desarrollo serios

The JVM Vision: From Academic Concept to Global Standard

• El concepto inicial de la Java Virtual Machine (JVM) surgió en la época de posgrado de Gosling, a partir de experimentos con formatos de distribución neutros respecto a la arquitectura y de investigación sobre traducción de instrucciones
• Más adelante eso evolucionó no solo para Java, sino hacia una tecnología de plataforma de ejecución de propósito general capaz de correr varios lenguajes en distintos tipos de hardware
• La filosofía de ‘Write once, run anywhere’ fue rechazada al principio como tema de tesis doctoral por falta de base matemática, pero terminó convirtiéndose en una tecnología práctica que cambió el entorno mundial de desarrollo de software

More Recent Work: Bridging IoT Gaps at AWS

• En AWS, Gosling participó en el desarrollo de Greengrass, un framework de aplicaciones IoT, materializando un enfoque técnico que simplifica con elegancia problemas complejos
• Abstrajo trabajos repetitivos y boilerplate entre despliegue y operación, como actualizaciones OTA, control remoto, telemetría, confiabilidad de red, seguridad y gestión de autenticación
• El código del lado del dispositivo se publicó como open source, promoviendo aportaciones de la comunidad para portar la tecnología a plataformas no prioritarias para Amazon, como RISC-V
• Otro proyecto de herramientas de desarrollo en el que participó después se canceló al quedar atrapado por el boom de la IA, lo que sugiere problemas derivados de una confusión guiada más por la moda que por la autenticidad técnica

AI Skepticism

• En entrevistas recientes, Gosling se refirió a la revolución de la IA como “en su mayoría un fraude”, mostrando una mirada escéptica que ve a la IA como un término de marketing tóxico
• Aunque reconoce que se trata de una tecnología matemáticamente impresionante, señala que el nombre IA oscurece la verdadera naturaleza técnica de estas herramientas como técnicas estadísticas avanzadas
• Critica con dureza la fiebre de la IA impulsada por venture capital, llamándola “un punto de reunión de estafadores y vendedores de humo”, y denuncia la búsqueda de ganancias rápidas centrada en el exit más que en tecnología realmente útil
• También advierte que la mayor parte del dinero invertido en IA terminará “tragado por un agujero negro”, como alerta sobre un flujo de capital guiado por modas sin sostenibilidad

Is It a Vibe? AI Coding Tools: Impressive Demos, Limited Utility

• Las herramientas de código con IA generativa causan una fuerte primera impresión, pero tienen una estructura limitada que falla apenas la tarea se vuelve un poco más compleja
• Estas herramientas solo pueden raspar y repetir muestras de código existentes, y los problemas realmente interesantes siempre son nuevos, por lo que no encajan bien con herramientas basadas en la copia
• En entornos de desarrollo profesional, el código patrón tiende a converger en bibliotecas, así que la generación de código por IA choca estructuralmente con las necesidades reales del desarrollo
• Gosling define el verdadero valor de la IA como una herramienta de búsqueda que se hace cargo de la documentación que nadie quiere escribir, destacando su utilidad como apoyo especializado para explicar cómo usar APIs

Java’s Evolution: Language Features and Runtime Improvements

• Entre los cambios recientes del lenguaje Java, mejoras como la inferencia de tipos y la forma de declarar arreglos son evaluadas como extensiones útiles que aumentan la comodidad de desarrollo
• Sin embargo, Gosling enfatiza que el avance más impresionante de Java está en la mejora de la calidad del entorno de ejecución JVM y de la biblioteca estándar
• La JVM moderna muestra un rendimiento de ejecución que ha llegado a un nivel “asombroso” en calidad de código, rendimiento de hilos y garbage collection
• Señala también que, en manejo de memoria y predictibilidad de rendimiento, es más eficiente que C basado en malloc, y menciona la posibilidad de ajustar las pausas del GC hasta unos pocos milisegundos
• La JVM actual se evalúa como un entorno de ejecución de alto rendimiento capaz de manejar de forma estable espacios de memoria absurdamente grandes

Programming Languages for Critical Infrastructure

• Ante la pregunta de en qué lenguaje debería reescribirse el sistema de control aéreo de la FAA, Gosling rechaza la premisa, diciendo que sería como “construir una casa eligiendo primero el martillo”
• Enfatiza que antes hay que entender claramente las propiedades del dominio del problema, como sistemas de comunicación, normativas internacionales, rutas de vuelo y evasión de colisiones, y solo después elegir la tecnología
• Aun así, agrega que para sistemas grandes donde la confiabilidad es crítica, Java puede ser un candidato fuerte

The Future of Programming in an AI World

• Aunque la IA siga avanzando, Gosling sostiene que la programación seguirá siendo una habilidad esencial, y afirma que si tuviera hijos, sin duda les enseñaría a programar
• Critica las afirmaciones de ejecutivos de big tech que dicen que la IA reemplazará a los desarrolladores humanos, calificándolas como amenazas defensivas para intensificar el trabajo
• Desarrolla la idea de que para entender bien los sistemas se necesita capacidad de programación, y que aunque una máquina haga parte del trabajo, la base de comprensión técnica humana debe mantenerse

Java’s Longevity Secret

• Como razones de la supervivencia de Java durante más de 30 años, Gosling menciona la capacidad de resolver problemas reales, el respeto por el usuario, la compatibilidad hacia atrás, la mejora de productividad y una filosofía centrada en la confiabilidad
• Siempre ha priorizado la utilidad práctica constante por encima de las modas del lenguaje, y su filosofía de diseño centrada en la realidad, enfocada en resultados más que en estilo, fue especialmente efectiva en entornos empresariales
• Desde la perspectiva de que el software “siempre debe funcionar correctamente”, Java sigue siendo una herramienta de ingeniería honesta y práctica

Oracle’s Stewardship: Better Than Expected

• Gosling dijo sobre la gestión de Java por parte de Oracle después de la compra de Sun Microsystems que “lo hicieron mucho mejor de lo que pensaba”, expresando sorpresa por un desempeño que superó sus expectativas
• Al principio temía “despojo y saqueo” por el historial pasado de la empresa, pero terminó valorando positivamente que no interfiriera con el equipo de Java y lo protegiera, preservando independencia y foco técnico
• Aunque señaló que faltó apoyo financiero, le dio una alta calificación al hecho de que se mantuviera una estructura que garantizaba la autonomía del equipo técnico sin interferencia corporativa

Crab Lovers Unite!

• Gosling ha dicho que quiere trabajar con la gente con la que le gustaría sentarse a comer, mostrando una actitud que valora criterios de colaboración centrados en las personas
• El periodista se encontró por casualidad con Gosling en Thanh Long, un restaurante de cangrejo en San Francisco, y dejó registro de ese momento en que una figura gigante del mundo tech aparece en una escena cotidiana
• Después ambos comieron cangrejo y conversaron juntos, y al prometer volver a verse en el mismo lugar transmitieron la calidez de un intercambio humano que va más allá de la tecnología

[cosine20]

Yo también creo que, entre los lenguajes de tipado estático, Java es el más cómodo y fácil de usar.

Aun así, desde el punto de vista del desarrollo general y práctico, escribir en Java aplicaciones orientadas al usuario final con GUI no era una muy buena elección. (Desde esa perspectiva, la combinación de C# + .NET es la mejor de todas).
Considerando las ventajas de Java, creo que el caso más adecuado en términos prácticos es usarlo en backend o middleware.

En fin, como de vez en cuando me toca usarlo, siento que siempre es un lenguaje que puedo manejar sin demasiada carga, así que me quedan más experiencias positivas con él.

[mhj5730]

La historia de que programaba desarmando televisores sacados de la basura suena como el puro inicio de una leyenda.

[ndrgrd]

Es cierto que, después de Java, los lenguajes empezaron a enfocarse en la productividad.

Antes de eso, C++, que se usaba mucho, todavía hoy es terrible incluso solo de leer. Sobre todo cuando te toca meter mano en proyectos de larga duración.

[3ae3ae]

Me cuesta estar de acuerdo con que Java priorizara la productividad del desarrollador.
¿Hay otro lenguaje que haya evolucionado hasta depender tan profundamente de un IDE como Java?

[3ae3ae]

Hice un comentario imprudente.

[sunrabbit]

Depender profundamente del IDE es un problema del ecosistema de Java, que ha evolucionado de forma poco ideal,
no un problema a nivel de diseño.

Dicho mal y pronto, hoy en día para desarrollar en Java no hace falta usar a la fuerza un producto de JetBrains,
pero igual que todos lo usan.

Y si miras la lista de lenguajes de programación de cuando apareció Java, había muchos lenguajes con implementaciones dependientes de la plataforma, es decir, del sistema operativo.
Java fue el que mostró la dirección que luego seguirían lenguajes como Node, Python y C#, capaces de ejecutarse en varios sistemas operativos con el mismo código.

Hoy en día, la compatibilidad de correr el mismo código en distintos sistemas operativos es algo tan obvio que ya es "sentido común".

[roxie]

> Francamente, hoy en día desarrollas en Java y tampoco es que necesariamente tengas que usar productos de JetBrains.

En esta parte... me cuesta un poco estar de acuerdo, sniff sniff...

[kwj9211]

Ahora parece algo bastante natural,
pero cuando salió Java, ¿no habrá sido ya una ayuda bastante grande para la productividad el solo hecho de soportar de forma estable múltiples plataformas sin necesidad de una nueva compilación?

[angrycoder]

Parece que, en comparación con los lenguajes anteriores a Java, la productividad es mejor.

[ahwjdekf]

c++ > c# >= java

[cosine20]

C# >= Java > C++

[GN⁺]

Comentarios de Hacker News

• Java no tiene el mejor rendimiento del mundo, pero existe la percepción de que está más o menos en tercer lugar después de C/C++, lo cual no está nada mal; incluso sería más rápido que Go y más de 10 veces más rápido que Python o Ruby. También gusta que, aunque la sintaxis de Java no sea perfecta, sí sea consistente y predecible. Con herramientas como Idea o Eclipse, no hay que preocuparse por la productividad. Su modelo de gestión de memoria difiere de la filosofía Unix, pero una vez que se entiende, parece un compromiso razonable. Se valora esa practicidad: gracias a esos trade-offs se obtiene velocidad y seguridad de memoria, junto con ventajas como llamadas dinámicas y hotswap.
  • Se nota que herramientas como IntelliJ para Java ofrecen un entorno extraordinariamente superior frente a otros lenguajes. Da curiosidad por qué la comunidad de Go no parece muy entusiasmada con desarrollar contenedores de estructuras concurrentes. En Java existe una cultura de recomendar excelentes contenedores para programación concurrente, algo envidiable, y a veces se extrañan java.util.concurrent o JCTools.
  • Recién salido de la universidad, uno pensaba que Java servía para todo, pero después entendió que lo realmente adelantado a su tiempo eran la JVM y el tooling de Java App Server. El lenguaje en sí resultaba decepcionante antes de las mejoras de productividad de 2006~2007. Hoy interesan otros lenguajes que corren sobre la JVM, como JRuby, Clojure, Scala, Groovy y Kotlin. JRuby llama la atención porque permite usar dos ecosistemas maduros a la vez. Que Project Loom haya hecho posible usar las fibers de Ruby en la JVM beneficia a ambos lados. Los logros de Charles Nutter están subestimados.
  • Se dice que Java es más rápido que Go, pero en la práctica muchas veces Go resulta más veloz o usa entre 2 y 10 veces menos memoria, así que estarían en un nivel parecido. Los value type de Go facilitan la optimización. Llama la atención que se mencione específicamente a Go, y considerando que C# es más rápido que Java, se concluye que Java no estaría en tercer lugar sino más bien en quinto.
  • Se valora mucho cómo sealed class, switch expression, Project Loom y records, introducidos recientemente en Java, se integraron de forma natural con la sintaxis existente. También se percibe que las herramientas de diagnóstico de Java, como los analizadores de heap dump y de GC, están entre las mejores.
  • Se señala que los rankings de rendimiento entre lenguajes cambian según qué se incluya y cómo se compare, y se remite al enlace de benchmarks compartido.
• Java (JVM) es de esas tecnologías que uno termina valorando más después de probar otros lenguajes/ecosistemas que estuvieron de moda por un tiempo. Se repite la sensación de que, en realidad, era solo el típico “el pasto del vecino parece más verde”. Rust sí pareció un lenguaje realmente muy avanzado y placentero de usar. Da pena que hoy Java no sea visto como un lenguaje “cool” en startups, y se piensa que la brecha de productividad casi ha desaparecido.
  • Tras usar Rust a tiempo completo durante dos meses, al menos en desarrollo de servidores no se entiende eso de que dé “alegría” frente a Java. Con Rust hay demasiados momentos en los que los problemas de lifetime sorprenden y bajan la productividad. Sin duda transmite una fuerte sensación de seguridad de tipos, pero en conjunto cuesta decir que sea una experiencia realmente divertida.
  • C# va muy por delante de Java y se diferencia de maneras significativas, como genéricos mucho mejor implementados, value type desde hace muchísimo tiempo y una FFI conveniente. Fuera de Unity, sin embargo, parece que a la gente no le importa demasiado, y se cree que Microsoft fracasó hace años en posicionarlo mejor en la conciencia popular.
  • Esta sensación se debería a que el tamaño de los proyectos es distinto. Cuando uno pasa de un enorme proyecto legado de Java con 10 años encima a un proyecto “nuevo” del tamaño de hello-world, claro que todo se ve mejor. Un gran rewrite ayuda incluso en revisiones de seguridad, pero por lo general las empresas no tienen margen para eso; solo excepciones como Google.
  • La misma sensación: Go fue decepcionante. Prometía todo, pero al final daba la impresión de ser parecido a Java o incluso más atrasado, por ejemplo con errores sin stack trace.
  • A mitad de casi 30 años de carrera, los 2 años en que se intentó trabajar en proyectos fuera de la JVM fueron la peor etapa profesional.
• Agradecimiento por los logros de James Gosling. Gracias al Java World Tour, alguien apareció como primer resultado al buscar “Java consultant” y pudo mantener una vida estable trabajando remoto desde el campo. Hay muchísimas personas cuya vida fue positivamente impactada por Java. También se admira el gran trabajo del equipo de Clojure construyendo un excelente ecosistema sobre la JVM.
  • También se agradece a James Gosling. En 1995, trabajando con C++ en Taligent, probar Java por primera vez resultó asombroso. Tras la disolución de Taligent, esa persona pasó mucho tiempo vinculada a Java y software relacionado.
  • James Gosling (Java) y Rich Hickey (Clojure) son vistos como creadores que aportaron aire fresco al mundo de la programación en sus respectivas épocas.
• Aunque en años recientes se ha trabajado con .NET/C#, en general la sensación es que JVM/Java es el mejor ecosistema que se ha probado. Java ha resuelto muchas más cosas de forma correcta. Por ejemplo, Java resolvió la división del trabajo con fork/join pool, mientras que .NET simplemente metió work-stealing en un thread pool global, lo que hace que el código sync-over-async provoque deadlocks generales con facilidad. En una base de código grande, pedir una conversión total de código síncrono a asíncrono es prácticamente imposible. Del lado de Java, incluso si hay errores a nivel de librería o framework, se suelen superar pronto; en .NET, si el problema está en la librería estándar, el lenguaje o el runtime, es mucho más difícil arreglarlo. Java acertó con muchos estándares base.
  • La thread pool starvation en .NET resulta muy irritante, aunque se dice que últimamente impacta menos. Se piensa que es imposible una implementación totalmente inmune al mal uso del thread pool; lo único viable es aumentar threads o ajustar inteligentemente el orden del trabajo. Quien comenta aclara que no es especialista en thread pools.
  • Se pensaba que .NET había estado copiando los enfoques exitosos del ecosistema Java, pero en realidad hay muchas diferencias.
  • Se objeta que no es justo mencionar problemas de deadlock sin escribir nada de código .NET, y que basarse en una entrada de blog de hace 13 años tampoco resulta convincente.
• Java es visto como un caso de éxito extraordinario. Pero James Gosling habría sido el punto de partida, no el líder real. Desde la época de Java 1.1~1.2, Mark Reinhold lideró de forma decisiva la integración del JIT, el desarrollo de HotSpot, el enorme incremento de clases en 1.2, y después de la compra por Oracle impulsó soporte para lenguajes dinámicos, open source, lanzamientos rápidos y las bases de las funcionalidades modernas del lenguaje. Se considera que las fortalezas de Java existen gracias al liderazgo de Mark Reinhold.
  • Todo el equipo principal de desarrollo resulta impresionante. Gosling quería un lenguaje práctico, y después gente como Mark Reinhold y Brian Goetz lo fueron haciendo evolucionar de forma amigable para los desarrolladores. Oracle puede no gustar, pero se agradece que haya permitido avanzar a un grupo tan sobresaliente.
  • Se señala que Kotlin, como Java, es un lenguaje de tipado estático, no un lenguaje dinámico.
  • Incluso si Linus hubiera hackeado git en solo dos semanas y solo hubiera aportado la chispa inicial, el hecho de que luego la comunidad lo expandiera demuestra que evaluar algo solo por su punto de partida es incompleto.
• Como ingeniero de software de más de 40 años, parece sensato elegir herramientas que simplemente “hacen el trabajo”. Hoy Java o C# cumplen bien ese papel. Personalmente, C# da la impresión de tener un ecosistema mejor integrado. Para cualquier caso de uso, en un minuto se puede crear una app en C#. El lenguaje evoluciona rápido, hay estabilidad en la disponibilidad de talento y .NET también soporta multiplataforma. La elegancia y eficiencia del lenguaje hacen más fácil el trabajo.
• Se recuerda haber simulado código de SO en Java en la universidad. Para estudiar algoritmos abstractos se entiende que Java puede servir al reducir complejidad, pero personalmente se piensa que Python habría sido más adecuado. Por la influencia de la industria, no convence insistir en Java como única opción en la educación inicial universitaria. Como ya se había visto BASIC y C en secundaria, simular código de bajo nivel de SO en Java se sintió como un paso atrás.
  • En la universidad, alguien aprendió microcontroladores en C, estructuras de datos/OOP en Java, y conceptos de sistemas/SO/concurrencia en C y ensamblador MIPS. Para estructuras de datos y algoritmos, Java distingue con más claridad los tipos abstractos y la estructura que Python, así que incluso puede ayudar a formar conceptos más precisos. Pero enseñar conceptos de SO en Java sí parece un poco excesivo.
  • Se opina que las desventajas educativas de Java que mencionó Joel también aplican a otros lenguajes de alto nivel como Python, y se resalta irónicamente que MapReduce (hecho por Google en Java) se adelantó a Microsoft.
• Se reconoce el éxito de Java, pero persiste un fuerte rechazo por varias razones: la herencia de código verboso en grandes empresas, frameworks complejos y código de baja calidad. Se detestaba esa cultura en la que el código se producía “como carbón”, sin pasión ni personalidad. La JVM parecía una caja negra internamente, dificultando depuración con herramientas como strace o gdb, y el sobreaprovisionamiento de memoria complicaba que el kernel entendiera bien la carga. También se percibía que, al usar la JVM, sin ayuda de expertos era fácil terminar con problemas graves. Además, Oracle, las licencias, la gestión de versiones del JDK, la falta de una imagen atractiva en 2025 y el peso del código legado se ven como puntos negativos. En lo personal, se ha construido una carrera evitando Java en lo posible. Hoy existen muchos lenguajes de alto rendimiento basados en compilación estática y ejecutables pequeños con menor complejidad operativa, por lo que el papel de soluciones como la JVM o la VM de Python parece ir reduciéndose.
  • La JVM ofrece capacidades de depuración dinámica de nivel mundial: reinicio de frames, cambio de variables, breakpoints de excepción y mucho más. La integración con IDEs como Idea/Eclipse tampoco tiene comparación frente a otros lenguajes. También hay muchísimas herramientas de diagnóstico como JMX/JConsole, Java Flight Recorder, jstack, HPROF, etc. Se apunta además que la licencia open source no impone restricciones de uso y que comprar la JVM de Oracle es una elección opcional. Se pregunta incluso cuál sería exactamente el problema con el código legado.
  • Decir que JAVA no tiene “cool factor” no resulta convincente. En lugar de strace/gdb, las herramientas del JDK y los IDE son abrumadoramente superiores.
  • Aunque al principio las herramientas puedan parecer difíciles en la superficie, es fácil acostumbrarse. Incluso se afirma que en una semana ya se puede ser experto en tuning de GC. Como el GC gestiona con un contexto mejor a nivel de aplicación que el kernel, ofrece ventajas reales, aunque se admite cierta complejidad adicional de aprovisionamiento.
  • Tras más de 20 años usando Java, nunca se necesitó strace/gdb, y el soporte de depuración/IDE es muy potente. Poner Python y la JVM al mismo nivel en rendimiento no es apropiado.
  • Probablemente esa opinión viene de no haber usado realmente Java con profundidad, y se reafirma que las herramientas de depuración y diagnóstico de Java están entre las mejores.
• Se menciona que, cuando Gosling estaba en Sun, codiseñó el sistema de ventanas NeWS. NeWS estaba basado en PostScript y permitía que los clientes enviaran programas al servidor. Al diseñar Java, parece haber quedado la huella de querer ver las páginas web como algo programable, igual que en NeWS. De hecho, al preguntarle en un ejemplar firmado de "The Java Programming Language" si “Java era la venganza de NeWS”, Gosling respondió con una sonrisa.
  • Así como X tuvo a Wayland como sucesor, NeWS terminó teniendo algo parecido a navegador+JavaScript (PWA, Electron). Al final parece que el enfoque de NeWS ganó incluso en el entorno de Microsoft, y da curiosidad saber qué pensará Gosling.
  • Hubo algo parecido con Display PostScript. En una combinación SPARCStation+SPARCprinter, toda la lógica de impresión se procesaba en el servidor. Si fallaba el servidor o la impresora, colapsaba todo el sistema. La integración entre print server e impresora era una pesadilla y solo aumentó la desconfianza hacia las impresoras. Se extrañan SunOS y el ecosistema SPARC, pero Display PostScript no se extraña en absoluto.
• Durante buena parte de la carrera se ha programado sobre la JVM. Últimamente se ha usado Scala, Clojure (de preferencia), Kotlin y otros en lugar de Java. Hace poco, tras quedar desempleado, se aceptó una oferta laboral en Python. Se nota que la demanda por experiencia en la JVM está disminuyendo. De todos modos, mientras llegue el sueldo, cualquier lenguaje está bien. Actualmente el proyecto personal va en Scala.

[roxie]

Parece que el bando de C# estaba escondido por ahí.