> So ignoring the main point of Rust, it's (mostly) what C++ would have been...

"And the sanitation"

"Oh, yeah, the sanitation, Reg. Remember what the city used to be like?"

Yeah. All right. I’ll grant you the aqueduct and the sanitation are two things that the Romans have done.

I am so glad someone got where I was going with that!

I think Go has done a lot in the last 10 years to facilitate a mindset shift in our industry to "less is more". For a long time, Go was (and probably still is) ridiculed for eschewing many of the features that programming language practitioners have dreamt up over the last several decades, but as more people have tried the language in earnest they have to grapple with the fact that there are some advantages to not having to grok an enormous feature matrix even if they disagree with Go's specific feature set. The conversation has advanced beyond the "if you don't like a feature just don't use it" justification for kitchen sink languages.

Is go really used a lot?

I know some larger corporations use it but I don't hear much about it otherwise. The most obvious plus side I hear about is the small memory footprint and fast boot time which makes it good for functions-as-a-service.

It is also getting generics know which makes it sound like the simplicity was a lie or will be a lie.

Except the critiques for not including generics were valid and the designers finally had to admit they should be in the language. "Less is more" really just meant "omit anything newer than we are used to."

You're implying a contradiction (and a weirdly adversarial one) where none exist. "Less is more" never implied "we will never change anything" or "we got it exactly right with v1". Yes, Go launched without generics so the developers could figure out whether they were really necessary and how best to add them.

I'm sure many will say "well I could have told them they were necessary from the start", but the overwhelming majority of these people are just lucky--they picked a conclusion that happened to pan out. And we know this with certainty because most of these people make arguments for generics where they are neither necessary nor useful--they're merely familiar with languages with generics and they reach for them on first sight of a problem. These people also can't articulate the advantages of not having generics--namely the unreasonable productivity that accompanies everyone writing the same code absent personal flourishes. The very fact that these people consider it a no-brainer that generics were the way to go from the start betrays their error--generics are only just worth their costs, and the emphatically pro-generics camp can only rarely articulate those costs due to their inexperience with other kinds of programming.

My stance is adversarial because Go has wasted an enormous amount of people's time. Not having generics was pitched as a feature, and they spent a lot of effort bragging about how fast compiles were without mentioning that this was because their optimizer was pitiful rather than some great property of the language design. They ignored just about every major development in programming language research in decades and rereleased something they'd already built before, just laundered under Google brand this time to ensure popularity.

The value of generics is obvious if you ever write your own container. Go had pre-Java-1.4 level type safety for any container not specially blessed by the creators. Prior art on how to do them without significant compile time cost was already established by Java, not even some obscure academic language. Go was dumb from the start.

> Go was dumb from the start.

You betrayed your own credibility. As previously mentioned, those who can't articulate the tradeoffs associated with the generics question lack qualifications--they are amateurs, and their opinions aren't interesting to professionals. Consequently, for lack of interest, I'll leave you to your opinions.

I don’t know if it’s Go that’s been that influence more or if it’s the generally increasing profile of functional programming languages (especially JavaScript!) which have always taken a more minimal approach to features.

> Also, a language is more than the sum of its parts. If it weren't, kitchen sink languages would be the best ones out there, because they have the most parts.

I've been hugely interested in this recently, at least part of what you are describing is programming language affordances.