3 ms·

No matter how many blog posts try to justify Go, it is a lost ship. Yes it is used by many companies (I still don't understand why), but that does not make it a

No matter how many blog posts try to justify Go, it is a lost ship. Yes it is used by many companies (I still don't understand why), but that does not make it a well designed language. > But secondly designing errors as explicit values has been a trend-(re)setter. Go, Rust and Zig have all chosen to use this approach. Just because Go treats errors as values, you can't compare Go's error handling with Rust's. Rust provides clean abstractions with Algebraic Data Types, ? operator over Result type to reduce polluting code with if-else nonsense in every single function. I bet atleast 30% of Go code in a project is error handling for the sake of handling. Further Go's syntax inconsistency irritates me more. I still don't understand if I should put a comma or semicolon or nothing between members in a struct definition. Also a := 10 ... a := 20 // error. a is defined. a, b := 20, 30 // accepted. why ??

api 2y ago
Go’s unreasonable success is due to Google but also its main feature: low up front cognitive load. A lot of that is from lack of async, or rather that async is hidden behind go routines.
- catlifeonmars 2y ago
  > A lot of that is from lack of async, or rather that async is hidden behind go routines. That’s an interesting take, but one that I’ve seen in multiple places in this thread. I find that introducing goroutines into a program immediately increases the cognitive load as now you need to think about joining, data races, and need to think about error handling differently (golang.org/x/sync/errgroup is an excellent library by the way). Oh and did I mention deadlocks?
fullstackchris 2y ago
So are you saying you would take on the initial cognitive load of Rust vs. Go for _every_ project?
theThree 2y ago
> a, b := 20, 30 // accepted. why ?? I guess it is a dept of error handling. Otherwise you have to write "foo,err1 := Foo();bar,err2 := Bar(),.."
guappa 2y ago
My company has 2 teams that use go for different reasons: * Easy to crossbuild and you distribute a single executable (although of course someone managed to pull some dependency that was dynamically loaded and made our CLI depending on a running Gnome session) * C developers who can't write C code that doesn't segfault every 3 minutes (because they never understood how threads work) can still have their ego but also produce somewhat useful code.

api 2y ago

Go’s unreasonable success is due to Google but also its main feature: low up front cognitive load. A lot of that is from lack of async, or rather that async is hidden behind go routines.

catlifeonmars 2y ago
> A lot of that is from lack of async, or rather that async is hidden behind go routines. That’s an interesting take, but one that I’ve seen in multiple places in this thread. I find that introducing goroutines into a program immediately increases the cognitive load as now you need to think about joining, data races, and need to think about error handling differently (golang.org/x/sync/errgroup is an excellent library by the way). Oh and did I mention deadlocks?

fullstackchris 2y ago

So are you saying you would take on the initial cognitive load of Rust vs. Go for _every_ project?

theThree 2y ago

> a, b := 20, 30 // accepted. why ?? I guess it is a dept of error handling. Otherwise you have to write "foo,err1 := Foo();bar,err2 := Bar(),.."

guappa 2y ago

My company has 2 teams that use go for different reasons: * Easy to crossbuild and you distribute a single executable (although of course someone managed to pull some dependency that was dynamically loaded and made our CLI depending on a running Gnome session) * C developers who can't write C code that doesn't segfault every 3 minutes (because they never understood how threads work) can still have their ego but also produce somewhat useful code.