3 ms·
The fact that golang was designed with the "billion dollar mistake" as recently as it was is pretty astonishing.
by topspin 2y ago
The fact that golang was designed with the "billion dollar mistake" as recently as it was is pretty astonishing.
- brikym 2y agoYes! And people will defend this awful language!
- topspin 2y agoI don't go that far. Mistakes were made, but golang has great properties as well. I'm just amazed that, given that golang's inception is relatively recent, somehow this old lesson had not been learned by the designers. Accomplished and learned people created this language. How did that happen?
- veber-alex 2y agoGo's design is laser focused on fast compile times at the expense of everything else.
- fire_lake 2y agoWhich is crazy. Even at Google scale the bottleneck to delivery is human reasoning about code changes, not so much build times.
- topspin 2y agoWhile it's true that fast compilation was probably the primary asperation of golang's design, it wasn't the only concern, and there is nothing about eliminating nullability that would have compromised compile time. So I'm left to imagine that they just didn't know.
- agarren 2y agoI agree, but it doesn’t change the fact in my mind that despite golang’s nulls, I’ve found it to be a ridiculously productive language to work with in a lot of cases. I’d credit that to the simplicity of the language (if not the runtime), and, it least from that perspective, it’s something Golang shares with F#. F# has the obvious advantage of a significantly better type system and the disadvantage of not sharing the more familiar Algol/c syntax.
- diarrhea 2y agoYes. The concept of references (which includes that of null pointers) and that of optionality (which includes that of nothingness) are orthogonal. The former is just an artefact of computer architecture, the latter is everyday business logic. Go mixes the two into a single concept, which is painful. As a newcomer to Go, I find myself struggling to express business logic all the time. Zero-valued types make the situation even worse. You’re constantly constructing invalid values of types (nil/zero-valued), by design. Go is “so easy”, but when you inevitably run into one of the footguns it’s “yeah just don’t do that”. One of the primary reasons for people to dislike Python is its dynamic typing. When Go came out, that was totally fair. But since then, Python has evolved and improved massively. It/mypy now supports type-safe structural pattern matching, for example. It’s very expressive, and safely so. Meanwhile Go barely evolved. Generics landed just recently. They’re only now experimenting with iteration, lifting it from a purely magic, compiler intrinsic concept. And still, no enums of course. The “type system” are structs, or very leaky type wrappers (nowhere near the safety of Rust new types, for example). People are obsessed with primitives. I can see the appeal of a simple, stable platform, but Go really ran too far with that idea.
- chx 2y agoWait, can you even run into a null pointer reference error in Go?
- topspin 2y agoYou can do this much: func main() { var p *int *p = 1 } panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x466462] That's memory safe. It's also common and terrible. As is Java's NullPointerException, C#'s NullReferenceException, Javascript's "is not a non-null object" and all the other, unnecessary and awful, yet memory safe manifestations of the same design mistake plaguing contemporary software. Understand that when Hoare coined the phrase "billion-dollar mistake," he was referring to his addition of null references to ALGOL W. ALGOL W references are not C pointers that allow willy-nilly pointer arithmetic and all the UB that come's with that. An explicit design goal of ALGOL W was to prevent unsafe dereferences. A dereference of a null reference in ALGOL W is defined behavior and yields a runtime error. NULL OR UNDEFINED REFERENCE An attempt has been made to access a record field using a null or never initialized reference. That said, ALGOL W isn't memory safe either: it attempts to mitigate memory violations, but this is not comprehensive.
- neonsunset 2y agoIf you add <WarningsAsErrors>nullable</WarningsAsErrors>, the below will not compile: var bytes = (byte[]?)null; Console.WriteLine(bytes.Length); That and, well, all variables must be assigned before use. You'd be right to point out it's a band-aid, a convenient one but still.
- topspin 2y agoAs you know, that has no benefit for any dependencies you have in play.
- neonsunset 2y agoWhat do you mean?