Hacker News Reader

Comment by tail_exchange | Hacker News Reader

I was very skeptical of Go, but after trying it, it quickly became my main and favorite language. I think the drawbacks of the language are easily offset by how powerful and simple it is.

Its biggest flaw imo, which I don't think was mentioned in the article, is that Go did not learn from The Billion Dollar Mistake in Java: null references. You have zero protection against nil pointers, and this is likely not something that can be changed now without breaking backwards compatibility.

View on HN

Lack of sum types and thus impossibility of just having Result<T,E>-like type for returning errors is bigger one for me, I didn't get bitten by nulls all that much in Go

Although I guess that feeds into eachother, sum types would eliminate any need for null types in the first place.

I would have taken sum types over generics, personally. It kinda sucks because you can't create something like Rust's `?` operator without them or making serious kludgy compromises.

Yes, sum types would solve the problem - you are both identifying the same issue imo

The article has a link to the Wikipedia page on null titled "the billion dollar mistake."

Nil is a carefully chosen name in Go, and was a trade-off which was made. It’s not quite right to compare it to null in other languages.

I agree it is not as safe as a language like Rust, however it was the right trade-off to make in my opinion.

The main protection you have against nil pointers are nil receivers, and knowing when to use reference semantics vs value semantics.

What's the tradeoff? what advantage having null pointers give?

default values for everything without significantly increasing language complexity

As far as I'm concerned, that's a drawback. Ubiquitous default values are an attractive nuisance. One which C# had already demonstrated 10 years prior.

The removal of nil leading to the removal of ubiquitous default values would have been positive.

I think that's why people in this thread are calling it a tradeoff. It's a very attractive option that seems like a great idea until it breaks. In happy path having default values is better, in mixed path situations, having a separate and reserved way of saying something hasn't been touched is incredibly powerful

I think default values are a major flaw, much worse than nil. An unintended default value causes data corruption. All types should be nillable in my opinion, using types that have fallback to a default value is source of nasty silent bugs. In Java for example I would never use a primitive data type.

Reply on news.ycombinator.com