4 ms·

Slowly but surely, the jvm has been closing the go gap. With efforts like virtual threads, zgc, lilliput, Leyden, and Valhalla, the jvm has been closing the ga

Slowly but surely, the jvm has been closing the go gap. With efforts like virtual threads, zgc, lilliput, Leyden, and Valhalla, the jvm has been closing the gap. The change from Java 8 to 25 is night and day. And the future looks bright. Java is slowly bringing in more language features that make it quite ergonomic to work with.

theshrike79 1y ago
I'm still traumatised by Java from my earlier career. So many weird patterns, FactoryFactories and Spring Framework and ORMs that work 90% of the time and the 10% is pure pain. I have no desire to go back to Java no matter how much the language has evolved. For me C# has filled the void of Java in enterprise/gaming environments.
- arethuza 1y ago
  To be fair those "weird patterns" weren't really Java itself but the crazy culture that grew up around it when it became "enterprise".
  - gf000 1y ago
    And actually coming over from C++!
    - pjmlp 1y ago
      It is incredible how many people think GoF has Java on it, without ever reading anything about the book.
- Orygin 1y ago
  Plus it seems hopeful to think you'll be only working with "New java" paradigm when most enterprise software is stuck on older versions. Just like python, in theory you can make great new green field project but 80% of the work in the industry is on older or legacy components.
  - gf000 1y ago
    Yeah, and you might just be given a mainframe with vacuum tubes.. Like, there are 10 million Java devs, there is a whole lot of completely brand new development going in any language, let alone in such a huge one.
  - lock1 1y ago
    I guess it's reasonable to be hopeful as a Java developer nowadays. Modern Java communities are slowly adopting the common FP practice "making illegal states unrepresentable" and call it "data oriented programming". Which is nice for those of us who actively use ADT. I no longer need to repeatedly explain "what is Option<?>?" or "why ADT?" whenever I use them; I could just point them to those new resources. Hopefully, this shift will steer the Java community toward a saner direction than the current cargo cult which believed mutable C-struct (under guise of "anemic domain model") + Garbage Collector was OOP.
  - vips7L 1y ago
    > most enterprise software is stuck on older versions This simply isn’t true. 60% of the ecosystem has moved beyond Java 8 in the last poll.
- CharlieDigital 1y ago
  C# is a highly underrated language that has evolved very quickly over the last decade into a nice mix of OOP and functional. It's fast enough, easy enough (being very similar now to TypeScript), versatile enough, well-documented (so LLMs do a great job), broad and well-maintained first party libraries, and the team has over time really focused on improving terseness of the language (pattern matching and switch expressions are really one thing I miss a lot when switching between C# and TS). EF Core is also easily one of the best ORMs: super mature, stable, well-documented, performant, easy to use, and expressive. Having been in the Node ecosystem for the past year, there's really no comparison for building fast with less papercuts (Prisma, Drizzle, etc. all abound with papercuts). It's too bad that it seems that many folks I've chatted with have a bad taste from .NET Framework (legacy, Windows only) and may have previously worked in C# when it was Windows only and never gave it another look.
  - theshrike79 1y ago
    I'm still sad that Silverlight[0] (and Moonlight) died because people hated MS so viscerally back then. It was actually really good for the time and lightyears ahead of whatever Flash was doing. But people rather used all kinds of hacks to get Flash working on Linux and OSX rather than use Moonlight. [0] https://en.wikipedia.org/wiki/Microsoft_Silverlight https://en.wikipedia.org/wiki/Microsoft_Silverlight
    - kstrauser 1y ago
      I was so glad it died. It was a weird proprietary replacement for Flash, which itself was weird and proprietary, except the new one was owned by a huge company that publicly stated they wanted to crush Linux and friends. A big chunk of their strategy at the time was around how to completely own the web. I celebrated every time their attempts failed.
    - mhast 1y ago
      As someone who developed in it at the time I found the reason it died was because they made new, slightly incompatible, versions every new Windows release. After a while people got tired of doing updates.
- mohaine 1y ago
  That isn’t Java, but spring. That said, if on the JVM, just use Kotlin.
  - aeonik 1y ago
    Or Clojure, Scala, Groovy. and with the GraalVM, JavaScript/Node, Python, R, and Ruby. among many others.
- lisbbb 1y ago
  I spent untold hours and years mastering inversion of control and late-binding and all those design patterns that were SOOOOO important for interviews only to never really utilize all that stuff because once the apps were built, they rarely, if ever, got reconfigured to do something besides the exact thing they were built for. We might as well have not bothered with any of it and just wrote modular, testable non-OOP code and called it a day. After just about 25 years, I look back at all the time I spent using Spring Framework, Struts, and older products and just kind of shake my head. It was all someone else's money making scheme. I'm also reminded about the time that Tomcat stopped being an application you deploy to and just being an embedded library in the runtime! It was like the collective light went on that Web containers were just a sham. That didn't prevent employers from forcing me to keep using Websphere/WAS because "they paid for that and by god they're going to use it!" Meanwhile it was totally obsolete as docker containers just swept them all by the wayside. I wonder what "Webshere admins" are doing these days? That was once a lucrative role to be able to manage those Jython configs, lol.
- figassis 1y ago
  This, Go came and I just have no desire to go back to those languages spawned from hell that force fed me horrible patterns and called it best practices. Go is amazing in that it lets you tell the machine what you want, simply and you can easily verify that that is indeed what the machine should be doing. Regarding defer, idk about other, but I never assumed it was a gotcha, you read the go docs once and all is just clear and you don’t make most mistakes that others claim are footguns.
clumsysmurf 1y ago
Being able to create a self contained Kotlin app (JVM) that starts up quickly and uses the same amount of memory as the equivalent golang app would be amazing.
- gf000 1y ago
  Graal native Image does that (though the compile time is quite long, but you can just run it on the JVM for development with hot reload and whatnot, and only do a native compile at release)
  - clumsysmurf 1y ago
    From what I have heard, Graal is still quite a headache if you are using libraries that are not compatible, but maybe this is out of date.
    - cogman10 1y ago
      Still an issue. The main problem is for native compilation you have to declare your reflection targets upfront. That can be a headache if your framework doesn't support it. You can get a large portion of what graal native offers by using AppCDS and compressed object headers. Here's the latest JEP for all that. https://openjdk.org/jeps/483 https://openjdk.org/jeps/483
      - gf000 1y ago
        Only those reflection targets that are not "visible" from straight forward code. If you have code that accesses the "stringLiteral" field of a class, then it will be auto-registered for you. But if you access it based on user input, then you have to register it manually. Also, quite a few libraries have metadata now denoting these extra reflection targets. But nonetheless you are right in general, but depends on your use case.
imiric 1y ago
That may be true, but navigating 30 years of accumulated cruft, fragmented ecosystems and tooling, and ever-evolving syntax and conventions, is enough to drive anyone away. Personally, I never want to deal with classpath hell again, though this may have improved since I last touched Java ~15 years ago. Go, with all its faults, tries very hard to shun complexity, which I've found over the years to be the most important quality a language can have. I don't want a language with many features. I want a language with the bare essentials that are robust and well designed, a certain degree of flexibility, and for it to get out of my way. Go does this better than any language I've ever used.
- gf000 1y ago
  I can reasonably likely run a 30 years old compiled, .jar file on the latest Java version. Java is the epitome of backwards and forward-compatible changes, and the language was very carefully grown so the syntax is not too indifferent, someone hibernated since Java 7 will probably have no problem reading Java 25 code. > Go, with all its faults, tries very hard to shun complexity The whole field is about managing complexity. You don't shun complexity, you give tools to people to be able to manage it. And Go goes the low end of the spectrum, of not giving enough features to manage that complexity -- it's simplistic, not simple. I think the optimum as actually at Java - it is a very easy language with not much going on (compared to, say, Scala), but just enough expressivity that you can have efficient and comfortable to use libraries for all kind of stuff (e.g. a completely type safe SQL DSL)
  - imiric 1y ago
    > The whole field is about managing complexity. You don't shun complexity, you give tools to people to be able to manage it. Complexity exists in all layers of computing, from the silicon up. While we can't avoid complexity of real world problems, we can certainly minimize the complexity required for their solutions. There are an infinite amount of problems caused primarily by the self-induced complexity of our software stacks and the hardware it runs on. Choosing a high-level language that deliberately tries to avoid these problems is about the only say I have in this matter, since I don't have the skill nor patience to redo decades of difficult work smarter people than me have done. Just because a language embraces simplicity doesn't mean that it doesn't provide the tools to solve real world problems. Go authors have done a great job of choosing the right set of trade-offs, unlike most other language authors. Most of the time. I still think generics were a mistake.
EFreethought 1y ago
There are still a LOT of places running old versions of Java, like JDK 8. Java is great if you stick to a recent version and update on a regular basis. But a lot of companies hate their own developers.
- gf000 1y ago
  60% is in newer than 8, though. So I wouldn't write down the platform.
skybrian 1y ago
That’s great, but are you still using Maven and Gradle? I’d want to see a popular package manager that doesn’t suck before I’d consider going back. (Similar to how Python is finally getting its act together with the uv tool.)
- gf000 1y ago
  There is Mill, which is pretty cool, but it is quite small. Though Gradle is more than fine with the Kotlin DSL nowadays.
lisbbb 1y ago
My criticism of the JVM is that it is no longer useful because we don't do portability using that mechanism anymore. We build applications that run in containers and can be compiled in the exact type of environment they are going to run inside of and we control all of that. The old days of Sun Microsystems and Java needing to run on Solaris, DEC, HP, maybe SGI, and later Linux, are LOOOOOOONG gone. And yet here we still are with portability inside our portability for ancient reasons.
- gf000 1y ago
  If you believe that's the reason for the JVM (and that it's a "VM" in the traditional sense), you are greatly mistaken. It's like saying C is no longer needed because there is only Arm and x86.. The JVM is a runtime, just like what Go has. It allows for the best observability of any platform (you can literally connect to a prod instance and check e.g. the object allocations) and has stellar performance and stability.
  - cogman10 1y ago
    I don't think that's a mistake. Besides the promise of memory management the "write once run everywhere" promise was a huge selling point of the JVM. So much so that Bill gates famously was terrified of it. "I am literally losing sleep over this issue since together with a move to more server based applications it seems like it could make it easy for people to do competitive operating systems." [1] [1] https://www.joyk.com/dig/detail/1672957813119759#gsc.tab=0 https://www.joyk.com/dig/detail/1672957813119759#gsc.tab=0
  - lisbbb 1y ago
    How can I be "greatly mistaken" about something I worked with for over 20 years? It's people like you with that attitude that only you know things that has bugged me about being in this field for all this time. You're not the only one who deeply studied and mastered all this crap.

theshrike79 1y ago

I'm still traumatised by Java from my earlier career. So many weird patterns, FactoryFactories and Spring Framework and ORMs that work 90% of the time and the 10% is pure pain. I have no desire to go back to Java no matter how much the language has evolved. For me C# has filled the void of Java in enterprise/gaming environments.

arethuza 1y ago
To be fair those "weird patterns" weren't really Java itself but the crazy culture that grew up around it when it became "enterprise".
- gf000 1y ago
  And actually coming over from C++!
  - pjmlp 1y ago
    It is incredible how many people think GoF has Java on it, without ever reading anything about the book.
Orygin 1y ago
Plus it seems hopeful to think you'll be only working with "New java" paradigm when most enterprise software is stuck on older versions. Just like python, in theory you can make great new green field project but 80% of the work in the industry is on older or legacy components.
- gf000 1y ago
  Yeah, and you might just be given a mainframe with vacuum tubes.. Like, there are 10 million Java devs, there is a whole lot of completely brand new development going in any language, let alone in such a huge one.
- lock1 1y ago
  I guess it's reasonable to be hopeful as a Java developer nowadays. Modern Java communities are slowly adopting the common FP practice "making illegal states unrepresentable" and call it "data oriented programming". Which is nice for those of us who actively use ADT. I no longer need to repeatedly explain "what is Option<?>?" or "why ADT?" whenever I use them; I could just point them to those new resources. Hopefully, this shift will steer the Java community toward a saner direction than the current cargo cult which believed mutable C-struct (under guise of "anemic domain model") + Garbage Collector was OOP.
- vips7L 1y ago
  > most enterprise software is stuck on older versions This simply isn’t true. 60% of the ecosystem has moved beyond Java 8 in the last poll.
CharlieDigital 1y ago
C# is a highly underrated language that has evolved very quickly over the last decade into a nice mix of OOP and functional. It's fast enough, easy enough (being very similar now to TypeScript), versatile enough, well-documented (so LLMs do a great job), broad and well-maintained first party libraries, and the team has over time really focused on improving terseness of the language (pattern matching and switch expressions are really one thing I miss a lot when switching between C# and TS). EF Core is also easily one of the best ORMs: super mature, stable, well-documented, performant, easy to use, and expressive. Having been in the Node ecosystem for the past year, there's really no comparison for building fast with less papercuts (Prisma, Drizzle, etc. all abound with papercuts). It's too bad that it seems that many folks I've chatted with have a bad taste from .NET Framework (legacy, Windows only) and may have previously worked in C# when it was Windows only and never gave it another look.
- theshrike79 1y ago
  I'm still sad that Silverlight[0] (and Moonlight) died because people hated MS so viscerally back then. It was actually really good for the time and lightyears ahead of whatever Flash was doing. But people rather used all kinds of hacks to get Flash working on Linux and OSX rather than use Moonlight. [0] https://en.wikipedia.org/wiki/Microsoft_Silverlight https://en.wikipedia.org/wiki/Microsoft_Silverlight
  - kstrauser 1y ago
    I was so glad it died. It was a weird proprietary replacement for Flash, which itself was weird and proprietary, except the new one was owned by a huge company that publicly stated they wanted to crush Linux and friends. A big chunk of their strategy at the time was around how to completely own the web. I celebrated every time their attempts failed.
  - mhast 1y ago
    As someone who developed in it at the time I found the reason it died was because they made new, slightly incompatible, versions every new Windows release. After a while people got tired of doing updates.
mohaine 1y ago
That isn’t Java, but spring. That said, if on the JVM, just use Kotlin.
- aeonik 1y ago
  Or Clojure, Scala, Groovy. and with the GraalVM, JavaScript/Node, Python, R, and Ruby. among many others.
lisbbb 1y ago
I spent untold hours and years mastering inversion of control and late-binding and all those design patterns that were SOOOOO important for interviews only to never really utilize all that stuff because once the apps were built, they rarely, if ever, got reconfigured to do something besides the exact thing they were built for. We might as well have not bothered with any of it and just wrote modular, testable non-OOP code and called it a day. After just about 25 years, I look back at all the time I spent using Spring Framework, Struts, and older products and just kind of shake my head. It was all someone else's money making scheme. I'm also reminded about the time that Tomcat stopped being an application you deploy to and just being an embedded library in the runtime! It was like the collective light went on that Web containers were just a sham. That didn't prevent employers from forcing me to keep using Websphere/WAS because "they paid for that and by god they're going to use it!" Meanwhile it was totally obsolete as docker containers just swept them all by the wayside. I wonder what "Webshere admins" are doing these days? That was once a lucrative role to be able to manage those Jython configs, lol.
figassis 1y ago
This, Go came and I just have no desire to go back to those languages spawned from hell that force fed me horrible patterns and called it best practices. Go is amazing in that it lets you tell the machine what you want, simply and you can easily verify that that is indeed what the machine should be doing. Regarding defer, idk about other, but I never assumed it was a gotcha, you read the go docs once and all is just clear and you don’t make most mistakes that others claim are footguns.

clumsysmurf 1y ago

Being able to create a self contained Kotlin app (JVM) that starts up quickly and uses the same amount of memory as the equivalent golang app would be amazing.

gf000 1y ago
Graal native Image does that (though the compile time is quite long, but you can just run it on the JVM for development with hot reload and whatnot, and only do a native compile at release)
- clumsysmurf 1y ago
  From what I have heard, Graal is still quite a headache if you are using libraries that are not compatible, but maybe this is out of date.
  - cogman10 1y ago
    Still an issue. The main problem is for native compilation you have to declare your reflection targets upfront. That can be a headache if your framework doesn't support it. You can get a large portion of what graal native offers by using AppCDS and compressed object headers. Here's the latest JEP for all that. https://openjdk.org/jeps/483 https://openjdk.org/jeps/483
    - gf000 1y ago
      Only those reflection targets that are not "visible" from straight forward code. If you have code that accesses the "stringLiteral" field of a class, then it will be auto-registered for you. But if you access it based on user input, then you have to register it manually. Also, quite a few libraries have metadata now denoting these extra reflection targets. But nonetheless you are right in general, but depends on your use case.

imiric 1y ago

That may be true, but navigating 30 years of accumulated cruft, fragmented ecosystems and tooling, and ever-evolving syntax and conventions, is enough to drive anyone away. Personally, I never want to deal with classpath hell again, though this may have improved since I last touched Java ~15 years ago. Go, with all its faults, tries very hard to shun complexity, which I've found over the years to be the most important quality a language can have. I don't want a language with many features. I want a language with the bare essentials that are robust and well designed, a certain degree of flexibility, and for it to get out of my way. Go does this better than any language I've ever used.

gf000 1y ago
I can reasonably likely run a 30 years old compiled, .jar file on the latest Java version. Java is the epitome of backwards and forward-compatible changes, and the language was very carefully grown so the syntax is not too indifferent, someone hibernated since Java 7 will probably have no problem reading Java 25 code. > Go, with all its faults, tries very hard to shun complexity The whole field is about managing complexity. You don't shun complexity, you give tools to people to be able to manage it. And Go goes the low end of the spectrum, of not giving enough features to manage that complexity -- it's simplistic, not simple. I think the optimum as actually at Java - it is a very easy language with not much going on (compared to, say, Scala), but just enough expressivity that you can have efficient and comfortable to use libraries for all kind of stuff (e.g. a completely type safe SQL DSL)
- imiric 1y ago
  > The whole field is about managing complexity. You don't shun complexity, you give tools to people to be able to manage it. Complexity exists in all layers of computing, from the silicon up. While we can't avoid complexity of real world problems, we can certainly minimize the complexity required for their solutions. There are an infinite amount of problems caused primarily by the self-induced complexity of our software stacks and the hardware it runs on. Choosing a high-level language that deliberately tries to avoid these problems is about the only say I have in this matter, since I don't have the skill nor patience to redo decades of difficult work smarter people than me have done. Just because a language embraces simplicity doesn't mean that it doesn't provide the tools to solve real world problems. Go authors have done a great job of choosing the right set of trade-offs, unlike most other language authors. Most of the time. I still think generics were a mistake.

EFreethought 1y ago

There are still a LOT of places running old versions of Java, like JDK 8. Java is great if you stick to a recent version and update on a regular basis. But a lot of companies hate their own developers.

gf000 1y ago
60% is in newer than 8, though. So I wouldn't write down the platform.

skybrian 1y ago

That’s great, but are you still using Maven and Gradle? I’d want to see a popular package manager that doesn’t suck before I’d consider going back. (Similar to how Python is finally getting its act together with the uv tool.)

gf000 1y ago
There is Mill, which is pretty cool, but it is quite small. Though Gradle is more than fine with the Kotlin DSL nowadays.

lisbbb 1y ago

My criticism of the JVM is that it is no longer useful because we don't do portability using that mechanism anymore. We build applications that run in containers and can be compiled in the exact type of environment they are going to run inside of and we control all of that. The old days of Sun Microsystems and Java needing to run on Solaris, DEC, HP, maybe SGI, and later Linux, are LOOOOOOONG gone. And yet here we still are with portability inside our portability for ancient reasons.

gf000 1y ago
If you believe that's the reason for the JVM (and that it's a "VM" in the traditional sense), you are greatly mistaken. It's like saying C is no longer needed because there is only Arm and x86.. The JVM is a runtime, just like what Go has. It allows for the best observability of any platform (you can literally connect to a prod instance and check e.g. the object allocations) and has stellar performance and stability.
- cogman10 1y ago
  I don't think that's a mistake. Besides the promise of memory management the "write once run everywhere" promise was a huge selling point of the JVM. So much so that Bill gates famously was terrified of it. "I am literally losing sleep over this issue since together with a move to more server based applications it seems like it could make it easy for people to do competitive operating systems." [1] [1] https://www.joyk.com/dig/detail/1672957813119759#gsc.tab=0 https://www.joyk.com/dig/detail/1672957813119759#gsc.tab=0
- lisbbb 1y ago
  How can I be "greatly mistaken" about something I worked with for over 20 years? It's people like you with that attitude that only you know things that has bugged me about being in this field for all this time. You're not the only one who deeply studied and mastered all this crap.