Literally all of them. Availability might have been a good point, but their other blog post somehow reaches 100% so I don't believe that either. Also not every business needs 99.9999 availability and can give up for good reasons (like cost and complexity).
The author is an engineer at AWS so he has an obvious bridge to sell.
That said, I do agree with the general point of needing more than one computer. But most people probably just need two, one for backup, far from “distributed system” in the traditional sense.
TL;DR the ISO standards committees behind SQL are working on bring graph query languages and SQL databases closer together.
Obviously there is work to be done at the storage/query planning layer after that, but I’m hopeful once the surface exists more widely that will drive more work in those areas.
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 :-)
Each language shines for specific applications and the provided public data adds little value without clusterization per each application type.
Plus, GitHub is not representative of the real world. As an example, how much Cobol is versioned there compared to the number of LOC in production today?
Also, less new questions on SO may just be a symptom of a mature language instead of a decline.
This is an interesting topic that rarely gets addressed objectively.
GitHub and SO may be relevant directionally for languages that have some material presence on those sites. It's not unreasonable to think there may be a decline though, for a language still at #3 or so, the headline somewhat oversells.
But, yes, there are definitely limitations to GitHub and SO data. You'd probably have to do some primary survey research of the audience in question--e.g. large enterprises--to get better numbers for that audience. And, even then, my experience with trying to get some sort of handle on the amount of C code out there years ago was that few people really have a great grasp on lines of code (? an imperfect measure in its own right) of various languages in use in their organizations.
Possibly. I'd have to study the data sources to have an opinion. I could definitely see it being a source for languages that you wouldn't necessarily expect your average Python or Javascript developer to know or casually pick up--and therefore would be certain to be explicitly called out in a job ad.
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.
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.
I believe it only guarantees serializable isolation. You may get strict serializable, but it doesn’t appear to be the case that you will know for sure if any transactions were not linearizable.
