[dgellow]

> There is probably some truth to the idea that many newcomers will go for the latest features. However, on the flip side, I’ve been wondering if there can’t be a competitive edge in designing a language that is minimalistic, stable and slow to evolve by design.

That's exactly how I see Go, and why I personally use it, even though it has clear limitations and can be frustrating at time. And the language get quite a lot of hate because of these choices and their consequences. Minimalistic often means that you have to implement your own solution for some common problems, and/or write a good amount of boilerplate. Stable means that you don't change things that much over time, even if trends are shifting and new patterns/paradigms are developed, so you're potentially losing people and/or powerful technics (you also avoid the ones that haven't been proven yet and will potentially be seen as harmful in the future).

On the other hand you have the real benefits of having something small that you can easily keep in your mind, a tool that won't impact your maintenance budget, you can learn it once and then can be good for years without feeling the need to catch up all the time with newest changes and ideas. That's quite relaxing IMHO.

[tuatoru]

> > a language that is minimalistic, stable and slow to evolve by design.

The upper case languages. C, AWK, SQL, COBOL, FORTRAN (yes yes I know the latter two like to be written in mixed case these days).

Also Ada ... hmm, perhaps not so minimalistic.

And Scheme.

[de_watcher]

ARNOLD C?

[christophilus]

Agreed. Also, Clojure. It’s one of the most stable languages I know of that is actively developed. It’s refreshing to install a 5 year old library and have it just work. In many cases such libraries aren’t abandoned; they’re just done. That’s a rarity in other languages I use.

[mark_l_watson]

Right on, and this also applies to Common Lisp. I often use very old CL libraries, not modified in a long time because they are “done.”

[Jeff_Brown]

> something small that you can easily keep in your mind

The tradeoff is that a small language can lead your program to be big, hard to read, hard to keep in your head. Abstractions like polymorphism, monads, recursion schemes or lenses add (what initially seems like a lot, but later feels like) a little to the language, in return for (if used appropriately) immensely cutting down on the amount of code you end up writing.

[dgellow]

Sure, but that’s not really that aspect I was talking about

[pwdisswordfish0]

Go isn't as rosy as is often claimed, unfortunately. I have a lot of familiarity with the Wirth school that shaped it, and the design and conservative philosophy of the language really appeal to me. But of course what it's really about is the economy (ecosystem), silly.

Take my recent experience with Gogs and Gitea as an example—both not just incidentally coming out of the Go world, but also consciously branding themselves as "a painless self-hosted Git service". The latter abandons this and the gestalt of Go right out of the gate. Builds are not in any sense fast, it depends heavily on the NPM ecosystem, and there are other issues. The former is the original and supposed to eschew with all the "move fast and break things" attitude of the latter, right? Try building and it fails. At the time 1.14 was the latest version of Go. The fix was upgrading to 1.14, which had only been released a few months earlier. So then you build this binary on your local machine and then move it to the the VPS and find out that you can't set it up because sqlite support hasn't been built in because that requires building with cgo, which proves to be a real pain in the neck trying to build on a different system, so you're better off doing that on the system it's going to run on. So much for Go's thoughtful compiler architecture. So you re-clone the repo, only this time on the remote system. And of course that won't build, because (remember?) it needs the latest version of go. And now you're running as non-root user on a system with a system-level go binary, so that's going to involve twiddling the symlinks and/or your path so `go` invokes the right version.

I say all this with an awareness of the tremendous unrest against the trajectory of Go's "simplicity" from within its own fanbase, and the Go team's recent capitulations in the last year or so. As the blog post lays out, this is not unique; it's the way mainstream software development goes in general. The reason is what I said before: it's the "economy"—the interactions of a bunch of stakeholders.

What seems to be the problem with every system, no matter what tech stack they're built on or the principles they set out to embody at the beginning, is that it tends towards consultant-driven, devops-scale complexity. Intentional or not, there's an invisible force that moves things in the direction of maximizing "payoff", where that most often involves literal money changing into hands of the person putting up with all this stuff. Pretty much everyone in the workforce benefits when their line of work accumulates more esoterica, thus proving the value of consultants and others who derive their paycheck from being wizards taming incomprehensible systems. Even well-meaning, non-nefarious actors are susceptible to it. What also happens is that most developers get so far up their own ass with respect to their chosen tech stack that they're not able to see the problems their "progress" is causing, and they've got a whole community usually egging them on. This isn't too far off from what we've seen with the Twitter-driven polarization in politics, as everyone is able to find a set of likeminded people telling them that they're doing and thinking the right things.

[dgellow]

I think that you have a good point with the example of gitea, the language and other tools can be as minimalistic and clean as you can wish for, and you can have the best intent to have a stable ecosystem, you are still likely to have the same kind of issues.