7 ms·

the people that work on Java & the JVM are very smart. it has become a best of breed language - hell its better than Go for industry purposes. the drawback wi

• karel-3d 7mo ago
  I didn't use Java since 7, but from people that do - nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java". I don't know if it's true though.
  • ezfe 7mo ago
    There's a lot of programming that has nothing to do with SpringBoot - and I say this as someone who works in a backend team that uses SpringBoot for all our apps.
    • deleted 7mo ago
      [deleted]
  • shermantanktop 7mo ago
    You're talking to specific people. A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.
  • gf000 7mo ago
    There are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.
  • ivan_gammel 7mo ago
    Spring Boot isn‘t bad. It‘s opinionated about configurations and dependencies. Its main advantage is that you can start shipping production-quality code very quickly, focusing on business problems rather than anything else. Vibe coding on it is more or less stable, entire apps can be built solo in a few months. And it‘s easy to do fullstack with SSR based on Thymeleaf and Htmx. It is absolutely superior to anything that exists for node stack. And then there‘s also Micronaut, if you prefer compile-time setup to Spring.
  • szatkus 7mo ago
    That's weird. Back when Java 7 was a new thing, people used Spring (Boot wasn't there yet) even more to compensate for the lack of language features. Also back then most projects still used XML configuration, so you actually write more Java code in modern Spring. Because Spring Boot uses Java configuration classes by default (although you can still use XMLs if you need for some reason).
  • KronisLV 7mo ago
    > Nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java". Subjective experience, but largely agreed. Vague rant that summarizes my own experience: major version updates kind of suck, even if Spring Boot is still better than regular Spring (I've gone through the XML hell, was not fun, even less so with a separate Tomcat instance that we had to deploy to, instead of an embedded one). In practice their huge effective pom.xml also leads to conflicts when your package needs something else and it feels a bit arcane to override things. There are things that have underlying technical reasons for being the way they are but seem stupid from afar - like how @Transactional doesn't work when called from within the same bean. Personally I also prefer code over convention for configuration and initialization so the whole annotation driven setup feels quite annoying and difficult to debug when things go wrong - but even the code configuration isn't always great and sometimes it feels like they have abstractions for the sake of abstractions. Spring Boot also often brings friends like MapStruct or Lombok or Mockito which add even more dynamic behavior and issues when you update JDK, alongside slow testing with JUnit and unpleasant debugging of jumping through numerous abstraction layers. You don't strictly have to, but people will. I probably should have written down every complaint with exact details (so those could be picked apart as user error) over the years that I've been unfortunately maintaining and building shitty software with Java, but I will say this - modern Spring Boot isn't wholly horrible, it has a pretty rich ecosystem and you can do a lot of things with it, but the overall vibe I get from it ofen can be summarized with "Eww." I'd end up using it because I have to, or because it's a means to an end ("Hey, we need to build an event-driven system to integrate with a bunch of others, you have two weeks"), not because I want to. For the sake of comparison, I believe that for plenty of the folks even Dropwizard would be worth a look: https://www.dropwizard.io/en/stable/ https://www.dropwizard.io/en/stable/ it is more or less like some glue around a bunch of idiomatic packages in the Java ecosystem and it's not horribly hard to integrate something that you want yourself (e.g. Dagger 2 for DI, at this point I'll take anything that does as much as possible at compile time https://dagger.dev/dev-guide/ https://dagger.dev/dev-guide/). Or, for a more modern spin, Quarkus isn't too bad either https://quarkus.io/ https://quarkus.io/ or maybe Micronaut https://micronaut.io/ https://micronaut.io/ or perhaps Helidon https://helidon.io/ https://helidon.io/ with neither of those being strong recommendations - figure out what you like for yourselves. For people that have been luckier than me, that might as well be the very same Spring Boot, just on better projects. JVM is a pretty cool piece of tech though, and so are the JetBrains IDEs with their refactoring features and nice Maven integration.
  • vips7L 7mo ago
    I’ve been working in Java for 12 years, my entire career. I have never worked on a Spring project.
• andyjohnson0 7mo ago
  "a solid foundation for the future" is faint praise for a language that has been around for over thirty years. > It has become a best of breed language To me it lags significantly behind .net (runtime) and C#/F# (language). I don't see Java catching-up.
  • gf000 7mo ago
    They trade blows, and have different philosophies (complex runtime, simpler language vs the reverse). E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.
    • spockz 7mo ago
      I would love to have a Java compiler with the capabilities of the .net compiler. To make incremental builds to aid code completion including type information, looking past simple syntactical errors, fixing them, and continuing compilation. Currently, this is “magic” embedded in eclipse, IntelliJ, and maybe a bit in the vscode plugin. Imagine having a Java LSP running that can provide all this information while typing. .net has had this for ages. From a language design I think that is wonderful.
      • hocuspocus 7mo ago
        Java LSP backends are basically headless Eclipse and NetBeans, they definitely go beyond syntactical errors. There's also the upcoming Metals v2 that's using another compiler frontend optimized for performance, Google Turbine: https://metals-lsp.org https://metals-lsp.org Actionable diagnostics for Java aren't implemented yet though.
      • pjmlp 7mo ago
        It also slows VS code a lot, is not properly documented, and still relies on concatenating strings together, due to Source Generators interaction with attributes.
    • adgjlsfhk1 7mo ago
• HendrikHensen 7mo ago
  What do you mean by "better than Go for industry purposes"? I don't understand what "industry purposes" means and in what aspects Java is better than Go in your opinion (I can think of some myself, but I'm interested in your perspective).
  • kyrra 7mo ago
    Not the GP, but for really large code bases, Go is missing a few features that I've noticed: 1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this. 2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names. 3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).
    • oefrha 7mo ago
      > No immutable types (in Go) The typical answer is opaque types with only readonly methods exported. Not elegant, but it’s there. I guess it’s arguably not a “good way” to do it.
      • joeblubaugh 7mo ago
        In fact it was “the Java way” for many years and “useless getters” was always a big complaint about Java.
        • oefrha 7mo ago
          Hey it's better in Go. In Java it's getFoo(). In Go it's just Foo(). Saves three bytes, and three keystrokes if you program by hand and don't autocomplete!
• stanac 7mo ago
  After ~13 years of working with C#, I moved to Kotlin. It's such a beautiful language. When I have to read docs for a Java lib I realize why I like Kotlin. I want to say culture around Java doesn't have to change, new culture is growing around succinctness (if not simplicity) of Kotlin, and it gets most of the benefits of Java ecosystem.
  • okr 7mo ago
    I also like Kotlin. The readability is awesome. ;) inline fun <reified T> Any?.cryptic() = (this as? T)?.let { it::class.simpleName?.also(::println) } ?: Unit
    • gf000 7mo ago
      I get the snark, but also - there is this "ideal Java code style" that most experienced devs tend towards. Unfortunately I don't see anything like that for Kotlin (yet?), and there are a bunch of patterns that I really dislike. I sometimes feel people just toy around, like "wow I can make this into an extension method, how cool" and leave that as the code. In general, I really dislike extension methods, especially when paired with tiny objects with barely any functionality to begin with. Like people build a mental model of what a thing is based on how can it be used - but if you leave that empty and put every behavior at different files in the form of extension methods you make this understanding very hard to build up. Add to it that it removes polymorphism and often actually hinders readability.. so my point is, having more ways to write code is not necessarily a positive.
  • pjc50 7mo ago
    I must say I prefer C# over Java. They're pretty similar in a lot of ways, but LINQ is much nicer to use than the Java streaming equivalents. And there are some odd warts like Java lacking unsigned types.
• moralestapia 7mo ago
  I am captivated by your thought process.
• mands 7mo ago
  It's getting better, it doesn't all have to be Spring Boot and JBoss. There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI (https://tamboui.dev/ https://tamboui.dev/) for terminal UIs, and more. Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance / resource improvements. It's not all there yet, but I think the next few years things will come together nicely (however a better build system is sorely needed - one of the things that Go / Rust did right).
  • cess11 7mo ago
    If someone reads this and wonders what JBoss is, the contemporary variety is called WildFly and it is actually rather easy to install and play around with. https://www.wildfly.org/ https://www.wildfly.org/ I think this is an often overlooked solution to some of the problems we nowadays tend to approach the clown for. As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.
    • zokier 7mo ago
      > As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway. Bazel is the most obvious contender and very different from Maven in almost every possible way.
      • cess11 7mo ago
        Not really, no. It is similar but worse than Maven in that it requires quite a bit of time investment to configure, and shares the drawback of Gradle that it is configured in a programming language instead of a configuration language. Switching out Maven for a larger maintenance burden might be reasonable in a large organisation that is swimming in competent employees, but most do not. As for obvious contender, I'd say that would be Gradle, which is harder to get someone started with than Maven and due to the DSL allows you to invent weirder footguns.
• lucketone 7mo ago
  > for not embracing religion of OOP and FactoryFactory Not the case today. Of course, crappy code (or questionable patterns) can be found in all languages, and java community had made some innovations in the area early on, but today we have a different picture. FactoryFactory has gone mostly extinct, the most likely place to see it is “dailywtf.com”. We now know that we prefer composition over inheritance, we have stream api - language and community evolved, old patterns are not neccessary anymore to solve same/similar problems. Sample of one - junit (testing lib) source code, from quick glance it seems more procedural than dogmatic OOP: https://github.com/junit-team/junit-framework/blob/main/junit-jupiter-api/src/main/java/org/junit/jupiter/api/AssertArrayEquals.java#L434 https://github.com/junit-team/junit-framework/blob/main/juni...
  • dmix 7mo ago
    It's still going to be hard to overcome the stigma of ex-Java developers coming into other languages and bringing their overly complex ideas with them. But I am happy to hear Java itself is evolving and I hope that limits the downstream effects of it being one of the most popular language a lot of devs start on.
  • owlstuffing 7mo ago
    > We now know that we prefer composition over inheritance When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a. But that’s not what composition is really about. The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface. Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits. So most developers never really practice interface composition. They either subclass, or they wire objects together and expose the wiring. The slogan survived. The concept mostly didn’t. The manifold project, for example, experiments with language-level delegation to make interface composition practical with Java. https://github.com/manifold-systems/manifold/blob/master/manifold-deps-parent/manifold-delegation/README.md https://github.com/manifold-systems/manifold/blob/master/man...
    • gf000 7mo ago
• Arwill 7mo ago
  Once i heard a manager explain "we must get rid of anything Oracle, including Java, because of license reasons". I see this attitude everywhere since. JavaScript people are too afraid to use Java, that is why something like TypeScript exists. And for personal projects, C# has become a better and more fun "just works" platform.
  • zelphirkalt 7mo ago
    I wouldn't count myself as a JavaScript person at all, and usually avoid it where I can, going to some length, to make pages static, if possible. So I am not exactly in the group of people you are attacking. However, I am afraid of the Java coder who is decorated as senior, has sway due to their position, and who will tell me, that something, that is a simple function, shall not be a simple public static "method", but must be wrapped in yet another object, which I need to instantiate, because OOP, and because obviously I don't know what I am doing, or because it doesn't fit existing "coding practices/style" or "Java style". I am afraid of the Java coder, who for years has not touched anything but Java, because their jobs didn't require anything else, because so many companies want Java. I am afraid of the one who throws around jargon like "dependency injection" all day, without ever using simple terms, or realizing what those things are looking like in another paradigm. Lord, please save me from ever having to work with such obnoxious and uninformed, learning resistant people. This actually may be a straw man, but even one such character matching one or more of those traits, seated above at the seniority ladder will make a mess, that everyone else has to live with.
    • Arwill 7mo ago
      > So I am not exactly in the group of people you are attacking. I wasnt attacking anyone. Developers are used to the lack of type-safety in JS, and assume that having to code in a type-safe language is something hard. Ive seen this attitude multiple times, it is a known topic. The issue you are describing is what the author on top mentioned, the culture. It is not just Java, the "enterprise style" coding has infected other languages too. It is the result of how new developers were educated in a time when for example code performance or code readability were only abstract considerations. I fought that style myself multiple times in the past. But thankfully it is going away now. We are more or less in "chained function call hell" now.
• pjmlp 7mo ago
  Enterprise space architecture is not picky, all programming languages get a place when they manage to hit big at corporate life. It can be Yourdon with C and Pascal, Booch with Smalltalk and C++, Patterns with Smalltalk and C++, UML with Ada, C++, Smalltalk and Java, Rational RUP , Java and .NET application servers, Kubernetes with WebAssembly microservices,.... Ever looked into Typescript with effects, pretending to be Haskell?
• refulgentis 7mo ago
  Front page, 82 comments, comment 2 hours ago…why is this the top comment? “People who write Typescript could just be writing Java except they’re scared of being outcasts for not using design patterns” is bait, not a serious technical opinion. Oh. That’s why it’s the top comment.
• Thaxll 7mo ago
  The fact that you mention Go explicitly hints a real issues with Java.
• hackemmy 7mo ago
  I write TypeScript daily and honestly it is not about being scared of Java. The ecosystem just makes more sense if you are already building for the web. You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. That is a hard thing to replicate in Java even if the language itself is technically better in some areas. The barrier is not cultural fear, it is practical convenience.
  • ivan_gammel 7mo ago
    With SSR/HTMX/HATEOAS the amount of code executed on client side is relatively minor and does not justify the unstable JS/TS tooling and frameworks, and the security nightmare which is NPM-based supply chain.
  • winrid 7mo ago
    What if you have a mobile app? Rest APIs? The argument doesn't work. Every backend language has ways to generate specs/types/clients from the APIs code.
  • chii 7mo ago
    > You write your frontend in JS/TS, your backend in the same language, your build tools understand it natively, and you share types between client and server. that's an excuse imho. It's a post-facto justifying using js on the serverside because of familiarity. I know because the exact same reason was given for GWT (google web toolkit), and that failed pretty horribly (despite it being quite good imho).
    • rossjudson 7mo ago
      GWT was a huge success, and eventually became obsolete -- which is not the same as "failing horribly". It took a long time for the web ecosystem to build up the capabilities that removed the need for GWT. For a while, it was quite a good way to build and heavily optimize certain kinds of web client applications.
      • 7mo ago
• chrysoprace 7mo ago
  The problem is that many jobs with Java (that I've found) lean so heavily towards OOP that it's part of the job description. I just don't enjoy OOP and find that there's almost always a simpler approach, and to have it prescribed as part of the engineering culture will always steer me away.
  • ivan_gammel 7mo ago
    Most of backend development on Java is procedural with OO syntax and ability to replace something in the chain of calls with stub in tests. Spring beans are usually stateless singletons containing a few references.
    • mands 7mo ago
      Yep, I find it easier to think of a Spring (or any DI) Bean like a parameterized module that is applied at runtime, the code within each bean is pretty procedural.
• beachy 7mo ago
  I wonder if at we are standing looking at the smoking field of programming languages created over the last 50 years and gazing at the final survivors, of which Java is definitely one. Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction. I learned IBM /360 assembler when I started in computers a long time ago. I haven't seen a line of assembler in many decades, but I'm sure it's a viable language still if you need it. Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it.
  • nradov 7mo ago
    Programmers would create a new language when there is a fundamental change in hardware architecture such that the assumptions underlying the old programming languages no longer apply. Java is probably a poor choice for writing software in which most computation happens on GPUs. But I agree that someone (or something) will still be using Java to write new line-of-business applications in 50 years.
    • gf000 7mo ago
      Mostly a tongue in cheek reply, but you might be interested in TornadoVM. (Nonetheless, I agree with you)
  • thefaux 7mo ago
    > Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction. Compiler writing can be an art form and not all art is for mass consumption. > Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it. This makes no sense to me. If AI possesses intelligence then it should have no problem learning how to use a new language. If it doesn't possess intelligence, we shouldn't be outsourcing all of our programming to it.
• wotsdat 7mo ago
  [dead]
• pron 7mo ago
  And Java has some advantages that are hard to beat. It performs better than Go and builds just as fast (at least when not using some popular build tools) while offering unmatched deep, low-overhead observability. People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.
  • Capricorn2481 7mo ago
    > and builds just as fast Source? I'm not saying you're lying but I have never seen any Java project build as fast as Go
    • pron 7mo ago
      Use javac directly, in a recent JDK, to compile lots of files at once (i.e. one invocation of javac to compile multiple files) and you'll see. The speed is over 100,000 lines/sec: https://mill-build.org/blog/1-java-compile.html https://mill-build.org/blog/1-java-compile.html
      • voidfunc 7mo ago
        Seriously a need for a new build tool in Java that doesn't fuck around too much.
        • vips7L 7mo ago
          Check out mill from the link. It’s quite good.
          • voidfunc 7mo ago
            Oh sweet. Former Java dev turned Go dev like a decade ago, this looks close to what I want.
        • nekitamo 7mo ago
          100% this. Ant was bad in many ways, but at least it was lightning fast. Gradle is just tragic.
• c0balt 7mo ago
  Maybe this is just a question of taste but I never could get along with Javas (or Kotlin's) tooling. Primarily working in Vim/Helix works for most languages from Nix to Typescript or Rust and C, but Java just never worked quite right. It also generally felt like it had a worse story around tooling from a DX perspective, something like Golang or even npm feels a lot lighter than the molasses of JDK management and gradle et al.
  • owlstuffing 7mo ago
    > Maybe this is just a question of taste but I never could get along with Javas (or Kotlin's) tooling Are you joking? IntelliJ is without a doubt the best dev tooling environment available.
    • c0balt 7mo ago
      No, I'm not. Through university (and even before) I have access to their full suite. I have tried to use PyCharm, GoLand and Idea. Idea was useful for Java but felt quite slow and even with vim bindings was a pain to navigate. Learning the shortcuts helped but it never got quite as fast as helix/vim for general editing (especially as my work usually is a polyglot). It might be the best for Java (compared to eclipse or bluej) but that does not mean it fits my workflow/way of work. PyCharm/GoLand both are "nice" but it did not feel better/more efficient than pylance/pyright)/gopls + vscode/helix. The only I still occasionally use is DataStorm as it is quite a nice SQLite/PostgreSQL client. edit: fixed typo from gostorm -> goland
      • rkomorn 7mo ago
        GoStorm?
        • c0balt 7mo ago
          Thanks for noticing the typo, must've mixed up the PHP and Golang IDEs
  • gf000 7mo ago
• hintymad 7mo ago
  > hell its better than Go for industry purposes Yet if you ask people in the bay area, especially the those who are under 35, they would tell you that "Use Java? Over my deadbody". It's just amazing that people always chase shiny new things.
  • bergheim 7mo ago
    Right because golang is like 2 years old and new o.O
  • chrisweekly 7mo ago
    chasing the new shiny? or running away from the zombie?
  • klooney 7mo ago
    There's so much Java development in the Bay
• materielle 7mo ago
  As a Go developer, this is right on the mark. I’ve been hearing good things about Java lately, so I decided to check out the language for the first time since 2012 or something. And I was impressed! The language maintainers have added so many great features while maintaining backwards compatibility. And slowly but surely improved the JVM and garbage collection. So after toying around for a bit, I decided to write some personal projects in Java. After a week, I gave up and returned to Go. The build tooling is still an over engineered mess. Third party library APIs are still horrible. I will never invest even 5 minutes in learning that horrible Spring framework when stuff like Django, Rails, or the Go ecosystem exist. The community, and thus the online forums and open source libraries, still approach engineering and aesthetics in a way that is completely foreign and off putting to me.
  • chii 7mo ago
    > I will never invest even 5 minutes in learning that horrible Spring framework well there's your problem - why are you using spring for a personal project, when there's so many other simpler, lighter weight frameworks around?
  • EdwardDiego 7mo ago
    Yeah, don't use Spring. If I'm doing DI, I want compile time DI, so Micronaut or Quarkus.
  • gf000 7mo ago
    > Spring framework when stuff like Django, Rails, or the Go ecosystem exist. Django and Rails have a very similar model to Spring, so frankly this is just "I was lazy to learn a new tool and it must suck" kinda take. Is there a learning curve? Sure. Does it worth it? I would say for typical CRUD stuff, yeah. No matter how trivial it is you will likely end up needing something that is a single annotation away. But you may want to try quarkus over spring.
• dyauspitr 7mo ago
  With LLMs as they currently stand, and with the reasonably confident hope they will get better why even have anymore languages. Shouldn’t we just have everything coded in the most performant language which would be Assembly or C?
• 9rx 7mo ago
  > hell its better than Go for industry purposes. [...] the drawback with Java will always be the CULTURE The industry purpose for Go is that all codebases look more or less the same, so workers can jump into any project they've never seen before and instantly feel like they wrote it themselves. Google talked about that a lot around the time Go was released. It is why they created it instead of just adopting Haskell or something. Some of that simply comes down to the language not allowing much creativity, but without the culture developers would still find a way to mess with outcomes. You can still write crazy Go code if you want to. The culture is the piece that matters. If Java doesn't have the culture, how does it fit in industry?
• mghackerlady 7mo ago
  Java isn't even true OO. The only truly OO programming languages that I know of are SmallTalk, Obj-C, and Ruby
  • gf000 7mo ago
    Says a single guy who may have coined the term, but that's not how words work. The industry's millions of devs use it differently, so the de facto meaning is that java is an OOP language, and the original is closer to the actor model.
• lenkite 7mo ago
  Hey even Go has got effective `FactoryFactory` stuff in a lot of open source projects. They just name it differently.
• fzeindl 7mo ago
  That and also the JVM is a marvel of engineering with millions of hours that were poured in by smart people over the last 30 years. It can be as fast a C, supports a multitude of languages, introspection, surveillance etc.
  • Tostino 7mo ago
    JFR is one of my favorite things about the JVM. Such good tooling to figure out whatever it is you are having problems with in production. I've also used Eclipse MAT to find tricky dangling references to objects that caused memory leaks. Definitely not as polished, but extremely useful.
    • fzeindl 7mo ago
      I agree JFR is amazing. Also that you can start it on a running JVM and it that is has minimal ~1% performance overhead.
• phplovesong 7mo ago
  The drawback is also the JVM. Its a heavy, bulky VM. The alternative being Go that is much lighter.
  • gf000 7mo ago
    With all due respect, I'm fairly sure that anyone using "VM" the same way as you do here really think of it as a container or what. It's a runtime, and go also has a similar, fairly fat runtime. It's just burnt into the binary instead of being shipped separately. (Hell, even Rust has a runtime, it's just very very lean compared to languages featuring a full GC like go and java)
    • phplovesong 7mo ago
      You cant seriously compare JVM to the Go runtime. The JVM is on another level in size, complexity and bulkiness and size for a "compiled binary". The Go runtime is mostly just for goroutines and other runtime stuff, like relection etc. A go hello world binary is around 1mb, while the java one is (with a jre) up and around 50mb.
• another_twist 7mo ago
  I dont think the Spring ecosystem is bad. In fact, its one of the more stable frameworks. Even spring AI which is built for AI agents a new use-case is very intuitive if you take time to learn its abstractions. Usually doesnt take more than a day of reading docs and writing some try-out code. The thing I really like about Java is the stability of its packaging ecosystem. Maven is XML (yuck) but is okay with the IDE integrations. Gradle has advanced features often missing in Python / Go such as build caching. The OOP stuff is also good because it scales with very large code bases. In, fact frontend esp React adopted a functional style which leads to complexities associated with hooks. A mixed approach is usually better. Overall, the only bad thing are the multiple unnecessary abstraction layers which are a pain in any language. Rest of Java is quite good.
• saghm 7mo ago
  > All those people using typescript (could be using Java - but the culture doesn't want them and consider them heretics for not embracing religion of OOP and FactoryFactory) I assume you're specifically talking about the backend and not suggesting that people write Applets or use GWT or something.
• peterashford 7mo ago
  There are no FactoryFactorys in Java. Never have been