hugofirth

What specific example or point from the blog post do you disagree with?

I wish Swift wasn’t so tied to the Apple ecosystem, as it has (IMO) a good mix of these

This is not the title of the article, kinda biases the reader to the outcome of the debate don’t you think?

Man I was frustrated by this article. Despite it being on a subject matter I normally ignore, it lured me in with the promise to “dig into data publicly in a way that (so far) I haven’t seen anyone else do”.

I was expecting some novel analysis of in depth data scraped from GitHub APIs, or the results of a qualitative survey of big Java shops, or … something?

Instead what we got was a reposting of a few surface level stats pulled from other blog posts which have tolled the death of Java (or C++ or whatever) ad nauseum.

It’s as if the author started with a narrative and went searching for the line plots to justify it.

To be clear I don’t doubt the growth of Java amongst new learners is slowing down. Partly perhaps due to an image problem relative to other new languages, but likely also due to having somewhat saturated its “total addressable market” and not repositioning itself in new “markets” in the way that, say python has done.

But it’s still a great language for many categories of problem (e.g. high throughput live service) and has rich ecosystem. Build what you like with whatever tool is good for the job. Stop using bad stats to motivate your recent learning choices and just go build stuff :-)

As a data point, this change will mean a lot of work for us (we built cluster discovery on top of Akka Cluster at Neo4j). I'm not thrilled, but I respect their right to make these changes, and personally think that BSL with a timed revert to Apache 2.0 is a meaningful compromise.

Enterprises have to be sustainable. If you're furious with Lightbend for making this change to protect their bottom line, then you can always fork one of the last open source versions and maintain/fix that yourself. But most people won't do that, because if they did they'd likely have been active contributors to the project before now, reducing the ongoing maintenance burden on Lightbend and potentially avoiding them feeling the need to close-source in the first place.

Yes they do

It does though, the primary thesis of the article is that the question (whether or not software engineering is engineering) is important because if software engineering is the real deal, then we're ignoring useful lessons from all the other disciplines.

This is daft. CockroachDB exhibits extremely strong isolation and consistency levels. I believe it is strictly serializable under most circumstances?

Also - anyone who says that x database must be rewritten “because GC” is just making an incredibly un nuanced argument about a nuanced problem. People have built production ready databases in both Java and Go. If you care about low/predictable tail latencies then you have a bunch of other more important problems to solve before you worry about the behaviour of a modern garbage collector. For example: how good is your cache hit ratio? How are your synchronous replication protocols affected by grey failures? That kind of thing.

Another thing which makes the Raft/Paxos vs new-consensus-algorithm comparisons complicated is caching.

If your raft state machines are doing IO via some write through cache (which they often are) then having specific machines do specific jobs can increase the cache quality. I.e. your leader node can have a better cache for your write workload, whilst your follower nodes can have better caches for your read workload.

This may lead to higher throughput (yay) but then also leave you vulnerable to significant slow-downs after leader elections (boo).

What makes sense will depend on your use case, but I personally agree with the author that multiple simple raft/paxos groups scheduled across nodes by some workload aware component might be the best of both worlds.