Comment by imiric

1 day 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.

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)

  • you shun unnecessary complexity.

    If you dont think that exists in java, spend some time in the maven documentation or spring documentation https://docs.spring.io/spring-framework/reference/index.html https://maven.apache.org/guides/getting-started/ Then imagine yourself a beginner to programming trying to make sense of that documentation

    you try keep the easy things easy + simple, and try to make the hard things easier and simpler, if possible. Simple aint easy

    I dont hate java (anymore), it has plenty of utility, (like say...jira). But when I'm writing golang I pretty much never think "oh I wish this I was writing java right now." no thanks

    • Well, spring is a whole framework that gives you a lot of stuff, but sure, complexity has to live somewhere - fundamentally so.

      Without it, you either write that complexity yourself or fail to even recognize why is it necessary in the first place, e.g. failing to realize the existence of SQL injections, Cross-Site Scripting, etc. Backends have some common requirements and it is pretty rare that your problem wouldn't need these primitives, so as a beginner, I would advice.. learning the framework as well, the same way you would learn how to fly a plane before attempting it.

      For other stuff, there is no requirement to use Spring - vanilla java has a bunch of tools and feel free to hack whatever you want!

  • > I can reasonably likely run a 30 years old compiled, .jar file on the latest Java version.

    Great, pretty much every language ever can do the equivalent. Not what anyone is talking about.

    > Java is the epitome of backwards and forward-compatible changes,

    Is the number of companies stuck on Java 8 lower than 50% yet? [1]

    [1]: https://www.jetbrains.com/lp/devecosystem-2023/java/

    • > Great, pretty much every language ever can do the equivalent. Not what anyone is talking about

      Go already has a breaking change.

      > Java 8

      Yes

  • > 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.