Comment by AlgebraFox | Hacker News Reader

Comment by AlgebraFox | Hacker News Reader

Parent Full thread

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 ??

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.

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.

> 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?

> 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(),.."

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

Reply on news.ycombinator.com