Java 27

> and, of course, not much can be extrapolated from any benchmark

Right, so one case (which I certainly believe is possible) is very different from “time and time again.”

I worked at a MS "fanboy" company around 2011-2013. Highly competent guys, really Senior Devs, C#, MS SQL, as well as using graph data - with one distinction: it must be MS.

Open Source? No way. Git? No, they relied as die hard MS believers on the MS software called Team Foundation or something like that, that was integrated into Visual Studio Pro - sorry, I forgot about it, I considered it kind of bloat and outdated. Also I couldn't stand the nomenclature. A project was called "Solution" - I died inside, because this sounded like utter nonsense to me, because how do they know it would be one in the end?

While JetBrains as well as Linux quickly iterated through everything and got traction as well as a cadence that overall kind of was paced around sprint cycles that lasted two or four weeks, the company finally started to break up with project management and implemented Scrum.

As the JavaScript guy, the only one, because a customer wanted a SaaS "solution" but with static web content this wasn't really dynamic. I knew one of the founders who was a managing partner and he asked me to join as Web Developer.

Overall, all were very skeptical towards me because how could someone bet on JavaScript at the time? Well I turned the argument around and said the same about C# with its closed source walled garden approach to everything relying on MS to solve their problems with no way of giving feedback while there was no real release cycle and roadmap available - hopium and copium.

Statically typed languages for the win they said, blabla. I wasn't against static types, but did pure magic in JS, that they saw me as magician and I got some fans and I found one team mate who wanted to be coached by me on JS, Ajax and stuff.

So, there you have it. History.

I think there are pros and cons to any approach as always. Both language suffer from feature creep.

C# is still tightly knit into some products from MS and there are some backwards compatibility issues to take care of that limit certain progress and need substantial change.

Java isn't that way and was near dead and went OS. That's why they moved to the current model. Former versions were also hardly changed, have a look at everything before Java Version 12 or so.

Java wasn't community driven all the time.

So, C# has its merits, TypeScript for the win, so MS won over JavaScript ironically but only on the outside.

I shocked my MS fanboy colleagues when I really gave them a shock therapy regarding security when they mocked me with the examples given by MS why JavaScript was so bad and C# would beat it. We all know the infamous type coercion examples with mixed types, arrays etc.

So I shocked them with eval function of course but then gave them nightmares and mental overload with Function.prototype.toString and new Function() trickery.

It blew their mind, there was nothing remotely available in their world. Not introspection, nothing.

JavaScript was kind of assembler like I said. Highly flexible, you need to use modules, like jQuery did but have to build your own.

So TypeScript used exactly this flexibility: compiling to JavaScript. A metalanguage.

For the true insider, JavaScript won.

Oh, net/http recovers from a panic inside a handler and sends error 500. I don't know if that was always the default. Where I worked before, our own Go servers didn't recover, and it did cause outages.

This is kinda bad practice. Go and Rust panics are similar, they aren't exceptions that you can safely recover from. Say there's a panic in the middle of modifying some global state like a database connection. Hence complaints about the net/http recover like https://github.com/golang/go/issues/25245 . But I guess they decided it's worse to let servers crash from trivial mistakes.

By time and time again I meant concurrent services that are written by people who are not experts at low-level programming. The irony is that they don't see "CPU spent on memory management" as they do in Java not because there's less of it - quite often it's much, much more - but because it's simply not measured and reported.

As for the caching test, it's just technically interesting, because the JVM was designed to address the performance issues we suffered from in large C++ programs (all the JVM engineers are, of course, C++ people), both due to compilation and to memory management, and we regularly compare both our compilation and memory management algorithms to other approaches, and it just so happens that last week one of our GC engineers compared Caffeine to Moka and saw how CPU-intensive the memory management work is compared to ZGC (he was particularly interested in this because caching is one of the more challenging workloads for generational moving GCs because a cache deals with many old objects, whereas generational GCs tend to focus more on young objects, and he wanted to make sure that our GCs help reduce the high memory-management overheads associated with low-level languages even in this challenging scenario).

Of course!

But from a quality standpoint there are three concerns:

(1) Do you actually do the code review, do you actually enforce the style?

I worked on a Scala project where the dev manager thought it was preferable to handle errors with monads and would be vociferous about what a great practice that was compared to exceptions and that code review was central to how we do things... but if you looked at the code most of the time errors just got dropped silently and that was the same for many practices that the dev manager told me were doing but that we don't. He still posts on LinkedIn complaining about other dev managers who say they do code review but really don't. Practically that code didn't consistently give the right answers and poor error handling was one reason, another was that they never really understood that teardown was just as important as initialization.

(2) Is your documented practice correct? Is it really doing the right thing?

In a lot of cases there really is a right and wrong way to do things (e.g. uv resolves Python dependencies properly, pip doesn't) but it's less clear in error handling, like sometimes things went wrong and there is no way you can make it right and you can do the best that you can.

The global nature of the problem is vexing. Like an IOException might really be a BackhoeCutAFiberSomewhereInWisconsinException and a segmentation fault is occasionally a YouAskedForAOneAndGotAZeroInsteadException and it's not just academic because, given an exception, you want to answer questions like "Should I retry this operation? How long should I wait before I retry this operation?"

(3) Is this practice something you can sustain? How hard is to do? How much cognitive load does it add and how does it interact with other practices? "Throw up as much as you can", "tear down in finally {}", "otherwise handle local consequences of errors and rethrow" and "really catch errors at the drivers of units of work" is a practice that really works in many languages and is pretty easy to do right, even code that is written without a lot of care will do the right thing or something close by default. I've seen a lot of "no plan for error handling" or "bad plan for error handling"... like I was traumatized by the first C program I saw in a 1984 issue of Byte magazine which was using errno to handle errors which vastly complicated very simple code because the error path was intimately wound with the happy path and in cases like that there tend to be bugs in both of them. When I saw Exceptions in Java I remembered that old C program and thought "I love this!"