Comment by the_duke

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.

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.

To be fair those "weird patterns" weren't really Java itself but the crazy culture that grew up around it when it became "enterprise".

That isn’t Java, but spring.

That said, if on the JVM, just use Kotlin.

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.

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.

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.

There is Mill, which is pretty cool, but it is quite small.

Though Gradle is more than fine with the Kotlin DSL nowadays.

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)

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

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)

Google is 100% writing a whole load of new services, and Go is 13 years old (even older within Google), so it surely has had ample opportunities to take.

As for hot swap, I haven't heard it being used for production, that's mostly for faster development cycles - though I could be wrong. Generally it is safer to bring up the new version, direct requests over, and shut down the old version. It's problematic to just hot swap classes, e.g. if you were to add a new field to one of your classes, how would old instances that lack it behave?

I love Elixir but you cannot compile it into a single binary, it is massively concurrent but single-threaded slow, and deployment is still nontrivial.

And lists are slower than arrays, even if they provide functional guarantees (everything is a tradeoff…)

That said, pretty much everything else about it is amazing though IMHO and it has unique features you won’t find almost anywhere else

That doesn’t exist yet. Also Elixir is in no way a replacement for Go.

It can’t match it for performance. There’s no mutable array, almost everything is a linked list, and message passing is the only way to share data.

I primarily use Elixir in my day job, but I just had to write high performance tool for data migration and I used Go for that.

My vote is for Elixir as well, but it's not a competitor for multiple important reasons. There are some languages in that niche, although too small and immature, like Crystal, Nim. Still waiting for something better.

P.S. Swift, anyone?

yeah, if the requirement is "makes it pretty straightforward to write reliable, highly concurrent services that don't rely on heavy multithreading", Elixir is a perfect match.

And even without types (which are coming and are looking good), Elixir's pattern matching is a thousands times better than the horror of Go error handling

This one i can get behind.

Swift is my hope for the next big server language. Great type system, great error handling.

I'd swap java with go any day of the week. I never liked how much 'code-padding' is required with java `public static void main`

Java, lol. Enterprise lang with too many abstractions and wrongly interpreted OOP. Absolutely not.

What about php/ruby for web?

Absolutely no on Java. Even if the core language has seen improvements over the years, choosing Java almost certainly means that your team will be tied to using proprietary / enterprise tools (IntelliJ) because every time you work at a Java/C# shop, local environments are tied to IDE configurations. Not to mention Spring -- now every code review will render "Large diffs are not rendered by default." in Github because a simple module in Java must be a new class at least >500 LOC long.