I don't know that this is 100% a problem with the language, which cannot be reasonably coped with.
Is it an option to write your own code so that it does not return nil pointers, and only check when you are interfacing which code which might not give you the same courtesy? In other words - in order to avoid driving yourself crazy with paranoid checks everywhere (whether they are done by the runtime or by you) maybe you can defend the invariants at the 'perimeter'.
For that matter, there are going to be many places in many projects where nil pointers are going to be exceptional enough that it is OK to shut down when they occur. There's not always a need to check and handle at points where will be a rare event and not such a big deal when it does happen.
It isn't necessarily a virtue for a program to keep on running when its contracts can't really be fulfilled any more due to the funkiness of its environment or dependencies, so sometimes the best way to handle an error is to just stop and give debug info rather than checking and handling.
I completely agree that it is a huge missed opportunity not to be able to call into Go from C code and I can understand complaints that mandatory gc might prevent Go from replacing C in some domains.
"For that matter, there are going to be many places in many projects where nil pointers are going to be exceptional enough that it is OK to shut down when they occur. There's not always a need to check and handle at points where will be a rare event and not such a big deal when it does happen."
It seems strange to me to create a modern statically typed language that by design doesn't prevent the most common type error (null passed to a function that doesn't handle null), especially when it's so easy to add null safety to the type system.
In C/C++/Java, I need to document in relatively verbose English if a public function/method I write won't handle null. References/pointers that by default aren't nullable are safer, but they also optimize (less documentation and perhaps less machine code) for the common case of functions that don't want to have to deal with null.
I agree that in many many circumstances, nulls are exceptional cases, and I think this is a good thing. At least in the C++ code I write, nulls are rare, so I handle nulls (perhaps by throwing) a small number of places at the borders and then create references from the pointers for internal use. (It's great that null references are undefined behavior in C++.) That way, I get nice stack traces near where unexpected nulls are introduced and I don't have to feel guilty/lazy about not properly handling nulls in my code.
You seem to think non-nullable references force the programmer to use extra checks all over the place. The opposite is true, at least when writing code that someone else might possibly call.
> You seem to think non-nullable references force the programmer to use extra checks all over the place.
No, the other way around. The demand for extra checks all over the place seems to demand non-nullable references. I probably wrote unclearly about this
> I completely agree that it is a huge missed opportunity not to be able to call into Go from C code and I can understand complaints that mandatory gc might prevent Go from replacing C in some domains.
As rsc has pointed out a few times, this problem is just a matter of someone doing the work to make it happen, not a fundamental limitation of the language itself.
>As rsc has pointed out a few times, this problem is just a matter of someone doing the work to make it happen, not a fundamental limitation of the language itself.
Yes, but as neither he nor any other Go designer went ahead and did it the problem exists.
Why would you want do to it anyway? There isonly a handful programs/libraries that do not exist in C.
The only scenario I can think of is risk-minimizing managers. They allow a project to be done in Go but in case things don't work as expected, they don't want to be trapped in Go and be able to reuse that code from their favorite language.
I assume those genuinly new libraries will take some time. Go is over 3 years old and yet there is hardly anything available for Go that is not available for other languages.
In fact the only things that come to my mind are vitess and Skynet - Terminator-future with Go. Being no expert in these areas, I bet there are C equalivalents that perform equally well. Also the vitess equivalent's implementation might be more complex in case it exists.
Because a library written in Go will only be useful in Go (a major shortcoming of Go) and Go can use C libraries, I suspect Go will not be used for library creation for the foreseeable future.
>Because a library written in Go will only be useful in Go (a major shortcoming of Go)
I claim that C, C++ and Java are the only languages whose libraries are heavily used from other languages. For other languages it's often better to interface via some kind of Network socket.
Surely there are Go libraries like there are Ruby libraries. But which C user seriously would want to interface a Ruby library?
Long story short: this is why Go code does not need to be called from C. :-) Different story in 5 years, in case Go is then sufficiently widespread.
Is it an option to write your own code so that it does not return nil pointers, and only check when you are interfacing which code which might not give you the same courtesy? In other words - in order to avoid driving yourself crazy with paranoid checks everywhere (whether they are done by the runtime or by you) maybe you can defend the invariants at the 'perimeter'.
For that matter, there are going to be many places in many projects where nil pointers are going to be exceptional enough that it is OK to shut down when they occur. There's not always a need to check and handle at points where will be a rare event and not such a big deal when it does happen.
It isn't necessarily a virtue for a program to keep on running when its contracts can't really be fulfilled any more due to the funkiness of its environment or dependencies, so sometimes the best way to handle an error is to just stop and give debug info rather than checking and handling.
I completely agree that it is a huge missed opportunity not to be able to call into Go from C code and I can understand complaints that mandatory gc might prevent Go from replacing C in some domains.