Comment by ainar-g
4 years ago
That seems like a pragmatic and honest way of looking at software engineering, consistent with Russ Cox's later thoughts on the difference between programming and software engineering[1]. It sounds to me less like “this is a language for beginners and underperformers” and more like “this is a language using which large teams of programmers with varying levels of experience can be productive together”.
> This attitude I think is the reason most experienced deveploers I've worked with are put off by the language.
This is not my experience. Of the six team leads with whom I've discussed the language (after they've had some experience with it) only one was put off by it. The rest were either glad that “something simpler is finally here” or were of the opinion that Go is “just another language”.
(Interestingly enough, the one person who was not impressed was a big fan of purely functional programming, while all others were C++/Java/Ruby kind of people. Which is consistent with my own personal observation that fans of purely functional languages tend to dislike Go, for the most part.)
> Which is consistent with my own personal observation that fans of purely functional languages tend to dislike Go, for the most part.)
It's not only your personal observation (though I would remove the "purely" from "purely functional languages). A good indication of that: on the Go 2020 survey, the 6 most popular responses to "Which critical language features do you need that are no available in Go?" are features that functional programming languages have. All of these features are in ML and its descendants (SML, OCaml, Haskell, Scala, etc).
The graph: https://go.dev/blog/survey2020/missing_features.svg
The article: https://go.dev/blog/survey2020-results
Of the top 6 features in this chart, I see only two that are associated with functional languages: the vague "functional language features" catch-all, and ADTs. The rest is commonly found in mainstream imperative languages today.
My point is that functional languages have all these features, even if some are found in non-functional languages these days. Even functional langauges themselves are often not only functional. You can do OO in Scala, imperative and OO in OCaml. OCaml is actually a good example to talk about, as the recent developments are all about adding multicore, better concurrency and better tooling, something that Go was very good at from the start.
In a way, you can see that the people using these languages that may appear very different are converging to the same "ideal". And that's not a surprise, both languages have a very Unix-y origin, and origin in Pascal/Modula. Go added to that CSP, OCaml added ML. These days OCaml is adding things to better handle the CSP part, and some people are asking for Go to better handle the ML part.
As a fan of pure functional programming who very much dislikes Go, I can vouch for this statement. But in the spirit of giving credit where due one thing that the pure functional crowd can learn from Go is the value in making really good tooling and really try to genuinely make easy things easy.