IT Runs on Java 8

That stimulates a pattern of behavior where people emphasize engineering things that differentiate their business from what others are doing. You don't build a tech startup on doing basically what companies that already exist have been doing for years. If you copy those, you'll be exactly like those and not be able to differentiate. Also, startups don't have to worry about supporting still relevant software that they inherited from way back. I't s a clean slate by definition and that means picking current versions of whatever technology is relevant to you. So, this is simply a form of selection bias.

It's actually interesting to see what startups are doing because many normal businesses end up cherry picking what happens there some time later; particularly when those startups survive (most of course don't).

The title mentions Java 8, which is not that old yet. It was basically the current version until last year. 9 and 10 were non LTS releases with only 6 months support. v11 was only released summer last year.

If you use Scala or Kotlin or most other JVM languages, v11 brings very little new to the table that actually matters. It's a very minor release unless you actually use the Java language. GraalVM, which is a popular new related technology is still stuck on v8. Personally, I'm a big Kotlin fan. It looks exactly the same on JDK 11 as it did on JDK 8 and there's no big need to update. Actually because of Android, Kotlin is still biased towards Java 7.

I always look at technology platforms from a point of view of risk management. In a startup, you need to take risks but not across the board. If you go for some new funky storage layer (nosql, event stores, etc.), pair it with some new language nobody is using yet, and a bunch of frameworks that got released on github 3 weeks ago in a pre 1.0 state, then you are taking a lot of risk and the chance increases that some of it won't work out as you hope. It's fine if your startup is about that technology stack but otherwise, you may want to be more conservative and pick your risks more carefully.

If, for example, you need to have some microservice with a bog standard REST API running, pick something that you are comfortable with or plan to take a calculated risk by e.g. trying out a new framework but pairing it with a DB and language you already know.

If your startup is building what is a glorified web shop or something similarly mundane but necessary, there are a few good arguments for just sticking with proven technology. This is why e.g. Spring Boot is pretty popular with some startups. It's simple and new enough that you can get away with it without looking too old fashioned. And if you need to scale an engineering team around that in a hurry, it's kind of nice to have something reasonably widely used, understood, and mature.

People stick with Ruby on Rails for the same reason even though lots of people now pull their nose up for stuff like that. A lot of fintech startups tend to stick with stuff like this. They'll use current versions and might bring in e.g. Scala or Clojure. But overall they are definitely biased towards using more enterprisey stuff.

Funnily enough, node.js is now old enough that you see that creeping into the enterprise world as well. Personally for me that's still in the high risk category due to the high amount of changes and turnover with many npms. I have a few legacy node.js projects and updating their dependencies is an enormous PITA because basically everything breaks if you do that to a node.js project that is more than a few months old. It's like a snapshot of what was fashionable a while back. Most of my remaining Java projects on Github I update once every year or so (or whenever I need to touch them) and typically without any drama whatsoever. V7 or v8 to v11 is mostly a just bumping a few versions. Of course v11 can use them as is so there's no big need to do this. But I like to stay on top of this generally.

If you run a company that still needs to exist in two years, resilience over time is a good thing.

I get why people used to shit on Microsoft, but Microsoft has demonstrated over a number of years that its changed under Satya.

> However the way that this always works is that there is a base that can be written in, but anything non-trivial will have pulled in something that, surprise surprise, is Windows only.

Outside of desktop GUIs, this is simply not true. I'm writing complex, cross-platform systems that work just fine on Windows and Linux (and would on MacOS if I chose to target it).

Hell, even a lot of the tooling is now cross-platform: Visual Studio Code, Azure Data Studio, even Visual Studio and Xamarin run on MacOS!