[pjmlp]

There are several language design problems solved in the 20th century that Go designers decided to ignore, because they require PhD level skills to master, apparently.

Hence why the language is full of gotchas like these.

Had it not been for Docker and Kubernetes success, and most likely it wouldn't have gotten thus far.

[bb88]

And now they're stuck, since they doubled down on not making any language changes for the 2.0 release.

They made the language easier and quicker to write a compiler, but harder to write programs in, and it doesn't look like that will change in Go 2.0.

[pjmlp]

At least many CNCF projects are now adopting Rust, Java, C# and even to a lesser extent C++.

[bb88]

There's nothing better than a panic in production caused by a third party library.

[pjmlp]

This whole thread is about the money Über has spent to work around panics in Go.

[tehjoker]

speaking from personal experience, i selected go for a project because it is high perf, automatically uses all cores w/ goroutines, and is type checked

[triyambakam]

> type checked

Kinda...

[65a]

It is a type safe language, not exactly sure what you're hinting at here.

[madeofpalk]

This entire post is a big workaround go's insufficient type system because nil is not modelled in it. That's not safe.

[65a]

I agree I probably should have said strongly typed instead of safe, as yes, if you dereference a pointer to nil you are going to crash. That being said, I do think "possesses an untyped nil" is a pretty far cry from "not type checked at all". It's certainly much safer than languages like C or C++ which allow type punning, or Java, where both nullables and runtime exceptions associated with types are generally a more pernicious problem.

[pjmlp]

Also possible in Go via unsafe.