Hacker News Reader

Comment by Jabbles | Hacker News Reader

I don't really view "make" as inconsistent - the fact that builtin functions have special powers doesn't strike me as particularly unusual. If they didn't I presume they'd just be part of the standard library.

Besides, it seems that the inconsistency (if any) is the fact that the rest of the language doesn't have generics - something that I hope will be resolved in the future, but without which I am coping surprisingly well.

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. I do not think Go is intended or recommended for safety-critical applications, where special languages such as Ada are used.

View on HN

> the fact that builtin functions have special powers doesn't strike me as particularly unusual. If they didn't I presume they'd just be part of the standard library.

It strikes me that the primary expectation of a built-in function is not having to import anything, and not having to namespace-qualify it on use. It circumventing the type system IS a surprise. In Go, I believe not only generic-ness appears, but also overloading.

Go as a complete package is very cool, though! I think the reason its warts get brought up disproportionately often is a reaction to its evangelists going a bit overboard in claims of simplicity/orthogonality.

> 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.

The 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.

> 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.

Every 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.

>I don't really view "make" as inconsistent - the fact that builtin functions have special powers doesn't strike me as particularly unusual. If they didn't I presume they'd just be part of the standard library.

It's not unusual (as it happens elsewhere too), but it IS inconsistent.

A builtin function should just mean: it's always available and not part of the importable library. Not "special behavior".

Reply on news.ycombinator.com