3 ms·

That’s right, and this is confirmed by many benchmarks I’ve seen. I agree with pretty much everything in this article except the repeated claim that “Go is fast

That’s right, and this is confirmed by many benchmarks I’ve seen. I agree with pretty much everything in this article except the repeated claim that “Go is fast”. Of course “fast” is relative, but I would reserve it for languages that are nearly as fast as competitors in their segment. There are too many languages very similar to Go’s ergonomics that are much faster for us to meaningfully call Go “fast”. That said, I don’t really think that’s a problem. I think people who use Go are often just happy it’s faster than Python, and that’s okay. My personal dislike of Go comes simply from their unapologetic[1] embrace of default nullable pointers (the “billion dollar mistake”[2]): There is very strong theoretical (and practical) ground supporting the approach of Rust/Zig/Swift/etc’s (to use algebraic data types instead) as objectively better (yielding inherently more reliable results with virtually no ergonomic compromise[3]). In other words, in the 21st century, we know how to design statically typed languages that guarantee the impossibility of null dereference exceptions (not counting bugs in external libraries from other languages). And we can do this without any runtime performance or code ergonomics compromise! Therefore there are no good excuses anymore for any statically typed language in the 21st century to not provide this extremely beneficial guarantee. [1] There are no plans to fix this, ever: I’ve seen entire articles written by members of the Go team not just defending “all pointers are nillable”, but encouraging this as an idiomatic Go style of coding. [2] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill... [3] The ergonomic difficulties of Rust come from the borrow checker, not from their use of algebraic data types to replace nullable pointers.

kristoff_it 7y ago
I replied to the parent comment on my experience, but I do agree that Java and C# can be very fast. I also agree on the problem with null pointers with is really ridiculous. Another complaint that I have about Go is how for some reason Google decided to implement many web protocols in the standard library, but never really cared to get websockets right, to the point that they just sedn you to a third-party library from their own documentation. That + QUIC/HTTP3 make me want to take my tinfoil hat out from the drawer. https://godoc.org/golang.org/x/net/websocket https://godoc.org/golang.org/x/net/websocket
steveklabnik 7y ago
Has there been a statically typed language with no null and no generics? I'm pretty sure that every language I've used that implements an Option-like type has it be generic. Maybe TypeScript, where you can have "number | null"?
- Crinus 7y ago
  QBasic :-P. Though all dynamic allocation happens by resizing predefined arrays.
- kristoff_it 7y ago
  Go is already getting away with a magic generic map type, they could have done it the same way, it they wanted to.
- ummonk 7y ago
  Go has generics (e.g. in its data structures). They just aren’t usable by the programmer. The same could have been done for optionals.
josephg 7y ago
I would add parametric enums to your excellent rant. When I first learned Go I thought it’s use of constants with iota as quite a clean approach for enums. But after spending some time with Scala, Rust and Swift, well, I was wrong. Being able to exhaustively pattern match is simply excellent. And like non-nullable types, this is a zero overhead language feature that is simple, feels great to use, and reduces bugs. It feels like a real step backwards using languages without parametric enums. My litmus test when learning a new language involves porting across some plain text operational transform code. The go code came out about 40% larger than the rust and swift implementations for this reason. It was also much uglier and harder to read. Like, those extra lines were pure overhead. Eg this rust code is beautiful: https://github.com/josephg/textot.rs/blob/bb14b4b483e7dace67dcd233b36074e13c64d704/src/lib.rs#L98 https://github.com/josephg/textot.rs/blob/bb14b4b483e7dace67... And that’s prettier and about as performant as this C implementation of the same function (I think I somehow lost the Go code - but it wasn’t much better than this): https://github.com/ottypes/libot/blob/902470a22d3a99d9b776cea00ec4c001c7737360/text.c#L641 https://github.com/ottypes/libot/blob/902470a22d3a99d9b776ce... The equivalent javascript code (my go-to language!) is larger than the equivalent swift / rust code and, last time I checked, about 8x slower. Most of the gap in readability is this one beautiful feature!

kristoff_it 7y ago

I replied to the parent comment on my experience, but I do agree that Java and C# can be very fast. I also agree on the problem with null pointers with is really ridiculous. Another complaint that I have about Go is how for some reason Google decided to implement many web protocols in the standard library, but never really cared to get websockets right, to the point that they just sedn you to a third-party library from their own documentation. That + QUIC/HTTP3 make me want to take my tinfoil hat out from the drawer. https://godoc.org/golang.org/x/net/websocket https://godoc.org/golang.org/x/net/websocket

steveklabnik 7y ago

Has there been a statically typed language with no null and no generics? I'm pretty sure that every language I've used that implements an Option-like type has it be generic. Maybe TypeScript, where you can have "number | null"?

Crinus 7y ago
QBasic :-P. Though all dynamic allocation happens by resizing predefined arrays.
kristoff_it 7y ago
Go is already getting away with a magic generic map type, they could have done it the same way, it they wanted to.
ummonk 7y ago
Go has generics (e.g. in its data structures). They just aren’t usable by the programmer. The same could have been done for optionals.

josephg 7y ago

I would add parametric enums to your excellent rant. When I first learned Go I thought it’s use of constants with iota as quite a clean approach for enums. But after spending some time with Scala, Rust and Swift, well, I was wrong. Being able to exhaustively pattern match is simply excellent. And like non-nullable types, this is a zero overhead language feature that is simple, feels great to use, and reduces bugs. It feels like a real step backwards using languages without parametric enums. My litmus test when learning a new language involves porting across some plain text operational transform code. The go code came out about 40% larger than the rust and swift implementations for this reason. It was also much uglier and harder to read. Like, those extra lines were pure overhead. Eg this rust code is beautiful: https://github.com/josephg/textot.rs/blob/bb14b4b483e7dace67dcd233b36074e13c64d704/src/lib.rs#L98 https://github.com/josephg/textot.rs/blob/bb14b4b483e7dace67... And that’s prettier and about as performant as this C implementation of the same function (I think I somehow lost the Go code - but it wasn’t much better than this): https://github.com/ottypes/libot/blob/902470a22d3a99d9b776cea00ec4c001c7737360/text.c#L641 https://github.com/ottypes/libot/blob/902470a22d3a99d9b776ce... The equivalent javascript code (my go-to language!) is larger than the equivalent swift / rust code and, last time I checked, about 8x slower. Most of the gap in readability is this one beautiful feature!