9 ms·

I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instea

I personally appreciate Java (and the JVM) much more after having tried other languages/ecosystems that people kept saying were so much better than Java. Instead, I just felt like it was a "the grass is greener" every time. The only other language that I felt was an actual massive improvement is Rust (which so far has been a joy to work with). It's a shame imo that it's not seen as a "cool" option for startups, because at this point, the productivity gap compared to other languages is small, if nonexistent.

sapiogram 1y ago
My feelings exactly. Go was particularly disappointing, it promised everything but only felt like a sidegrade from Java. Screw it, a downgrade, until go errors get stack traces.
- overfeed 1y ago
  The reason I prefer the Go ecosystem to Java is cultural, rather than technical. Sure, the JVM is very impressive and the language has been evolving, but the culture around Java seems to encourage needless complexity. Of all the languages I've had to work with trying to get to know unfamiliar code-bases, it's the Go codebases I've been quickest to grok, and yielded the fewest surprises since as the code I'm looking for is almost always where I expect it to be.
  - skydhash 1y ago
    I think kotlin is what Java should have been like. The same capabilities but with less cumbersome constraints.
    - ori_b 1y ago
      When I used Kotlin, it felt like Java, but with the antipatterns baked in as language features.
      - complexworld 1y ago
        Could you explain which antipatterns you're referring to?
        ori_b 1y ago
        Leaning heavily into object orientation, including baking in things like companion objects, object expressions, etc. Encouraging utility classes that tack half-baked functionality onto existing types. Smart casts encouraging overly complex hierarchy. While operator overloading and infix functions aren't a Java anti-pattern, I also think the language would be improved by their removal.
        int_19h 1y ago
        Even if you sincerely believe that OOP is an anti-pattern, surely it was firmly "baked into the language" in Java already? Kotlin is fundamentally a better Java, not a rebuttal to Java.
    - Zambyte 1y ago
      It is all but impossible to use Kotlin without an IDE telling you everything, and for that I find the language interesting. And for comparison, I did in fact write Java without an IDE for an extended period of time.
  - whartung 1y ago
    The don't embrace that culture. Embrace a simpler culture. Strive for simplicity. Push for fewer dependencies. Simple example, JAX-RS running on top of Java SE. I agree, JAX-RS is not what one might call "simple". It IS complex, or I should say, it CAN be complex. But Happy Path, staying in the middle of the road, it's pretty sweet for knocking out HTTP backed services. The Jersey reference implementation will do most anything you need (including stuff not "included" in raw JAX-RS). No need for a container, no need for a lot that stuff and all that hanger-on. The core runtime is pretty broad and powerful. Consider my current project, it uses the built in Java HTTP server. Which works! It's fast, it's functional, it's free. (Yes, it's in a com.sun.net... package, but it's not going anywhere.) It's awkward to use. It's aggravatingly raw. It follows the tenet "why be difficult, when, with just a little effort, you can be impossible." So, I wrote a simple "servlet-esque-ish" inspired layer for response and request handling, a better path based regex-y router, and a nicer query parser for queries and forms. 500 lines. Add on a JSON library and I can process JSON-y web request/response, easily. (I also wrote my own Multipart processor -- that was another 500 lines, boy that was fun, but most folks don't need that.) A little bit of code and the built in server is MUCH easier to use. No tomcat, no deploys, zip. ...and no dependencies (save the JSON library). Something all of these cool frameworks and such have shown me is what's really nice to have, but at the same time, just what isn't really necessary to get work done. I mean, CDI is really neat. Very cool. But, whoo boy. So I have a single singleton to handle application life cycle and global services. It works great with tests. I have a 50 line Event Bus. I have a 100 line "Workflow Engine". 150 line java.util.Logger wrapper (which is mostly, you know, wrapper). I wrote that way back whenever they introduced varargs to java (Java 5? 6?). The modern Java logging landscape is just...oh boy. I'm content with JUL -- I can make it work. My current project is "magic free". I think @Overide in the single annotation anywhere in it. But it's comfortable to use, the cognitive load is quite load (outside of the actual application itself, which is NOT low -- sheesh). No swearing at frameworks. It's all my fault :). Anyway, the point is that "simple Java" lurks in there. It needs a bit of uplifting, but not a lot.
    - wpollock 1y ago
      You've made your point, but note the built-in HTTPS server only supports TLS 1.2, so don't use that for production code. (For testing it's probably fine.)
  - LtWorf 1y ago
    True, but the culture around go isn't any better. In my experience go developers are former java developers so they have the same culture of thinking it's ok to ignore how a unix system works. So you will have awful logging, daemons that never report they're ready, badly handmade command line parsing and so on.
- deleted 1y ago
  [deleted]
- arccy 1y ago
  funny. java is known for its stacktraces where you need 3 vertical monitors stacked together to see the whole thing and it still doesn't tell you anything useful about why the app crashed.
  - marginalia_nu 1y ago
    I think that's a bit unfair. Generally the stacktraces tell you exactly what and where the problem is. Generally shouldn't be more than a dozen lines or so. The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.
  - hu3 1y ago
    as someone who had to deal with Java stack traces the entire week, I feel attacked. God bless Gemini 2.5 Pro which ate all the traces for breakfast.
  - frontfor 1y ago
    Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.
    - lenkite 1y ago
      Tip of the Day: You can wrap errors using "fmt.Errorf" in Go - this gives you a nice chain of error messages which is a pseudo stack trace. Another tip is to define and leverage sentinel errors when wrapping errors so you can test using "errors.Is" higher up when doing error handling in the call-hierarchy - like when mapping to http errors or exit codes. Using "fmt.Errorf" is lean and painless compared to defining custom errors.
      - dontlaugh 1y ago
        It’s still not stack traces for every error, which is the default in every other language with stack unwinding. In practice you have to use a combination of error wrapping and custom stack trace errors for your production logs to be useful on failure. The stdlib errors really should have stack traces.
bdangubic 1y ago
same! mid-way through my almost 3 decade career I got bored and thought lets try some non-JVM projects, for 2 years I took projects using other languages etc… worse two years of my career :)
bsaul 1y ago
Funny. I've been trying rust for the past 2 months fulltime, and i'm really wondering how you can call it a "joy to work with" when compared to java, at least for server development. Rust feels like walking on a minefield, praying to never meet any lifetime problem that's going to ruin your afternoon productivity ( recently lost an afternoon on something that could very well be a known compiler bug, but on a method with such a horrible signature that i never can be sure. in the end i recoded the thing with macros instead). The feeling of typesafety is satisfying , i agree. But calling the overall experience a "joy" ?
- mynameisash 1y ago
  > I've been trying rust for the past 2 months fulltime, > recently lost an afternoon on something that could very well be a known compiler bug With respect, at two months, you're still in the throes of the learning curve, and it seems highly unlikely you've found a compiler bug. Most folks (myself included) struggled for a few months before we hit the 'joyful' part of Rust.
  - johnisgood 1y ago
    Okay, but I have hit the joyful part of some other languages long before a few months. What gives?
    - asa400 1y ago
      Rust is genuinely novel, so for most of us its going to be less familiar, so it will take longer to learn. It's not like learning Python if you already know Ruby, for example. The upside is that it offers some pretty great guarantees you can't (yet) find elsewhere. If you want those guarantees it will be worth it, if those guarantees don't matter to you, it may feel like a slog.
      - johnisgood 1y ago
        What guarantees are you speaking of exactly?
deepsun 1y ago
My opinion on that is the projects scale. Typically people came from a 10+ year Java project of 100+ engineers, to a greenfield advanced hello-world -- of course it's going to feel better and more productive. Also, as open-source folks say, "rewrite is always better". It also serves as a good security review. But companies typically don't have resources to do complete rewrites every so often, I saw it only in Google.
- sabellito 1y ago
  I've worked in 3 of the biggest rails codebases in the world (Shopify being the last) and I can say from experience that rails legacy monoliths are infinitely worse to work with than some awful, but harmless, sea of struts XML legacy.
  - stevoski 1y ago
    I find this really interesting, and meets my (limited) Rails experience and (extensive) Java experience: I found it hard taking over an existing Rails project - it felt frail to me, that any small change might have unexpected consequences. Whereas when I've taken over Java projects - or come in late to an existing team - I felt quite confident getting started, even if it is a bit of a mess.
    - sabellito 1y ago
      It's mostly because of the compiler, but ruby also makes it extremely easy to shoot oneself in the foot with magic.
kllrnohj 1y ago
Personally I think C# is miles ahead of Java and in meaningful ways (like a drastically better implementation of generics, not to mention value types have existed for eons at this point and an FFI system that doesn't hate you for using it) But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.
- bsaul 1y ago
  Problem with C# isn't the language, it's the enterprise ecosystem. You always feel like you're going to have to pay at some point down the road for using the tech.
  - cgh 1y ago
    Every large company I’ve ever worked at had a strict “no Microsoft on the server” policy and for better or worse, C# is closely identified with Microsoft.
    - runjake 1y ago
      IOW Linux on the server?
  - hu3 1y ago
    I don't see Java being any better in this regard. Microsoft has been historically much less aggressive with lawyers compared to Oracle.
    - frontfor 1y ago
      That might be true for other Oracle products like the DB, but has that been true for Java and openjdk?
      - homebrewer 1y ago
        Sure. Here's just one example I was able to quickly find in the browser history: https://www.theregister.com/2025/05/09/users_advised_to_review_oracle_java_use/ https://www.theregister.com/2025/05/09/users_advised_to_revi... You can easily just not use the Oracle JDK, though, unless you're running commercial software which requires running on the Oracle runtime to get technical support. As others have said, the problem is not the runtime, but libraries: many major .NET libraries have been going fully commercial, you can't really trust the ecosystem anymore.
watwut 1y ago
Same here. I started to really like java after working with js/ts on small to medium project. I started to love java after working in on medium to little big project.

sapiogram 1y ago

My feelings exactly. Go was particularly disappointing, it promised everything but only felt like a sidegrade from Java. Screw it, a downgrade, until go errors get stack traces.

overfeed 1y ago
The reason I prefer the Go ecosystem to Java is cultural, rather than technical. Sure, the JVM is very impressive and the language has been evolving, but the culture around Java seems to encourage needless complexity. Of all the languages I've had to work with trying to get to know unfamiliar code-bases, it's the Go codebases I've been quickest to grok, and yielded the fewest surprises since as the code I'm looking for is almost always where I expect it to be.
- skydhash 1y ago
  I think kotlin is what Java should have been like. The same capabilities but with less cumbersome constraints.
  - ori_b 1y ago
    When I used Kotlin, it felt like Java, but with the antipatterns baked in as language features.
    - complexworld 1y ago
      Could you explain which antipatterns you're referring to?
      - ori_b 1y ago
        Leaning heavily into object orientation, including baking in things like companion objects, object expressions, etc. Encouraging utility classes that tack half-baked functionality onto existing types. Smart casts encouraging overly complex hierarchy. While operator overloading and infix functions aren't a Java anti-pattern, I also think the language would be improved by their removal.
        int_19h 1y ago
        Even if you sincerely believe that OOP is an anti-pattern, surely it was firmly "baked into the language" in Java already? Kotlin is fundamentally a better Java, not a rebuttal to Java.
  - Zambyte 1y ago
    It is all but impossible to use Kotlin without an IDE telling you everything, and for that I find the language interesting. And for comparison, I did in fact write Java without an IDE for an extended period of time.
- whartung 1y ago
  The don't embrace that culture. Embrace a simpler culture. Strive for simplicity. Push for fewer dependencies. Simple example, JAX-RS running on top of Java SE. I agree, JAX-RS is not what one might call "simple". It IS complex, or I should say, it CAN be complex. But Happy Path, staying in the middle of the road, it's pretty sweet for knocking out HTTP backed services. The Jersey reference implementation will do most anything you need (including stuff not "included" in raw JAX-RS). No need for a container, no need for a lot that stuff and all that hanger-on. The core runtime is pretty broad and powerful. Consider my current project, it uses the built in Java HTTP server. Which works! It's fast, it's functional, it's free. (Yes, it's in a com.sun.net... package, but it's not going anywhere.) It's awkward to use. It's aggravatingly raw. It follows the tenet "why be difficult, when, with just a little effort, you can be impossible." So, I wrote a simple "servlet-esque-ish" inspired layer for response and request handling, a better path based regex-y router, and a nicer query parser for queries and forms. 500 lines. Add on a JSON library and I can process JSON-y web request/response, easily. (I also wrote my own Multipart processor -- that was another 500 lines, boy that was fun, but most folks don't need that.) A little bit of code and the built in server is MUCH easier to use. No tomcat, no deploys, zip. ...and no dependencies (save the JSON library). Something all of these cool frameworks and such have shown me is what's really nice to have, but at the same time, just what isn't really necessary to get work done. I mean, CDI is really neat. Very cool. But, whoo boy. So I have a single singleton to handle application life cycle and global services. It works great with tests. I have a 50 line Event Bus. I have a 100 line "Workflow Engine". 150 line java.util.Logger wrapper (which is mostly, you know, wrapper). I wrote that way back whenever they introduced varargs to java (Java 5? 6?). The modern Java logging landscape is just...oh boy. I'm content with JUL -- I can make it work. My current project is "magic free". I think @Overide in the single annotation anywhere in it. But it's comfortable to use, the cognitive load is quite load (outside of the actual application itself, which is NOT low -- sheesh). No swearing at frameworks. It's all my fault :). Anyway, the point is that "simple Java" lurks in there. It needs a bit of uplifting, but not a lot.
  - wpollock 1y ago
    You've made your point, but note the built-in HTTPS server only supports TLS 1.2, so don't use that for production code. (For testing it's probably fine.)
- LtWorf 1y ago
  True, but the culture around go isn't any better. In my experience go developers are former java developers so they have the same culture of thinking it's ok to ignore how a unix system works. So you will have awful logging, daemons that never report they're ready, badly handmade command line parsing and so on.
deleted 1y ago
[deleted]
arccy 1y ago
funny. java is known for its stacktraces where you need 3 vertical monitors stacked together to see the whole thing and it still doesn't tell you anything useful about why the app crashed.
- marginalia_nu 1y ago
  I think that's a bit unfair. Generally the stacktraces tell you exactly what and where the problem is. Generally shouldn't be more than a dozen lines or so. The main area they get excessively lengthy is in certain frameworks and testing tools that can add like 100 lines to the trace.
- hu3 1y ago
  as someone who had to deal with Java stack traces the entire week, I feel attacked. God bless Gemini 2.5 Pro which ate all the traces for breakfast.
- frontfor 1y ago
  Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.
  - lenkite 1y ago
    Tip of the Day: You can wrap errors using "fmt.Errorf" in Go - this gives you a nice chain of error messages which is a pseudo stack trace. Another tip is to define and leverage sentinel errors when wrapping errors so you can test using "errors.Is" higher up when doing error handling in the call-hierarchy - like when mapping to http errors or exit codes. Using "fmt.Errorf" is lean and painless compared to defining custom errors.
    - dontlaugh 1y ago
      It’s still not stack traces for every error, which is the default in every other language with stack unwinding. In practice you have to use a combination of error wrapping and custom stack trace errors for your production logs to be useful on failure. The stdlib errors really should have stack traces.

bdangubic 1y ago

same! mid-way through my almost 3 decade career I got bored and thought lets try some non-JVM projects, for 2 years I took projects using other languages etc… worse two years of my career :)

bsaul 1y ago

Funny. I've been trying rust for the past 2 months fulltime, and i'm really wondering how you can call it a "joy to work with" when compared to java, at least for server development. Rust feels like walking on a minefield, praying to never meet any lifetime problem that's going to ruin your afternoon productivity ( recently lost an afternoon on something that could very well be a known compiler bug, but on a method with such a horrible signature that i never can be sure. in the end i recoded the thing with macros instead). The feeling of typesafety is satisfying , i agree. But calling the overall experience a "joy" ?

mynameisash 1y ago
> I've been trying rust for the past 2 months fulltime, > recently lost an afternoon on something that could very well be a known compiler bug With respect, at two months, you're still in the throes of the learning curve, and it seems highly unlikely you've found a compiler bug. Most folks (myself included) struggled for a few months before we hit the 'joyful' part of Rust.
- johnisgood 1y ago
  Okay, but I have hit the joyful part of some other languages long before a few months. What gives?
  - asa400 1y ago
    Rust is genuinely novel, so for most of us its going to be less familiar, so it will take longer to learn. It's not like learning Python if you already know Ruby, for example. The upside is that it offers some pretty great guarantees you can't (yet) find elsewhere. If you want those guarantees it will be worth it, if those guarantees don't matter to you, it may feel like a slog.
    - johnisgood 1y ago
      What guarantees are you speaking of exactly?

deepsun 1y ago

My opinion on that is the projects scale. Typically people came from a 10+ year Java project of 100+ engineers, to a greenfield advanced hello-world -- of course it's going to feel better and more productive. Also, as open-source folks say, "rewrite is always better". It also serves as a good security review. But companies typically don't have resources to do complete rewrites every so often, I saw it only in Google.

sabellito 1y ago
I've worked in 3 of the biggest rails codebases in the world (Shopify being the last) and I can say from experience that rails legacy monoliths are infinitely worse to work with than some awful, but harmless, sea of struts XML legacy.
- stevoski 1y ago
  I find this really interesting, and meets my (limited) Rails experience and (extensive) Java experience: I found it hard taking over an existing Rails project - it felt frail to me, that any small change might have unexpected consequences. Whereas when I've taken over Java projects - or come in late to an existing team - I felt quite confident getting started, even if it is a bit of a mess.
  - sabellito 1y ago
    It's mostly because of the compiler, but ruby also makes it extremely easy to shoot oneself in the foot with magic.

kllrnohj 1y ago

Personally I think C# is miles ahead of Java and in meaningful ways (like a drastically better implementation of generics, not to mention value types have existed for eons at this point and an FFI system that doesn't hate you for using it) But nobody seems to talk about or care about C# except for Unity. Microsoft really missed the boat on getting mindshare for it back in the day.

bsaul 1y ago
Problem with C# isn't the language, it's the enterprise ecosystem. You always feel like you're going to have to pay at some point down the road for using the tech.
- cgh 1y ago
  Every large company I’ve ever worked at had a strict “no Microsoft on the server” policy and for better or worse, C# is closely identified with Microsoft.
  - runjake 1y ago
    IOW Linux on the server?
- hu3 1y ago
  I don't see Java being any better in this regard. Microsoft has been historically much less aggressive with lawyers compared to Oracle.
  - frontfor 1y ago
    That might be true for other Oracle products like the DB, but has that been true for Java and openjdk?
    - homebrewer 1y ago
      Sure. Here's just one example I was able to quickly find in the browser history: https://www.theregister.com/2025/05/09/users_advised_to_review_oracle_java_use/ https://www.theregister.com/2025/05/09/users_advised_to_revi... You can easily just not use the Oracle JDK, though, unless you're running commercial software which requires running on the Oracle runtime to get technical support. As others have said, the problem is not the runtime, but libraries: many major .NET libraries have been going fully commercial, you can't really trust the ecosystem anymore.

watwut 1y ago

Same here. I started to really like java after working with js/ts on small to medium project. I started to love java after working in on medium to little big project.