3 ms·
> Finally, null pointer dereference does not cause undefined behaviour, as in C, C++. Go will panic (and you can safely recover). I'm not convinced that removin
by azth 14y ago
> Finally, null pointer dereference does not cause undefined behaviour, as in C, C++. Go will panic (and you can safely recover). I'm not convinced that removing null pointers will eliminate the cause of these bugs. I think the idea of "failing fast" would help diagnose bugs much faster - although I see reasons for disagreeing.
Dereferencing nulls in Java is not undefined either, so what? And the notion of 'failing fast' is exactly why null pointers should be modeled in the type system. What faster way to catch bugs than at compile time? Furthermore, how do you know you will quickly hit a NPE in you code at runtime, if it happens to be in a code path that is infrequently accessed? Ironically in the OSCON talk mentioned in another comment here, Pike mentions that dynamic typing is pushing some compile time errors into runtime, which is exactly what is happening here.
- kkowalczyk 14y agoThe crucial difference is that static typing is a well understood problem. The subset of "modern languages without null pointers" and "languages used to write a lot of serious software" is zero. And notice "a lot" in this sentence. Majority of serious software is still written in languages like C++ or Java, which are either much less safe than Go or at about the same level of un-safeness. While I'm sure someone wrote serious software in Haskell, very few (comparatively speaking) did. We can theorize why "modern languages without null pointers" failed to take off at the scale of Java or Python, but that they failed is a fact and that makes all their properties, including lack of null pointers, of questionable utility in the craft of actually writing useful software. Go is a pragmatic, minimalistic languages, built on proven and well understood ideas.
- swift 14y ago> that they failed is a fact and that makes all their properties, including lack of null pointers, of questionable utility in the craft of actually writing useful software. This seems like something akin to the just world fallacy. So far, no language with feature X has achieved mainstream success; therefore, feature X is of questionable utility. I don't think this makes much sense. Programming languages are combinations of a large number of features and design decisions, any of which (or none of which!) could be responsible for their unpopularity. Some features have value that is immediately obvious once you've experienced them, irrespective of the viability of the overall language they may be embedded in.
- pcwalton 14y agoEvery language that becomes popular, including Go, brings something new to the table that wasn't present in mainstream languages previously. In fact, it is precisely the languages that don't bring anything new that don't tend to become popular. There are many, many features that Go has that haven't appeared in mainstream languages before, and this is a good thing. Besides, Scala code tends to avoid null (it's only in there for compatibility with the JVM), and it has quite a few users.