¿Por qué las startups evitan Java?
(news.ycombinator.com)¿Por qué las startups evitan Java? respuesta a una pregunta publicada en HN
- La razón principal es que el ecosistema de Java está roto; Maven/Gradle y similares son terribles.
- Lo evitan por los desarrolladores que siguen a Spring.
- Porque confunden Java con hibernate/springboot.
- Java es programación corporativa aburrida, no algo moderno y popular como Rust.
- Si tienes que usar la JVM, es mejor usar otros lenguajes como Kotlin o Clojure.
- Decir en 2022 que tu nueva startup usa Java es como decir que usa Cobol.
- Alguna vez fue cool y estaba de moda, pero entonces apareció Oracle.
47 comentarios
Un voto a favor al final. Después de que Oracle se lo quedó, empezó a retroceder
Todos saben perfectamente que no pueden asumir esos costos ni ese nivel de personal, así que... ¿de qué están hablando?
Maven/Gradle y demás son terribles
Esto sugiere que se nota el nivel del autor al ver esto
Gracias por sus consejos, colegas.
La ventaja de que sea fácil contratar también puede convertirse en la desventaja de que postule literalmente cualquiera.
Habrá veteranos que dominaron la JVM, incluso pasando por Kotlin y Scala, y también habrá personas del sector SI con más de 10 años de experiencia en Java, pero sin intención de mejorar técnicamente, que ni siquiera conocen la Stream API y siguen estancadas en la sintaxis de aquella época. Si se contrata con Go o Rust, da la impresión de que la proporción de los segundos se reduciría bastante. Con Python no estoy tan seguro...
Pasarse de Java a Kotlin no es difícil, y pasar de JSP a Thymeleaf tampoco lo es. Solo está la incomodidad de la falta de referencias. Sea lo que sea, primero intenten trabajar con objetos, herencia y diseño estructural. Depender de librerías o herramientas auxiliares no demuestra más que uno todavía es principiante.
Personalmente, me parece que en Java hay una gran asimetría de información por lo larga que es su historia.
Como fue un lenguaje que marcó toda una época, todavía queda muchísimo contenido producido en ese entonces, y aun después de tantas actualizaciones de versión, da la impresión de que ese material sigue reproduciéndose como si todavía fuera vigente.
Recuerdo que hubo muchas dificultades para encontrar nuevos enfoques acordes con las versiones más recientes.
No es que en otros lenguajes no pase, pero si tuviera que elegir lenguajes muy fragmentados, diría que Python y Java encajan perfectamente.
Sin embargo, como Python es valorado por su velocidad de desarrollo, parece que las startups todavía lo contratan de vez en cuando.
Pero creo que esa es una razón distinta a por qué las startups evitan Java.
[Razones por las que las startups evitan Java]
[Pero razones por las que una startup debería elegir Java]
[Pero razones por las que igual hay que reconsiderarlo]
Más allá de si Java es bueno o malo, lo que siento en la práctica es que Java no parece ser la corriente principal entre las startups del extranjero.
Tuve que realizar análisis técnico para la adquisición de empresas en el extranjero, y no hubo ni una sola que usara Java. Lo curioso es que, inesperadamente, había muchas con .NET.
Como ya había tenido esa experiencia hace 2 o 3 años, es un comentario con el que me identifico.
A mí tampoco me gusta mucho Maven por lo verboso que es,
pero resulta que Gradle también era algo terrible.
A mí me da más miedo npm;
Y además, me parece que lo de COBOL ya fue pasarse un poco de la raya.
Será porque lo usan más desarrolladores de grandes empresas jaja
En fin, cada vez que veo cómo critican a Java a ciegas me da risa. Cuando ves los casos, se notan las experiencias oscuras que cada quien arrastra.
Java fue demasiado flojo.
Se merece que lo critiquen.
Últimamente parece que se está poniendo las pilas, pero yo creo que todavía merece más críticas.
De todos modos, a medida que pasan las generaciones, otro lenguaje terminará volviéndose dominante. En las startups, el proceso de toma de decisiones para adoptar nuevas corrientes es más simple, y solo dejan de ser startups si el lenguaje que usan se vuelve dominante; en cambio, en las empresas grandes, el proceso de decisión es más complejo y hay intereses involucrados, así que la diferencia no será que adoptan algo solo cuando su estabilidad ya está asegurada.
COBOL, que apareció en 1959, recién desapareció del sector financiero cuando ya llegó el siglo XXI. Como referencia, incluso Java, que muchos de ustedes consideran poca cosa, también comenzó como software de código abierto y en su momento fue el lenguaje más popular entre las SOHO. Además, la imagen de Java como lenguaje de grandes empresas se reforzó después de la adquisición por parte de Oracle y, en Corea, con la aparición del Electronic Government Framework impulsado por el gobierno.
Me da curiosidad de dónde salió el mito de que “Java solo es popular en Corea”. Si hablamos de grandes empresas de IT en Corea, al final son apenas un par entre Naver, Kakao y Line, y como esas dos usan Java, ¿será por eso?
Claro, en Estados Unidos el pool de ingenieros es mucho más amplio, así que sí hay una ventaja para armar equipos con otros lenguajes, pero incluso en todas las empresas de IT de EE. UU., incluidas las FAANG, Java es un stack tecnológico sumamente común.
Como son compañías tan grandes, la diferencia entre equipos suele ser enorme, pero en Amazon incluso el framework estándar interno es Java (escuché que en la versión 2 usaron Spring y que ahora cambiaron a Guice). Tengo entendido que en Google están más o menos mitad C++ y mitad Java, con algunos equipos que usan Python, y que en Apple también, hasta donde sé, la mayoría de los servicios web corren sobre Java.
Ni hablar de Netflix:
hystrix,zuul,eureka, todo eso lo hizo Netflix, así que probablemente sea una de las empresas que mejor usa Spring en el mundo.En Facebook también, aunque la mayoría usa C++ o Hack, tengo entendido que hay algunos equipos que usan Java.
Y Twitter, según sé, empezó con Ruby y después se pasó a Scala, que es un lenguaje de la JVM. Además, en otras grandes empresas como Atlassian, VMware, Red Hat, etc., probablemente sea más difícil encontrar una que no use Java.
Como Kafka y Hadoop también corren sobre la JVM, incluso si no usan Java directamente para sus servicios, no sé si realmente exista una empresa que no necesite Java en absoluto.
No hay nadie que niegue que antes se usaba mucho Java. Parece que eso está bastante alejado del punto principal de este artículo.
Tu texto en sí está hablando de grandes empresas en general, sin importar el país, pero en los comentarios se ve particularmente mucho la mención de que "en Corea es así" o "eso aplica solo a Corea".
No es que solo en Corea se use mucho Java, pero sí parece cierto que en Corea en particular se usa bastante. Por ejemplo, en los resultados de la encuesta del año pasado de JetBrains se decía: “Java es el lenguaje más utilizado en Corea, China y Alemania. La participación de Java en Corea es del 53%, en China del 47% y en Alemania del 33%.”. Creo que en este fenómeno seguramente también influyeron la existencia del marco de trabajo de gobierno electrónico, que varios también mencionaron mucho en los comentarios, y el currículo de la formación en programación financiada con fondos públicos.
Viendo algunos comentarios, me acordé de aquel artículo sobre C++ que se publicó hace tiempo. Está claro que en la comunidad coreana de desarrolladores C++ y Java casi han subido al nivel de lo sagrado, jaja; en cuanto los criticas, parece que se activa el botón de ataque de muchísima gente...
Claro que hubo razones por las que Java también arrasó en el mercado local, pero meter a C++ en el mismo saco que Java es un poco... jaja
"Botón de ataque" no me parece una expresión muy adecuada. Porque presenta a la otra persona de manera negativa.
Me atrevo a decirlo porque me gustaría que fuéramos una comunidad que se respete un poco más entre sí. Lo siento.
Estoy de acuerdo. No parece que haya necesidad de disculparse.
Más que decir que las startups evitan Java, creo que las ventajas de otros lenguajes/frameworks son mayores, pero sí coincido en que el ecosistema de Java/Spring es peor de lo que uno pensaría. Sinceramente, aunque soy desarrollador de Spring, no me gusta particularmente Spring. Como casi no hay desarrolladores que hayan hecho desarrollo de aplicaciones web en entornos distintos de Java (prácticamente sinónimo de Spring), la sensación es todavía peor.
Spring
data-jpa) está a nivel de religión.Java
Las ventajas del ecosistema JVM definitivamente existen, así que en proyectos nuevos Kotlin es casi obligatorio, y si no hay una razón clara para llevar Spring, me parece más deseable empezar con un framework liviano como ktor. Sobre las desventajas que señalé, hay mucha gente que dice que el diseño está mal o que uno desarrolló sin entender bien la filosofía de Spring, pero OOP también se puede hacer en otros lenguajes...
Aunque la sección de comentarios está bastante desordenada y agresiva, este es un comentario con el que sí se puede estar de acuerdo.
Estoy de acuerdo en que deberíamos adoptar con más decisión lenguajes y frameworks nuevos, pero, siendo sinceros, la realidad local es que todavía hay demasiada gente que, incluso al arrancar un proyecto nuevo desde cero, elige por inercia Java 8 en vez de Java 17, la versión LTS más reciente, sin ninguna razón realmente racional. Si uno mira sitios como blogs de Tistory, es muy fácil encontrar publicaciones con fecha de este mismo año 2022 como “cómo descargar Java 1.8”. Viendo eso, da la impresión de que no es para nada extraño que muchas otras personas aquí muestren una actitud de rechazo total hacia Java.
Pero tampoco creo que estos problemas se originen únicamente en el lenguaje Java en sí. Más bien, pienso que el problema mayor es una cultura hostil al cambio —que parece especialmente marcada a nivel local— y la proliferación de código sin evolución hecho a base de copiar y pegar. De hecho, yo trabajo dando mantenimiento a varios tipos de programas similares desarrollados en C#, y aunque considero que el lenguaje en sí es mejor que Java, por bueno que sea un lenguaje no hay forma de evitar lo terrible que puede llegar a ser un código que el responsable anterior resolvió a las apuradas simplemente copiando y pegando código de proyectos viejos. Incluso ahora, debido a cambios en el entorno externo, estamos en una situación en la que una parte considerable de ese código repetido tiene que ser reemplazada sí o sí antes de fin de año, lo que lo hace todavía más terrible.
Es un tema que dispara reacciones, al menos en el contexto local.
Parece difícil dejar de lado Java, que se ha usado mucho desde hace tiempo, y como se sigue necesitando gente, en las academias financiadas por el gobierno siguen produciendo más gente para Spring con el mismo currículum de siempre..
Siento que va a ser difícil cortar ese círculo.
Aun así, veo con buenos ojos los intentos de usar Kotlin con Spring.
Cuando usas Docker...
las imágenes de Docker también se vuelven innecesariamente grandes.
Y además tarda mucho en arrancar, etc...
Como ahora casi todos usan Docker, parece que también se ha vuelto algo menos preferido..
El ecosistema de Java jamás se ha roto ni una sola vez.
Hay una enorme cantidad de proyectos open source y, con cada actualización de versión, creo que refleja las tendencias actuales de desarrollo más rápido que otros lenguajes.
gradle/mavenson solo opciones de herramientas de build, no algo obligatorio.También hay muchas otras herramientas de build y puedes usar la que quieras.
¿Por qué se usa
npmen Node? Porque es conveniente.gradle/maventambién se usan mucho porque son convenientes.Aunque Java también tiene muchos frameworks, creo que Spring sigue siendo popular hasta hoy porque ofrece flexibilidad para extenderse, facilidad para gestionar proyectos y un rendimiento estable.
Si vemos por qué en las startups cambian a Java a medida que el negocio crece, en la mayoría de los casos deciden hacer el cambio por una gestión de proyectos más estable.
Hasta ahora, al desarrollar a pequeña escala con Python o Node no hay problema, pero si el negocio tiene éxito y el mismo proyecto pasa a tener 100 o 1000 desarrolladores, ya no es fácil aprovechar las ventajas de Python o Node y, al contrario, sus desventajas se vuelven mayores.
Creo que por eso cambian a Java, que permite asegurar estabilidad además de control de calidad en proyectos a gran escala.
Si hubiera existido un lenguaje alternativo mejor que Java, ¿no lo habrían adoptado antes que nadie?
Por último, los servicios hechos con Java tienen una barrera de entrada inicial alta y costos de infraestructura altos. Por eso, en las primeras etapas de una startup, suele verse que usan principalmente lenguajes que se pueden aplicar de forma fácil y rápida, sin invertir desde el inicio muchos costos ni mucho tiempo en la configuración.
Por ahora, al menos en Corea, sobran los desarrolladores de Java. Más exactamente, no hay desarrolladores de Java sino solo desarrolladores de Spring. Como el framework de gobierno electrónico es Spring, prácticamente todos los desarrolladores formados en masa salen sabiendo solo Spring. Como hay tantos de esos con experiencia acumulada, pasa eso. No hay diversidad y el ecosistema del lenguaje ya está arruinado. Hay mucha gente que se hace llamar desarrollador de Java pero ni siquiera puede crear un tablón de anuncios sin Spring.
El punto de esta pregunta es "startup"; lo importante no es tanto la "estabilidad/escalabilidad" sino la "velocidad de desarrollo".
¡Para una startup, el tiempo es dinero!
(¿Más adelante, cuando haya tiempo y dinero, pasar a Java?)
Y la popularidad de Java probablemente no sea algo exclusivo de Corea. Incluso ahora sigue estando en el top 3 de lenguajes de programación más populares.
Parece que esa idea de pasarse a Java solo aplica en Corea.
Como muchas empresas grandes tienen bastante hecho en Java, el objetivo principal es el mantenimiento.
Que aparezca Oracle o no, en realidad no aplica para la mayoría de las empresas de primera línea... incluso Naver, Kakao, Line y Coupang tienen sus sistemas principales completamente en Java. Incluso compañías de videojuegos como Nexon escriben su red interna de backend en Java.
No estoy para nada de acuerdo con eso de que el ecosistema de Java se arruinó o que Gradle es terrible.
No entiendo cuál es la lógica de pensar que, solo porque Java es un lenguaje antiguo y hay muchos desarrolladores de Java, eso significa que esa gente no quiere aprender cosas nuevas o que su calidad es inferior.
Nekaracube en su totalidad tiene a Java como principal, y recientemente Kotlin apenas se está introduciendo poco a poco.
¿O es que de verdad están diciendo algo como que los verdaderos cracks están en las startups? jaja
Parece que podría haber una traducción más adecuada para
hotshit."Decir en 2022 que tu nueva startup usa Java es como decir que usa Cobol."
En Corea no hay forma de ganarle a la lógica de que es fácil conseguir desarrolladores de Java. La calidad de los desarrolladores que se contratan así... bueno, quién sabe.
¿Que el ecosistema de Java está arruinado? ¿Y por qué dicen que Spring tampoco sirve? Los fundamentos son demasiado débiles.
Si la JVM fuera una criptomoneda, Java sería Bitcoin.
jajajajajajajajajajajaja
No es por nada que antes existía el meme de “Java requiere 2 personas”... Además, como existe el framework estándar del gobierno, en los proyectos SI del sector público casi te obligan a usar JAVA....
Me cuesta un poco entender eso de que el toolchain de Java no es muy bueno.
La forma de gestión de Maven/Gradle me parecía casi angelical comparada con lo que sufrí con npm...
Yo también empecé mi carrera con Java y trabajé alrededor de 4 años en una empresa únicamente como desarrollador Java. Luego, al cambiarme de empresa varias veces, fui probando distintos lenguajes como Python, Ruby y Go, y recientemente he continuado mi carrera como desarrollador de Solidity.
Últimamente, a medida que muchas startups terminan cierta etapa de crecimiento y entran en una fase de estabilidad, se ven muchos casos en los que cambian su infraestructura principalmente a Java. Pensando bien por qué hacen ese cambio, me dio la impresión de que simplemente todos lo hacen por inercia.
Muchos desarrolladores de nivel lead están acostumbrados a Java y, como les cuesta aprender otros lenguajes, simplemente usan el Java que ya conocen. Y cuando ese tipo de personas se concentra en las startups, parece que toda la infraestructura termina volviéndose basada en Java.
Personalmente, no me resulta fácil entender que se rehaga la infraestructura solo por una cuestión de costumbre, pero como las personas tienden naturalmente a evitar aprender cosas nuevas y el ecosistema de Java en Corea del Sur es tan sólido, parece que cambiar esto será muy difícil.
Java y Spring son buenos para ofrecer servicios grandes de forma estable, pero como los servicios de una startup en sus inicios son pequeños, no es fácil aprovechar las ventajas de Java.
En una startup al inicio, a veces un equipo pequeño tiene que encargarse tanto del Front como del Back, y para eso es más práctico hacerlo de una sola vez con Node.js o JS que con Java.
Al final, cuando las startups reciben inversión de serie, casi todas terminan migrando a Java y Spring.
Como todos saben, Java ofrece desde sus primeras versiones varias cosas que hoy damos totalmente por sentadas, como la gestión automática de memoria. Y en los años 90, cuando Java apareció por primera vez, se usaban mucho más que ahora lenguajes como C o C++, donde un pequeño error del desarrollador podía provocar una fuga de memoria y afectar con mucha mayor facilidad la confiabilidad de toda la aplicación. En una época así, la llegada de un lenguaje que, aunque pudiera tener pausas temporales de ejecución (Stop-the-world), reducía drásticamente la probabilidad de que un servicio muriera por completo por problemas de memoria, fue al parecer toda una sensación. Por eso, creo que Java arrancó desde muy temprano con la imagen de ser mucho más estable que otros lenguajes, y esa percepción se ha mantenido hasta hoy.
Además, a estas alturas Java cuenta con la confianza y la experiencia acumulada de haberse usado ampliamente durante mucho tiempo en todo tipo de servicios. Por eso, como mencionas, es más fácil hacer tuning de rendimiento o troubleshooting, y también existen muchas herramientas y soluciones, tanto comerciales como de código abierto. El ecosistema de un producto ampliamente usado ya de por sí hace más fácil resolver problemas, y desde una postura donde la estabilidad es prioritaria, el hecho de que ante una falla sea más sencillo solucionarla y reducir el downtime debe ser una gran ventaja.
Y en el caso de Kotlin, que se menciona mucho en otros comentarios, según el comentario de otra persona aquí en GeekNews, sorprendentemente todavía hay bastantes bugs del compilador y problemas relacionados con compatibilidad. Si incluso un lenguaje que usa la misma JVM y que ya lleva casi 10 años desde su lanzamiento sigue así, entonces, si el criterio más importante al decidir es la estabilidad, parece perfectamente razonable optar, salvo casos muy particulares, por algo que ya haya sido suficientemente comprobado a lo largo de muchos años.
Como referencia, aunque ahora pueda sentirse muy extraño, cuando Java apareció por primera vez, tomando prestada la expresión del libro Polyglot Programming (2014) de Baekjun Lim, dicen que incluso “daba una sensación novedosa, joven y hasta sexy”. En relación con eso, comparto una traducción de un texto escrito en 1997 por James Gosling, el padre de Java.
Creo que la razón por la que se recurre a Spring está en las particularidades del mercado de desarrolladores en Corea.
En el extranjero, la JVM, como dice este artículo, por lo general se está pasando a Kotlin.
A mí también me empezó a caer mal la imagen de Java por culpa de los fanáticos de Spring.
Especialmente en Corea, si dices que haces Java, prácticamente todo el mundo asume que es Spring Boot. Hay mucho de eso de Java = Spring Boot.
Soy un desarrollador que no sabe Java, así que me siento bien.
Aun así, parece que en una startup sería donde más rápido se puede contratar gente...
Pero en Corea...
Yo también usé Java en algún momento, pero ahora prefiero no usarlo si es posible.
¿Por qué me pone triste y al mismo tiempo me da risa..? jajaja
(En una startup anterior usábamos Java, pero ahora ya no)