3 ms·

Java is still an excellent option in many respects. Notably it has: - mature generics - streams - exceptions - rock solid for server apps - some FP style libra

Java is still an excellent option in many respects. Notably it has: - mature generics - streams - exceptions - rock solid for server apps - some FP style libraries - good timing - probably the widest universe of libraries Only downsides are, 1) JVM startup times and 2) it's not the newest shiny thing. I looked at the whole language comparison recently for a greenfields project. While initially optimistic, I was surprised how many capabilities some new alternatives are missing, and by the enthusiasm to write thousands of lines of low value C-style error checking. An architectural assessment: Above a trivial level of software, the majority of code composes something that can fail. Exceptions are an ideal mechanism for this general truth.

jerf 5y ago
I have thought before that if Java's interfaces worked like Go's did, with implicit satisfaction instead of having to declare explicitly, that there would probably be no Go. If I could go back and change one thing about Java, that's what it would be. I know there's other more obvious pain points that most people would pick, but I think this is a subtle one that undergirds several of the more obvious ones. (To be clear, I am aware that Go and Java still have differences beyond that; my claim is that with this change Java would have been "good enough" that Go either never would have been spec'd or it never would have gotten any traction if it was. Java, however, has left a significant window open for Go because it has gained traction.) The problem with the way Java does it is that it forces a temporal dependency between interface and implementation, all to avoid a programmer error which on average will happen less than once per programmer career: http://www.jerf.org/iri/post/2954 http://www.jerf.org/iri/post/2954 This causes a lot of gyrations to be necessary to use them properly, which starts introducing the desire for heavyweight ways of autogenerating this, etc. and roll around that cycle a few times and that's how you end up with as much XML as code in your codebase. I think Java and Go are a really interesting case study for people interested in programming languages, because on paper they are virtually identical languages (especially if you ignore channels and select in Go), and it gives a clean demonstration of how even those not-very-large differences end up having a profound effect on how solving problems in those languages are best done.
- jatone 5y ago
  I mean the GC pause times and static binaries are huge to me as well vs java. go is just a better languages to develop with in my mind. I have to spend less time optimizing and more time getting shit done.

jerf 5y ago

I have thought before that if Java's interfaces worked like Go's did, with implicit satisfaction instead of having to declare explicitly, that there would probably be no Go. If I could go back and change one thing about Java, that's what it would be. I know there's other more obvious pain points that most people would pick, but I think this is a subtle one that undergirds several of the more obvious ones. (To be clear, I am aware that Go and Java still have differences beyond that; my claim is that with this change Java would have been "good enough" that Go either never would have been spec'd or it never would have gotten any traction if it was. Java, however, has left a significant window open for Go because it has gained traction.) The problem with the way Java does it is that it forces a temporal dependency between interface and implementation, all to avoid a programmer error which on average will happen less than once per programmer career: http://www.jerf.org/iri/post/2954 http://www.jerf.org/iri/post/2954 This causes a lot of gyrations to be necessary to use them properly, which starts introducing the desire for heavyweight ways of autogenerating this, etc. and roll around that cycle a few times and that's how you end up with as much XML as code in your codebase. I think Java and Go are a really interesting case study for people interested in programming languages, because on paper they are virtually identical languages (especially if you ignore channels and select in Go), and it gives a clean demonstration of how even those not-very-large differences end up having a profound effect on how solving problems in those languages are best done.

jatone 5y ago
I mean the GC pause times and static binaries are huge to me as well vs java. go is just a better languages to develop with in my mind. I have to spend less time optimizing and more time getting shit done.