That seems like a huge disadvantage for nuclear power if you need to guarantee strict ideological commitment to ignore cost-competitiveness not just now but into the future. Renewables and batteries are not only cheaper now but have far less scope for major failures based on some MBA cutting corners in a decade.
The fallacy of "simple" languages is not understanding the history of programming languages, why and how they grow with the community, assuming they get any adoption at all.
No one among the folks that created Scheme or C, would assert R7RS or C23 are that simple.
Go only took off thanks to Docker pivot from Python into Go, and Kubernetes from Java into Go, after the respective teams got some Go folks into the project.
The usual RIX approach, followed the whole devops hype cycle that created all those CNCF projects half of which no one in devops space actually knows they exist.
People always forget this other post when arguing for the home team.
"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
It doesn't seem particularly damning to me, though, especially written by Russ Cox in hindsight. It's almost a truism that if you had spent less time on approaches that didn't pan out and more time on approaches that did eventually pan out, you likely would have arrived at a workable solution sooner.
For example, if the core Go team had spent more time exploring C#-like approaches (as some suggest they should have), it's possible that would have delayed the whole thing.
(btw, consider me a "long time listener, first time caller" -- I pretty much always pause to read your comments while flicking through discussions here, including I appreciate you often bring in historical context, even if I might have a different take, or even if I might have expressed your take differently ;)
Actually welcome to Smalltalk, 1980's, because that is where collections, and iteration with blocks, comes from as inspiration to Java, and all the folks that think LINQ was a .NET invention.
More like no one on the world was able to change their mind, and then they had to ask help to someone that could already have provided help before Go released 1.0 version.
"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been
well-served to spend more time with CLU and C++ concepts earlier."
Quite right. If the Go team somehow magically had the right technical background Go would have had generics earlier, but they didn't and weren't going to magically get it, so we're back to the only preventable way was to not release it at all.
But one would think that of the billions of people in the world that someone outside of the Go team would have had that familiarity to quickly change that, but no proposals came from that direction for over a decade and a lot of begging. I suppose those who had the chops were too busy constantly posting on HN about how Go doesn't have generics to lend their expertise. Priorities.
It's great to reflect back in hindsight about where you failed, but it's always easy to see where you failed after someone else finally shows you the way. The simple fact that the Go team did not have the technical capability to be able to add generics at the time remains. Being able to create a relatively popular programming language (or set of popular programming languages for some of them) certainly does not imply that you are a programming language expert. There may even be an inverse correlation. Those who show to be programming language gods appear most likely to end up creating esoteric languages that end up on the pile of languages that remain unknown and unused.
Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve.
Without the adoption success of Docker and Kubernetes adding wind to Go's sails, Go would have landed on the island.
They were not lacking in skills, rather politics, and there is a public talk from Rob Pike where he mentions even the Go 1.18 generics would not have landed if it was for him.
> Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve.
Exactly. You might say that Wirth, Mössenböck, and Winterbottom had some programming language chops, bringing some new ideas to the world, which is in line with the observation that those with programming language skills end up creating languages nobody uses. In fairness, Pike was involved in Limbo, but his only claim to fame was pressuring Winterbottom to add garbage collection to Alef, thus Limbo.
> Without the adoption success of Docker and Kubernetes adding wind to Go's sails, Go would have landed on the island.
Fun story, but no. Those projects chose Go because Go had already gained traction and was thought, in that moment in time, that it was going to be the way of the future.
It is true that Docker is often credited as the first major success story, but Hugo, etcd, InfluxDB, etc. were all released around the same time, never mind the long list of projects that never gained popularity. The language was already being widely used by the time Docker showed up. Go didn't need a major success story to get on the radar. It had Google's marketing power behind it, or at least that's why most believe it was able to become popular without having any breakouts to its name.
> They were not lacking in skills, rather politics
These are not separable concepts. Politics are the result of lack of skill.
Really wearing the team's t-shirt there, Go was barely proven on the language adoption battlefield when Go heads preverted the direction Docker and Kubernetes were going, it wasn't even 1.0.
Lots of languages are full of dead projects that never gained notoriety.
In fact, YouTube downloader which is another "success" only happened, because once again, it was a gopher that forced a RIG, it was working perfectly fine.
> Go was barely proven on the language adoption battlefield when Go heads preverted the direction Docker and Kubernetes were going, it wasn't even 1.0.
Exactly. All these projects chose Go many years before anyone, outside of Docker, had heard of Docker. This idea that Go was some kind of underground language until Docker and Kubernetes arrived at which point everyone jumped on the bandwagon is simply not true. Go was already quite popular by the time Docker was released, as evidenced by a whole lot of other projects that became popular themselves being released at the same time. Those projects wouldn't have been able to have been released when they did if they waited for Docker's success to jump on the Go bandwagon.
> Lots of languages are full of dead projects that never gained notoriety.
No there aren't. Not where the language is on the heap of languages nobody has ever heard of. Oberon-2 and Limbo didn't fail because they never found their "Docker", they failed because nobody used them in the first place.
reply