Hacker News Reader

Comment by snovymgodym | Hacker News Reader

Java, especially modern Java, is a fine language. The JVM is an awesome runtime. I'm tired of pretending it isn't.

The vast majority of Java developers will never touch modern Java and have zero idea of its features or capabilities. I'm in the process of migrating literally thousands of servers and tens of thousands of apps to the cloud and there isn't anything close to modern Java. The absolute majority at this client seems to be Java 8 and there isn't a single Java 17 or newer. So it's one thing to have great modern features. But if you're going to be a Java developer it'll take work / luck to actually be able to use decent versions of it. Very similar story with C++. If you're on a great cutting edge team, you might be able to use the shiny new stuff. But more than likely you'll be relegated to some C++11 at the latest.

I haven't seen things quite so bad on the .NET side at this client. Yes there's a ton of legacy ASP.NET apps. But there are also a lot of .NET Core apps. They haven't quite made it to the post Core versions of .NET, but it's still a healthier state than I see with Java. I guess all of this to say that modern versions of "ancient" programming languages are great and really do improve things. But chances are if you're working with an ancient programming language you'll be stuck maintaining legacy shit and won't ever get to utilize the shiny stuff.

This is keeping in mind that your average programmer will never even try to interview for FAANG never mind grind leetcode and programming language trivia for weeks like seems so common here.

Well to be fair, if you wanted Performance, Linux support, and a framework which was built with dependency injection and async support in mind and not just have them as patched in footguns, you had to migrate to .NET Core. A Java 8 Spring app was just good enough.

If you want linux support, .net is not what you want.

Linux support is an afterthought and it shows. And you never know if it might be dropped next year.

Wrong. Linux support is first class in .Net just like Windows. We are strictly running our .Net code on linux servers and have encountered 0 problems over the past 5 years.

3 seconds of looking at the API and you see it's not 1st class at all. Presuming you have ever done any programming on linux, that is.

> The API

Which one?

the ones dealing with processes are very obviously a terrible match for posix systems for example.

Don't bother: https://news.ycombinator.com/item?id=43396171

These people could not care less about engaging with the subject, they are here because they feel obliged to engage in a moment of hatred of what they think is an enemy tribe.

Wow what a thread!

I mean… I provided justifications and links. The fact that you choose to disregard all of that is on you.

And the bit where you got angry because I didn't reply quick enough on an internet forum shows that perhaps you need to improve your manners.

If you are a .NET shop, .NET core still has a better Linux than Legacy .NET framework hence the migration.

If you are a Java shop everything just works so why touch it?

How do you tell systemd/sysv that your daemon is now ready to accept connections? How do you log to syslog?

In java there's no equivalent to daemon() (unless you go out of your way to call the libc) and java doesn't support SOCK_DGRAM for unix sockets, so no syslog either.

.net seems to have the same issues.

"everything just works" is true only for a very very narrow definition of "everything" which leaves out "daemon that works decently"

We've had this conversation before, it's likely a waste to reply but, well, my mistake.

For those interested as to why: https://news.ycombinator.com/item?id=43396171

A few more arguments while we're at it:

https://dotnet.microsoft.com/en-us/platform/telemetry (Linux leads with 77% of all systems invoking .NET CLI commands)

https://github.com/dotnet/runtime/blob/main/src/libraries/Sy... (first-class epoll/kqueue integration with async, much like the one Go has with goroutines via netpoll)

https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/u... (GC implementation is cgroups-aware, unlike Go)

This just anecdotal evidence of your one client. Every statistic I’ve seen shows that at least half is on a runtime > 8, with most in that half being on 17 or 21. My entire company runs on 21 and will be moving to 25 when it’s out.

Reply on news.ycombinator.com