The author notes the success of Go. Go's developers knew when to stop. Go is a mediocre language, but it has all the parts needed for server-side software. That's a big market.
I suspect that part of the success of Go is simply because its libraries are heavily used. You know that the library is serving a zillion requests a second in Google data centers. Major bugs have probably been found by now. Go has one solidly debugged library for each major function. Some other languages have a dozen half-debugged partly finished libraries. I once discovered that the all-Python connector for MySQL failed when you loaded more than a megabyte or so with LOAD DATA LOCAL. It passed the unit test, but clearly nobody was using it in production.
There's an intermediate stop between imperative programming and functional programming - single assignment. Variables are initialized once and are then immutable. This is becoming the default in newer languages such as Rust and Go - if you want mutability, you have to ask for it. This gives you the immutability advantages of functional programming without the run-on sentence syntax. Also, results have names, which improves readability, and give you something to display when debugging.
Haskell actually doesn't care by conscious choice: It's meant as a research language, and has "avoided success at all costs" (to use the tongue-in-cheek quote) to retain the freedom to play around with things. Which in turn lead to quite a few inventions that are now being copied by other modern languages (like Rust), though they rename them to make them less scary (apparently programmers are easily scared by names ... like the one that starts with M.).
That's a bit sad. On the other hand: Imitation is the sincerest form of flattery.
I don't know that it's sad at all. If you want to make a language to be a research language, there's nothing wrong with doing so. If that's what you want, being influential, having other languages steal your ideas is what success looks like.
If you want your language to be used by working software engineers, that's a different metric of success. But then, you'd do things differently if that was your goal.
Haskell, in achieving some real-world use, has achieved beyond the wildest dreams of a research language.
Spoilers: it was (at least in regard to software development)
At least post-1975 software development had the Mythical Man-Month to reflect on.
Furthermore, advances in memory safe languages and type safe languages can both be considered good things. Unfortunately, Go is "almost there but not quite" in these two departments.
>I'm going to go out on a limb and guess that you've never had to work in that space. It's really easy to insult Go's solutions
It's really easy to insult my opinion as well. I do have worked in really large codebases.
The only thing where Go helps "really large codebases" is quick compile times. But it is really easy to create a fast compiler when the language is anemic in features, this is no feat at all.
If Go wanted to be useful for "really large codebases" it would have supported good exception handling (take a look at Common Lisp for exemplary exception handling), for a start. And don't get me started on the horrible kludge of using interface{}.
And for "really large codebases" you want to keep mindless boilerplate code repetition -which is the noise that puts haze over the signal- close to zero. Go has many design choices that do exactly the opposite -- increase boilerplate to the max.
Fair enough, and somewhat deserved. (But only somewhat - your tone kind of led me into temptation. Still, I apologize.)
> The only thing where Go helps "really large codebases" is quick compile times.
Which was, in fact, explicitly their intent. In comments on this same article, people have been complaining about how long it takes to compile GHC. How long would it take for Haskell to compile a 10 million line program? For a program that has, say, 50 people working on it, and that lives for 20 years, that adds up to real money.
Now, you could argue that, if go didn't increase boilerplate so much, you wouldn't have so many lines to compile. That's a fair criticism. Still, just focusing on compile times, would you rather compile 10 million lines at Go's speed, or one million lines at Haskell's?
> But it is really easy to create a fast compiler when the language is anemic in features, this is no feat at all.
The "feat" is choosing to focus on compile time rather than on features.
I disagree with you on exceptions. Go's error handling approach means that you only have to worry about your function and the functions you directly call. Java's approach (or worse, C++'s, since the exceptions are unchecked) means that you have to worry about what every function in the call graph can throw. As the size of the program increases, knowing everything that can be thrown by everything you call becomes unreasonable. (I don't know enough about Lisp's approach to know whether it suffers from this problem or not.)
>This gives you the immutability advantages of functional programming without the run-on sentence syntax...
What exactly do you mean by this? Have you looked into something like let expression in Haskell? You can define as many symbols as you would like with it that you can use in the evaluation of the final expression...
My experience with Haskell has been that if I've written a "run on sentence", it can factored into separate functions, usually resulting in better readability.
I suspect that part of the success of Go is simply because its libraries are heavily used. You know that the library is serving a zillion requests a second in Google data centers. Major bugs have probably been found by now. Go has one solidly debugged library for each major function. Some other languages have a dozen half-debugged partly finished libraries. I once discovered that the all-Python connector for MySQL failed when you loaded more than a megabyte or so with LOAD DATA LOCAL. It passed the unit test, but clearly nobody was using it in production.
There's an intermediate stop between imperative programming and functional programming - single assignment. Variables are initialized once and are then immutable. This is becoming the default in newer languages such as Rust and Go - if you want mutability, you have to ask for it. This gives you the immutability advantages of functional programming without the run-on sentence syntax. Also, results have names, which improves readability, and give you something to display when debugging.