30 anos de Java — entrevista com James Gosling, o gênio por trás do código que mudou a tecnologia

• James Gosling é o criador do Java e é visto como um gênio pragmático que influenciou a computação moderna por 30 anos
• Vindo de um ambiente pobre, aprendeu programação montando computadores com peças tiradas do lixo, e esse aprendizado autodidata mais tarde se refletiu em sua filosofia de design de linguagem
• Na Sun Microsystems, a era em que brincadeira e inovação coexistiam serviu de base para a criatividade característica de Gosling e para a formação de uma cultura técnica
• Recentemente, ele demonstrou forte ceticismo em relação às ferramentas de IA generativa e ao boom da IA, e enfatizou que a importância do ensino de programação aumentou ainda mais
• O segredo da sobrevivência do Java não foi o brilho, mas uma filosofia de design pragmática voltada rigorosamente para estabilidade, retrocompatibilidade e produtividade do desenvolvedor

---

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

• O Java completa 30 anos em 23 de maio como uma linguagem de propósito geral, de alto nível e orientada a objetos, e ainda hoje é uma tecnologia central que move sistemas dos mais diversos portes
• Na base da existência do Java está o senso técnico pragmático e a intuição criativa de James Gosling
• Gosling começou como um adolescente canadense independente, que montava computadores juntando peças do lixo, e cresceu até se tornar um programador de alcance mundial
• A filosofia de “escreva uma vez, execute em qualquer lugar” é o símbolo do Java e levou a uma filosofia de linguagem que provocou uma mudança fundamental na forma de desenvolver software
• Ao longo da carreira, Gosling conciliou excelência técnica, espírito brincalhão e um forte senso ético, encarnando um modelo de desenvolvedor que influenciou continuamente a formação da cultura da computação moderna

James Gosling: The Brilliant Mind Behind Java

• James Gosling não é apenas o “pai do Java”, mas um gênio humilde capaz de explicar conceitos complexos de forma intuitiva
• Agora, 30 anos após criar o Java, ele relembra sua trajetória tecnológica e revisita o processo de evolução da linguagem e da cultura de desenvolvimento

The Path To Programming: Resourceful Beginnings

• Na infância, em meio a uma situação de extrema pobreza, Gosling teve a experiência de recolher televisores do lixo e desenvolver sua criatividade técnica
• Seu primeiro computador foi montado com racks de relés descartados pela companhia telefônica, simbolizando uma aptidão mecânica e uma habilidade de montagem evidentes desde cedo
• Ao visitar o centro de computação da Universidade de Calgary, ficou fascinado pelas telas, luzes piscando e unidades de fita, e ali começou uma curiosidade pela programação que duraria a vida toda
• Ele estudou sozinho vasculhando cartões perfurados para obter senhas e, ainda no ensino médio, criou um programa de análise de dados de satélite para o departamento universitário de física, acumulando a experiência de gostar de programar e ainda ser pago por isso
• Suas primeiras experiências de programação passaram por PL/1 em mainframes IBM, Fortran, assembly de PDP-8 e código do CDC 6400. Em seu tom contido característico, comentou casualmente: “No verão, trabalhei desenvolvendo um compilador COBOL”, algo que muitos programadores experientes teriam dificuldade até de encarar

Academia to Industry: Finding His Way

• Gosling descreve o meio acadêmico como “um laboratório que usa pós-graduandos como mão de obra barata”, revelando uma visão direta que valoriza mais a prática do que a teoria
• Mesmo durante o doutorado em Carnegie Mellon, trabalhou em startups para ganhar experiência prática e depois concluiu o curso, realizando uma trajetória flexível que combinou indústria e academia
• Seu primeiro emprego foi no IBM Research, mas ele o descreveu como uma “empresa dedicada a dar tiros no próprio pé”, mantendo uma postura analítica e fria sobre gestão corporativa e estratégia tecnológica
• Essas experiências iniciais depois se tornaram a base de sua compreensão, orientada pela realidade, da cultura organizacional, influenciando sua forma de atuar na Sun Microsystems

The Sun Days: Innovation and Pranks

• Como uma de suas lembranças mais divertidas da Sun, Gosling cita os grandes projetos anuais de pegadinhas de Primeiro de Abril, recordando uma cultura organizacional em que criatividade e bom humor conviviam
• Um exemplo clássico foi colocar uma Ferrari sobre uma plataforma flutuando em um lago, um caso que mostrou senso de humor apoiado por engenharia e trabalho em equipe
• Outra pegadinha mencionada foi montar um campo de golfe de 1 buraco no escritório do CEO, com grama artificial, bunker e obstáculo de água, como uma tentativa original de unir tecnologia e diversão
• Gosling lembra a Sun como “um ambiente raro em que excelência técnica e criatividade brincalhona eram permitidas ao mesmo tempo”, e isso serviu de base para sua visão sobre tecnologia e seu modo geral de resolver problemas

Java: Creating a Legacy That Changed Everything

• A jornada de 30 anos do Java é, para Gosling, sua realização mais emblemática e o ponto de virada decisivo de sua vida tecnológica
• Ele menciona a profunda satisfação com o impacto deixado no ecossistema de desenvolvedores sempre que alguém na rua lhe diz: “Consegui minha carreira graças ao Java”
• Recursos como lambdas e genéricos eram coisas que ele queria desde o início, mas o momento de introduzi-los foi ajustado segundo a filosofia de design de “não vou colocar isso do jeito errado”
• Sobre a gestão do Java pela Oracle, avaliou que “foi melhor do que o esperado” e enfatizou que, na prática, a participação e a contribuição contínuas da comunidade tiveram papel central
• O Java evoluiu de forma otimizada para ambientes de nuvem e alcançou um nível técnico “realmente impressionante” em suporte a multicore, tratamento de memória e melhorias de GC

Beyond Java: Ventures After Sun

• Depois da aquisição da Sun pela Oracle, Gosling tirou um breve descanso, entrou no Google e, seis meses depois, saiu para ir à Liquid Robotics
• Lá, desenvolveu sistemas de controle para robôs oceânicos autônomos e viveu condições de trabalho únicas que uniam tecnologia e natureza, como um ambiente em que era preciso fazer snorkel no Havaí
• Participou de projetos para monitorar a temperatura dos oceanos no Ártico e na Antártida, mas a pesquisa ambiental sofria com falta de recursos e ele enfrentou choques com a estrutura de startups apoiadas por venture capital
• Diante da pressão para migrar para a área de defesa, saiu por razões éticas e seguiu para a AWS, trabalhando no projeto Greengrass e em ferramentas de desenvolvimento, mantendo uma trajetória profissional guiada ao mesmo tempo por interesse técnico e critérios éticos

On Open Source and Industry Trends: Cutting Through the Hype

• O open source é descrito como mais do que uma simples ferramenta de colaboração: trata-se de um ecossistema complexo que também funciona como relação com desenvolvedores, estratégia de marketing e modelo de adoção bottom-up
• Sobre a tendência low-code/no-code, ele expressa ceticismo, dizendo que é um argumento repetido desde os tempos do COBOL, e a vê como uma abordagem especializada com limites quando aplicada a domínios complexos
• IA e machine learning, segundo ele, têm um problema mais de nomenclatura do que de tecnologia, levantando uma crítica ao termo ao dizer que “técnicas estatísticas avançadas” descreve melhor sua essência
• A IA é apenas uma ferramenta e não deve ser confundida com uma entidade autônoma; ela deve ser vista como uma ferramenta sofisticada que auxilia, e não ameaça, o trabalho humano

Developer Tools and Preferences: Embracing Progress

• Gosling usa o NetBeans IDE como principal ferramenta de desenvolvimento e demonstra apoio ao open source sob licença Apache e a uma comunidade ativa
• Em relação a desenvolvedores que ainda se apegam ao Vi ou a ferramentas dos anos 70 e 80, ele expressa frustração com a recusa em aceitar o progresso tecnológico
• Ele ainda usa Vi às vezes por rodar em qualquer lugar, mas defende fortemente o uso de IDEs modernas em ambientes reais de desenvolvimento

The JVM Vision: From Academic Concept to Global Standard

• O conceito inicial da Java Virtual Machine (JVM) surgiu ainda no período de pós-graduação de Gosling, a partir de experimentos com formatos de distribuição neutros em relação à arquitetura e pesquisas em tradução de instruções
• Isso evoluiu mais tarde para uma tecnologia de plataforma de execução universal, na qual não apenas Java, mas várias linguagens podem rodar em diferentes tipos de hardware
• A filosofia “Write once, run anywhere” chegou a ser rejeitada como tema de tese por supostamente não ter base matemática suficiente, mas acabou se tornando uma tecnologia prática que transformou o ambiente global de desenvolvimento de software

More Recent Work: Bridging IoT Gaps at AWS

• Na AWS, Gosling participou do desenvolvimento do Greengrass, um framework de aplicações IoT, implementando uma abordagem técnica que simplifica com elegância problemas complexos
• O projeto abstraía tarefas boilerplate recorrentes entre implantação e operação, como atualizações OTA, controle remoto, telemetria, confiabilidade de rede, segurança e gerenciamento de autenticação
• O código do lado do dispositivo foi disponibilizado como open source, incentivando contribuições da comunidade para portar a tecnologia a plataformas não prioritárias para a Amazon, como RISC-V
• Outro projeto de ferramenta de desenvolvimento do qual participou depois acabou interrompido no meio do boom da IA, sugerindo problemas causados por uma confusão guiada mais pela moda do que pela autenticidade técnica

AI Skepticism

• Em entrevistas recentes, Gosling descreveu a revolução da IA como “em grande parte uma fraude”, mostrando uma visão cética que considera IA um termo de marketing tóxico
• Embora reconheça que a tecnologia é matematicamente impressionante, aponta o problema de que o nome IA ofusca a natureza real da tecnologia, que são técnicas estatísticas avançadas
• Ele critica duramente a febre de IA liderada por venture capital como “um ponto de encontro de vigaristas e exageradores”, denunciando a busca por lucro rápido e saídas financeiras acima da utilidade tecnológica real
• Ao dizer que a maior parte do dinheiro investido em IA acabará sendo “engolida por um buraco negro”, ele faz um alerta sobre fluxos de capital insustentáveis guiados por modismo

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

• Ferramentas de código com IA generativa causam forte impressão no início, mas têm uma estrutura limitada que falha assim que as coisas ficam um pouco mais complexas
• Essas ferramentas só conseguem raspar e repetir amostras de código existentes, e os problemas realmente interessantes são sempre novos, o que não combina com ferramentas baseadas em cópia
• Em ambientes profissionais de desenvolvimento, o código padronizado tende a convergir para bibliotecas, então a geração de código por IA entra em choque estrutural com as exigências reais do desenvolvimento
• Gosling define o uso realmente útil da IA como uma ferramenta de busca que faz o trabalho de documentação que ninguém quer fazer, destacando seu valor como ferramenta auxiliar especializada em explicar como usar APIs

Java’s Evolution: Language Features and Runtime Improvements

• Entre as mudanças recentes na linguagem Java, recursos como inferência de tipos e melhorias na forma de declarar arrays são avaliados como extensões úteis que aumentaram a conveniência para o desenvolvedor
• No entanto, Gosling enfatiza que o avanço mais impressionante do Java está na melhoria da qualidade da JVM e das bibliotecas padrão
• A JVM moderna apresenta um desempenho de execução que chegou a um nível “surpreendente” em qualidade de código, desempenho de threads e garbage collection
• Em gestão de memória e previsibilidade de desempenho, ela é mais eficiente do que a linguagem C baseada em malloc, e ele também menciona a possibilidade de ajustar pausas de GC para poucos milissegundos
• A JVM atual é vista como um ambiente de runtime de alto desempenho capaz de lidar de forma estável até com espaços de memória absurdamente grandes

Programming Languages for Critical Infrastructure

• Sobre reescrever o sistema de controle de tráfego aéreo da FAA em alguma linguagem, Gosling rejeita a premissa da pergunta, dizendo que isso seria “como escolher um martelo antes de construir a casa”
• Ele enfatiza que primeiro é preciso entender claramente as características do domínio do problema, como sistemas de comunicação, regulamentações internacionais, rotas de voo e prevenção de colisões, para só então escolher a tecnologia
• Ainda assim, acrescenta que, para sistemas grandes e críticos em confiabilidade, o Java pode ser um candidato forte

The Future of Programming in an AI World

• Mesmo com o avanço da IA, programação continua sendo uma habilidade essencial, e Gosling afirma que se tivesse filhos, ensinaria programação a eles sem hesitar
• Ele critica as declarações de executivos de big tech de que a IA substituirá desenvolvedores humanos, chamando isso de ameaças defensivas para intensificar a pressão sobre o trabalho
• Para compreender corretamente os sistemas, é preciso ter capacidade de programação, e ele defende que mesmo que máquinas façam parte do trabalho, a base de entendimento técnico humano precisa permanecer

Java’s Longevity Secret

• Como explicação para o fato de o Java ter sobrevivido por mais de 30 anos, Gosling aponta capacidade real de resolver problemas, respeito ao usuário, retrocompatibilidade, aumento de produtividade e uma filosofia centrada em confiabilidade
• Em vez de seguir modas de linguagem, o Java sempre enfatizou uma utilidade prática consistente, e uma filosofia de design voltada para a realidade, focada em resultado mais do que em estilo, foi especialmente eficaz no ambiente corporativo
• Partindo da visão de que software “deve sempre funcionar direito”, o Java permanece uma ferramenta de engenharia honesta e pragmática

Oracle’s Stewardship: Better Than Expected

• Sobre a forma como a Oracle conduziu o Java após a aquisição da Sun Microsystems, Gosling disse que “foi muito melhor do que eu imaginava”, expressando surpresa com um desempenho acima do esperado
• No início, ele temia “saque e pilhagem” por causa do histórico anterior da empresa, mas depois avaliou positivamente o fato de a equipe do Java ter sido protegida e não atrapalhada, preservando independência e foco técnico
• Embora tenha criticado a falta de apoio financeiro, deu nota alta ao fato de que foi mantida uma estrutura com autonomia para a equipe técnica, sem interferência corporativa excessiva

Crab Lovers Unite!

• Gosling diz há tempos que quer trabalhar com pessoas com quem também gostaria de jantar, mostrando uma postura que valoriza critérios de colaboração centrados nas pessoas
• O jornalista conta que encontrou Gosling por acaso no restaurante especializado em caranguejo Thanh Long, em San Francisco, registrando o momento em que uma figura gigantesca da tecnologia aparece em meio à vida cotidiana
• Depois, os dois comeram caranguejo juntos e conversaram, prometendo que o próximo encontro seria no mesmo lugar, transmitindo o calor humano de uma troca que vai além da tecnologia

[cosine20]

Eu também acho que, entre as linguagens de tipagem estática, Java é a mais confortável e fácil de usar.

No entanto, do ponto de vista de um desenvolvimento genérico e prático, escrever em Java aplicativos voltados ao usuário final com GUI não era uma escolha muito boa. (Nessa perspectiva, a combinação C# + .NET é a melhor de todas.)
Considerando as vantagens do Java, acho que os melhores casos de uso, do ponto de vista prático, são backend ou middleware.

De qualquer forma, como é uma linguagem que de vez em quando preciso usar e que sempre dá para lidar sem pressão, acho que acabei ficando com mais experiências boas com ela.

[mhj5730]

Essa história de que ele programava desmontando TVs no ferro-velho parece mesmo o começo de uma lenda.

[ndrgrd]

É verdade que, depois de Java, as linguagens passaram a dar atenção à produtividade.

Antes disso, o C++, que era muito usado, continua sendo assustador até de ler. Especialmente quando você mexe em projetos de longa duração.

[3ae3ae]

É difícil concordar com a ideia de que o Java priorizou a produtividade dos desenvolvedores.
Existe outra linguagem que tenha evoluído a ponto de depender tão profundamente de uma IDE quanto o Java?

[3ae3ae]

Acho que fiz um comentário imprudente.

[sunrabbit]

Depender profundamente de IDE é um problema do ecossistema Java, que evoluiu de forma pouco ideal,
e não um problema no nível do design.

Falando de forma bem direta, hoje em dia, para desenvolver em Java, não é preciso necessariamente usar um produto da JetBrains,
mas, como todo mundo usa, acaba parecendo que é.

Além disso, se você olhar a lista de linguagens de programação da época em que o Java surgiu, muitas tinham implementações dependentes de plataforma, ou seja, dependentes do sistema operacional.
Foi o Java que mostrou a direção que linguagens como Node, Python e C# seguem: rodar em vários sistemas operacionais com o mesmo código.

Hoje em dia, essa compatibilidade de rodar o mesmo código em vários sistemas operacionais é um "bom senso" óbvio.

[roxie]

> Falando bem francamente, hoje em dia, para desenvolver em Java, não é exatamente necessário usar produtos da JetBrains

Essa parte... é um pouco difícil de concordar, sniff sniff...

[kwj9211]

Hoje isso parece meio óbvio,
mas, na época em que o Java surgiu, só o fato de oferecer suporte estável a múltiplas plataformas sem a necessidade de um novo build já não ajudava bastante na produtividade?

[angrycoder]

Em comparação com as linguagens anteriores ao Java, parece até ter uma produtividade melhor.

[ahwjdekf]

c++ > c# >= java

[cosine20]

C# >= Java > C++

[GN⁺]

Comentários do Hacker News

• A percepção é que o desempenho do Java não está no topo absoluto, mas fica em 3º lugar atrás de C/C++ e não é ruim; é até mais rápido que Go e mais de 10 vezes à frente de Python ou Ruby, o que já satisfaz. A sintaxe de Java não é perfeita, mas tem como vantagem ser consistente e previsível, e com ferramentas como Idea ou Eclipse a produtividade não preocupa. O modelo de gerenciamento de memória é diferente da filosofia Unix, mas, quando se entende, parece um compromisso aceitável. Fica a satisfação com o pragmatismo de obter, por meio desses trade-offs, velocidade e segurança de memória, junto com vantagens como chamadas dinâmicas e hot swap.
  • Dá para sentir que ferramentas como o IntelliJ para Java são incomparavelmente melhores do que em outras linguagens. Fico curioso por que a comunidade Go não parece muito empolgada em desenvolver contêineres de estruturas de dados concorrentes. Invejo a cultura de programação concorrente em Java, que recomenda ótimos contêineres, e às vezes sinto falta de java.util.concurrent ou JCTools.
  • Logo após me formar na universidade, eu achava que Java servia para tudo, mas depois percebi que o que estava à frente do seu tempo eram a JVM e o tooling dos Java App Servers. A linguagem em si era decepcionante antes dos ganhos de produtividade de 2006~2007. Hoje tenho interesse em outras linguagens que rodam na JVM, como JRuby, Clojure, Scala, Groovy e Kotlin. Entre elas, JRuby é interessante por permitir usar dois ecossistemas maduros. O fato de o Project Loom ter trazido as Fibers do Ruby para a JVM beneficia os dois lados, e o trabalho de Charles Nutter é subestimado.
  • Dizem que Java é mais rápido que Go, mas na prática muitas vezes Go é mais rápido ou usa de 2 a 10 vezes menos memória, então os dois ficam em nível parecido. Graças aos value types de Go, é mais fácil otimizar. Achei marcante a menção específica a Go e, considerando que C# é mais rápido que Java, diria que Java não está em 3º, mas algo como 5º.
  • Valorizo muito como recursos recentes do Java, como sealed class, switch expression, Project Loom e records, foram incorporados naturalmente à sintaxe existente. Também sinto que as ferramentas de diagnóstico do Java, como analisadores de heap dump e de GC, estão no mais alto nível.
  • Vale lembrar que rankings de desempenho de linguagens mudam conforme o que se inclui e como se compara; veja o link de benchmark fornecido.
• Java (JVM) é uma daquelas tecnologias que, depois de experimentar outras linguagens/ecossistemas que tinham fama de ser melhores, acabei valorizando ainda mais. Na prática, a sensação se repetia como aquele “a grama do vizinho parece mais verde”. Só Rust realmente me pareceu uma linguagem muito avançada e prazerosa de usar. Acho uma pena que hoje Java não seja visto como uma linguagem “cool” em startups, e acredito que a diferença de produtividade quase desapareceu.
  • Usei Rust em tempo integral por dois meses e, pelo menos em desenvolvimento de servidor, não entendo essa ideia de que ele traz “alegria” em comparação com Java. Há momentos demais em que os problemas de lifetime assustam e derrubam a produtividade. A sensação de type safety é real, mas no geral é difícil chamar a experiência de realmente prazerosa.
  • C# está bem à frente de Java e se diferencia de formas significativas, como generics muito melhor implementados, value types existentes há muito tempo e um FFI conveniente. Tirando Unity, pouca gente parece se importar, e acho que a Microsoft falhou antigamente em ganhar reconhecimento popular.
  • Acho que essa sensação vem da diferença de escala dos projetos. Normalmente, quando se sai de um grande projeto legado em Java com 10 anos de vida para um projeto “novo” nível hello-world, é natural que pareça melhor. Rewrites em larga escala ajudam até em revisão de segurança, mas as empresas em geral não têm essa folga, com exceções como o Google.
  • Sinto exatamente o mesmo. Go foi decepcionante: prometia tudo, mas no fim pareceu parecido com Java ou até um retrocesso, com coisas como erros sem stack trace.
  • No meio de quase 30 anos de carreira, os 2 anos em que tentei fazer projetos fora da JVM foram o pior período profissional da minha vida.
• Sou grato pelas conquistas de James Gosling. Por causa da Java World Tour, aparecer “Java consultant” no topo das buscas me permitiu trabalhar remotamente e manter uma vida estável no interior. Há muitas pessoas cuja vida foi impactada positivamente por Java. Também admiro o trabalho da equipe de Clojure por construir um excelente ecossistema sobre a JVM.
  • Eu também agradeço a James Gosling. Em 1995, trabalhava com C++ na Taligent quando usei Java pela primeira vez e fiquei impressionado com a novidade. Depois que a Taligent foi desfeita, passei muito tempo trabalhando com Java e softwares relacionados.
  • James Gosling (Java) e Rich Hickey (Clojure) são avaliados como criadores que trouxeram frescor ao mundo da programação em suas respectivas épocas.
• Trabalhei nos últimos anos com .NET/C#, mas, no geral, sinto que JVM/Java é o melhor ecossistema que já experimentei. Java acertou muito mais coisas. Por exemplo, Java resolveu a divisão de trabalho com fork/join pool, enquanto .NET apenas colocou work-stealing no thread pool global, o que faz código sync-over-async provocar deadlocks gerais com facilidade. Em bases de código grandes, pedir uma conversão completa de código síncrono para assíncrono é praticamente impossível. No lado do Java, mesmo quando há erros em bibliotecas ou frameworks, costuma-se superar rápido; já no .NET, se o problema está na biblioteca padrão, na linguagem ou no runtime, é difícil corrigir. Há muitos casos em que Java definiu melhor o padrão.
  • Thread pool starvation no .NET é extremamente irritante, embora eu tenha ouvido que o impacto diminuiu recentemente. Acho impossível existir uma implementação imune ao mau uso de thread pools. O que se pode fazer é aumentar o número de threads ou ajustar a ordem do trabalho de forma inteligente. Não sou especialista em thread pools, então não afirmo isso com total certeza.
  • Eu achava que o .NET vinha imitando a abordagem bem-sucedida do ecossistema Java, mas chama atenção o quanto, na prática, eles são diferentes.
  • Não é justo mencionar o problema de deadlock sem usar código .NET de fato, e também não é convincente se basear em um post de blog de 13 anos atrás.
• Há a percepção de que Java é um grande caso de sucesso, mas James Gosling foi o ponto de partida, não o líder real na prática. Desde a era Java 1.1~1.2, Mark Reinhold liderou a integração do JIT, o desenvolvimento do HotSpot, o grande aumento de classes no 1.2, e depois da aquisição pela Oracle também impulsionou suporte a linguagens dinâmicas, open source, lançamentos rápidos e a base dos recursos modernos da linguagem. A avaliação é que os pontos fortes do Java se devem à liderança de Mark Reinhold.
  • Toda a equipe principal de desenvolvimento é impressionante. Gosling queria uma linguagem pragmática, e depois pessoas como Mark Reinhold e Brian Goetz seguiram evoluindo a linguagem de forma amigável para desenvolvedores. Não gosto da Oracle, mas sou grato por ter dado continuidade a um grupo excelente.
  • Vale apontar que Kotlin, como Java, é uma linguagem estaticamente tipada, não uma linguagem dinâmica.
  • Mesmo que Linus tivesse apenas hackeado o git em duas semanas e fornecido só a faísca inicial, o fato de a comunidade ter expandido a ideia mostra que avaliar apenas o ponto de partida é incompleto.
• Como engenheiro de software acima dos 40, acho sensato escolher ferramentas que “simplesmente funcionam”. Hoje, Java ou C# cumprem bem esse papel. Pessoalmente, sinto que o ecossistema de C# é mais integrado. Para qualquer caso de uso, dá para criar um app em C# em 1 minuto, a linguagem evolui rápido e a oferta de profissionais é estável. O .NET também é cross-platform, e a própria elegância e eficiência da linguagem tornam o trabalho mais fácil.
• Tive a experiência de simular código de SO em Java na universidade. Entendo que, para estudar algoritmos abstratos, Java pode ser bom por reduzir a complexidade, mas pessoalmente acho que Python teria sido mais adequado. Não concordo com insistir em Java de forma incondicional no ensino introdutório universitário só por influência da indústria. Como já tinha visto BASIC e C no ensino médio, simular código de baixo nível de SO em Java pareceu um passo para trás.
  • Na universidade, aprendi microcontroladores em C, estruturas de dados/OOP em Java e conceitos de sistemas/SO/concorrência em C e assembly MIPS. Em estruturas de dados e algoritmos, Java pode ser melhor que Python para formar conceitos mais precisos, porque separa de forma mais clara tipos e estruturas abstratas. Mas ensinar conceitos de SO em Java realmente parece um pouco exagerado.
  • Vejo que as desvantagens do ensino com Java mencionadas por Joel também se aplicam a outras linguagens de alto nível, como Python. Ironicamente, vale destacar que o MapReduce, que o Google fez em Java, avançou mais que a Microsoft.
• Reconheço o sucesso do Java, mas ainda mantenho uma forte rejeição por vários motivos. Em grande parte por causa do legado de código verboso em grandes empresas, frameworks complexos e código de baixa qualidade. Eu odiava a cultura em que o código era produzido “como carvão”, sem paixão e sem personalidade. A JVM parecia uma caixa-preta por dentro, então depurar com ferramentas como strace e gdb era difícil, e a superalocação de memória tornava mais difícil para o kernel entender a carga de trabalho. Também sentia que, ao usar a JVM, sem ajuda de especialistas havia alto risco de problemas sérios. Além disso, Oracle, licenciamento, gestão de versões do JDK e a falta de uma imagem interessante em 2025 também pesam, junto com o fardo do código legado. Pessoalmente, construí minha carreira evitando Java ao máximo. Hoje há muitas linguagens de alto desempenho com compilação estática, binários pequenos e menos complexidade operacional, então o papel de soluções como JVM ou a VM do Python também parece estar diminuindo.
  • A JVM oferece alguns dos melhores recursos de depuração do mundo: reinício com reframing, alteração de variáveis, exception breakpoints e um conjunto enorme de debugging dinâmico. A integração com IDEs como Idea e Eclipse também é incomparável com outras linguagens. Há ainda muitas ferramentas de diagnóstico, como JMX/JConsole, Java Flight Recorder, jstack e HPROF. Quanto à licença, o uso open source não tem restrições, e comprar a JVM da Oracle é apenas uma escolha opcional. E qual exatamente seria o problema com código legado?
  • Dizer que JAVA não tem “cool factor” não é um argumento convincente. Em vez de strace/gdb, as ferramentas do JDK e as IDEs têm desempenho esmagadoramente melhor.
  • As ferramentas podem parecer difíceis à primeira vista, mas é fácil se acostumar. Em uma semana já dá para virar especialista em tuning de GC. Como o GC gerencia com um contexto melhor no escopo da aplicação do que o kernel, há muitas vantagens reais, embora eu reconheça certa complexidade extra de provisionamento.
  • Usei Java por mais de 20 anos e nunca precisei de strace/gdb; o suporte de debugging/IDE é muito forte. Também não faz sentido colocar Python e JVM no mesmo nível em termos de desempenho.
  • Parece que essa avaliação veio de alguém que, na prática, não usou muito Java, e isso só reforça que as ferramentas de depuração e diagnóstico de Java são de altíssimo nível.
• Foi mencionado que, quando Gosling estava na Sun, ele cocriou o sistema de janelas NeWS. O NeWS era baseado em PostScript e tinha uma estrutura em que o cliente enviava programas ao servidor. Dá para ver, no desenho do Java por Gosling, traços de uma vontade de enxergar páginas web como algo programável, como no NeWS. Quando perguntaram a ele, em um exemplar autografado de "The Java Programming Language", se “Java era a vingança do NeWS”, Gosling respondeu com um sorriso.
  • Assim como X teve o Wayland como sucessor, o NeWS parece ter tido como sucessor o navegador + JavaScript (PWA, Electron). No fim, parece que a abordagem do NeWS venceu até no ambiente da Microsoft, e fico curioso sobre o que Gosling pensaria disso.
  • Houve também algo parecido com o Display PostScript. Em combinações SPARCStation+SPARCprinter, toda a lógica de impressão era tratada no servidor, de modo que, se o servidor ou a impressora falhasse, o sistema inteiro parava. A integração entre servidor de impressão e impressora virou um pesadelo, e no fim isso só aumentou a desconfiança em relação a impressoras. Sinto falta do ecossistema SunOS e SPARC, mas do Display PostScript me despeço sem saudade.
• Passei uma parte considerável da carreira programando na JVM. Mais recentemente, usei Scala, Clojure (minha preferência) e Kotlin em vez de Java. Depois de ficar desempregado, aceitei recentemente uma proposta de trabalho com Python. Dá para ver que a demanda por experiência com JVM está diminuindo. De todo modo, se o salário cair na conta, qualquer linguagem está boa. No momento, meu projeto pessoal está sendo feito em Scala.

[roxie]

Tem uma turma do C# escondida aí no meio.