[loudlambda]

This is the story I keep being told, but it doesn't seem to match with the reality of a language. Two example off the top of my head:

Loop variables are captured by "reference", not by value, so it's very easy to create bugs where you capture accidentally capture the wrong thing and don't have the value you'd expect.

Nulls, the billion dollar mistake. Most languages are quickly moving away from nulls (and pointers for that matter), or creating constructs that make them much safer (such as what typescript is doing). Instead go doubles down on both of these. In the last decade of programming in kernel level c, python, ruby, c++, java, typescript, scala I've never worked with code that crashes so much and is as buggy as go.

Both of these problems could have been addressed fairly easily without bloating the language. Google has people on the c++ committee; it very much feels like the creators of go had too much hubris to walk down the hall or across the campus and kindly ask a good language designer to shoot holes in their design.

Another example is "iota". How does that make code sharing easy at scale? Any time I see iota, I have to start manually counting lines, and remember the rules for if blank lines or comments bump the counter, and it completely circumvents the ability to quickly grep for a value seen in a log message. It is completely antithetical to teams of people and spans of time and whatnot. It seems more like a team of three people who randomly had ideas and ran with them without thinking the consequences through very well, or consulting the wisdom of others.

[sacado2]

> Nulls, the billion dollar mistake.

That "billion dollar mistakes" is an excellent marketing expression (nobody wants to make billion-dollar mistakes! We should avoid that null they talk about! It looks so expensive!) but I don't know how actually true it is. Do we have any kind of scientific paper that proves languages without null lead to way less expensive software than languages with null?

I'm not talking about memory unsafe languages like C or C++, but situations where, in a memory-safe language, a null pointer exception in production happened to cost a shitload of money.

I'm pretty sure I never had a nil dereferencing in production with my go code. Invalid array access, off-by-one-errors, yeah, sure, way too many, but very few languages can prevent them at compile time. But nil dereferencing? I can't remember that.

[SureshG]

Kotlin is one example where it's difficult to make that mistake. Kotlin does provide nullable type and everything can check at compile time and it so good. So if write code in pure kotlin (java interop has null issues) you can avoid null pointer errors. It's really good.

[sacado2]

I totally agree it's great and tend to enjoy languages that don't provide the user with unchecked nulls. It's a cool tool, but I don't think it's worth a billion dollars. If I had to choose, I'd rather take non-mutability by default rather than compile-time enforced checking of null pointers.

[sytelus]

I'd read some post where Go designers boasted about how they simplified compiler code by cutting down a language feature. It seemed to me they were obsessed about keeping compiler simple which resulted in half-assed language that was then re-casted as achievement in minimalism. I've felt that Go is optimized for compiler designers as opposed to actual developers.

[diamondo25]

As a Go programmer myself, the syntax of Go is simple yet effective. You are in control of what should be done, and Go will make sure all edgecases are covered in _defined_ behaviour like a managed language would. In C, reading out of bounds is legal (except when the address is not accesdible). In Go, you will get a panic (that you can still catch, but its pointing out an invalid program state).

[haxus_the_great]

But how noteworthy is that? I'm sure programmers coming from C will appreciate it, but well-definedness is kind of… the bare minimum you'd expect from a modern language, especially a fairly high-level one like Go.