[OvervCW]

I'm amused by posts like this because it shows that Go is finally slowly moving away from being an unergonomically simplistic language (its original USP?) to adopt features a modern language should have had all along.

My experience developing in it always gave me the impression that the designers of the language looked at C and thought "all this is missing is garbage collection and then we'll have the perfect language".

I feel like a large amount of the feeling of productivity developers get from writing Go code originates from their sheer LOC output due to having to reproduce what other languages can do in just a few lines thanks to proper language & standard library features.

[pjmlp]

Unfortunely given that the authors are also related to C's creation, it shows a common pattern, including why C is an insecure language.

> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.

From https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...

Go grew up from the failed design with Alef in Plan 9, which got a second chance with Limbo on Inferno.

https://en.wikipedia.org/wiki/Alef_(programming_language)

> Rob Pike later explained Alef's demise by pointing to its lack of automatic memory management, despite Pike's and other people's urging Winterbottom to add garbage collection to the language;

https://doc.cat-v.org/inferno/4th_edition/limbo_language/lim...

You will notice some of the similarities between Limbo and Go, with a little sprikle of Oberon-2 method syntax, and SYSTEM replaced by unsafe.

https://ssw.jku.at/Research/Papers/Oberon2.pdf

[DanielHB]

I remember when I first got out of uni and did backend Java development, I thought I was incredibly productive because of the sheer amount of typing and code I had to pump out.

After doing a bit of frontend JS I was quickly dissuaded of that notion, all I was doing was writing really long boilerplate.

This was in the Java 6 days, so before a lot of nice features were added, for example a simple callback required the creation of a class that implements an interface with the method (so 3 unique names and a bunch of boilerplate to type out, you could get away with 2 names if you used an anonymous class).

[liampulles]

As a Go developer, I do think that I end up writing more code initially, not just because of the lack of syntactic sugar and "language magic", but because the community philosophy is to prefer a little bit of copying over premature abstraction.

I think the end result is code which is quite easy to understand and maintain, because it is quite plain stuff with a clear control flow at the end of the day. Go code is the most pleasant code to debug of all the languages I've worked with, and there is not a close second.

Given that I spend much more time in the maintenance phase, it's a trade-off I'm quite happy to make.

(This is of course all my experience; very IMO)

[miohtama]

How much is premature in time? 10 years? 20, 30 years?

[petralithic]

More like, let's throw away the last 75 years of programming language theory advances, only to rediscover them again ourselves, with much hardship.

[DarkNova6]

Sounds Like „Tell me about Generics in Go without telling me about Generics in Go“

[eptcyka]

How is the boxed interface problem enabling better ergonomics for Go? I find that most quirks listed here are not making the language any better.

[OvervCW]

In this specific blog post I suppose only "Ranging Directly over Integers" counts, but I was more generally referring to the introduction of features like generics.

[deivid]

C at least has const ptr. In go I've seen pointers mutated 7 levels down the callstack. And of course, the rest of the sphagetti depended on those side effects.

C is so limited that you would try to avoid mutation and even complex datastructures.

Go is "powerful" enough to let you shoot yourself much harder.

Go with `const` and NonNull<ptr> (call it a reference if you need) would be a much nicer language

[0x696C6961]

If you think Go and C are that similar then you don't know either.

[OvervCW]

They are similar in the sense that there are very few abstractions, relying on the programmer to reimplement common patterns and avoid logical mistakes.

You have to put thought into such things as:

- Did I add explicit checks for all the errors my function calls might return?

- Are all of my resources (e.g. file handles) cleaned up properly in all scenarios? Or did I forget a "defer file.Close()"? (A language like C++ solved this problem with RAII in the 1980s)

- Does my Go channel spaghetti properly implement a worker pool system with the right semaphores and error handling?

[quietbritishjim]

Go and C have partially shared origins. Two of the three creators of Go (Ken Thompson and Rob Pike) were involved in the early days of C. Ken Thompson is even the creator of B, the predecessor of C. There are obvious huge differences between the language but in a more subtle way they're actually quite similar: C is an "unergonomically simplistic language", just as the parent commenter describes Go.