[User23]

This is pretty much exactly how I feel. I have great respect for the Go team. I broadly agree with their design philosophy. I think CSP is a great theory for concurrency. And I just don’t really like writing Go. I don’t hate it, but I feel like I have to either fight the language or just repeat myself an awful lot.

Honestly, I suspect the deficiency is on my end. Perhaps I’ve just spent too much time with Lisp and have experienced some professional deformation.

[KerrAvon]

It's OK to have ergonomic opinions about languages! In scriptingland, I find Python abhorrent. Ruby fits my brain like a glove (the core language, not Rails). Doesn't indicate anything about the quality of the languages or their respective partisans.

[dopidopHN]

Look at you guys using nice looking languages! Haha, Java got better, but oh god it’s still verbose.

We got rid of the getter setter silliness to be in “constructor land.” ( immutable records from Java 17 )

Function are still not first class citizens, but … they have a working visa now. You can shove lambda anywhere.

It’s still awkward to write functional code

Meh. Recently I’ve been really productive with it and I like the sheer boredom and lack of surprises.

[kaba0]

Java is several times more expressive and less verbose than Go, objectively.

[RhodesianHunter]

Most developers on the JVM with any freedom have switched to Kotlin.

[pjmlp]

Better check those numbers, only those forced by Mountain View minions have done so.

[RhodesianHunter]

I'm talking about on the server, not Android... but sure. Bury your head in the sand.

[dopidopHN]

I was free I would not develop corporate software. But oh well

[fs111]

citation needed

[RhodesianHunter]

Any and all language trend survey results from the past couple of years.

[mort96]

I sorely wish CSP was enforced in any way by Go, but it's not. The only thing which arguably makes Go more "CSP-y" than, say, C++ is that it comes with a decent built-in concurrent queue and some syntax sugar. Goroutines have full mutable access to all the variables in their scope, and lots of Go code ends up being your good old mutex hell -- just more of it, since threads are so easy to create.

I think something way more radical than "C++ threads but with a built-in concurrent queue" is needed. If the default was to share nothing, and any shared memory had to be explicitly shared somehow, that would be a great step in the right direction. Maybe the compiler could even check that explicitly-shared variables are protected by a mutex; something like how Rust mutexes "own" the things they're protecting and you can't access the underlying object without having the lock.

[kubanczyk]

Yes, that part might benefit from more constraints. There was a HN thread which approached it from a different angle: remove `go x()` and instead enforce mandatory use of WaitGroup/ErrGroup (i.e. a block that spawns them is the same block reaps them, always). I might extrapolate a bit here. https://news.ycombinator.com/item?id=26509986

[danielheath]

I don't like _writing_ go, but I also don't hate reading & _debugging_ it.

I love writing lisp, but I hate reading & debugging lisp.

[Karrot_Kream]

Lisp as practiced nowadays is mostly found in small teams with low turnover. As such, features of the language that necessarily have to scale with larger team sizes and turnover rates are probably just not that important to its current user base.

There's a Go code base that a friend and I first wrote 5 years ago and we incrementally update it as we find small bugs because of a system it interacts with that changes. We usually touch it once every quarter. I've had no trouble re-reading the code base and keeping it up-to-date. I can't say the same for a lot of other code bases I've worked in.

[rob74]

Yup, that's the tradeoff that most people somehow don't get: Go is maybe a bit more awkward and verbose to write than other languages, but it's much easier to read and refactor. My work with Go is (unfortunately) mostly private side projects which I sometimes have to leave for months, so I already learned to appreciate this years ago. Plus I also programmed in Delphi for years, so maybe some of the Pascal-inspired features of Go that programmers accustomed only to C-family languages find alien seem familiar to me.