It still boggles my mind that Go decided to force programmers to worry about nil pointers.
Which is fine, except that this is probably the second-most boring critique of Go, one virtually everyone has heard before, and it has little if anything to do with the story we're actually commenting on, despite having spawned a huge thread about option types.
If GoKart had been my project, I'd be annoyed.
- I dunk on Java for pervasive nullability too (though there are tools that add @Nullable xor @NonNull annotations used for analysis, possibly sound). But Go has over a decade more hindsight and should've known better.
I haven't used the other languages.
Go distinguishes between the two too. You cannot pass nil as a value to int. In fact in Go you'd get a compiler warning[0] so you don't even need to rely on type hints and a properly set up CI/CD pipeline to catch said faults:
The problem with Go is that pointers can be nullable[1] as well as interfaces[2] (interfaces, crudely speaking, being Go's solution to generics and inheritance. Crudely speaking. So interfaces get used a lot).
There is some logic to them being nullable if you think about the code from a hardware perspective but given how opinionated the compiler and language is, I feel they could have done more to catch accidental nils to save the developer from having to consciously consider them each time.
[0] https://play.golang.org/p/BADNnw08hoo
Basically, it's the difference between returning None from a function `def f() -> MyClass` in Python (which is type error) versus returning nil from `func f() &MyClass`, which is completely normal in Go.
Having `Optional` in the function signature makes it explicit that one has to check for Nones. Go lacks that.
Plus I personally think if you need an optional parameter then 99% of the time the API is likely designed wrong from the outset (eg maybe you should instead be passing a class). The reason being is that optional parameters aren't always predictable (eg why is this value optional? When do I need to include a value for it?)
For what it's worth, I completely disagree with your point. Optional arguments are there to set default values. Default values are so useful that even Rob Pike went through some efforts to use them in Go[0] after refusing to have them in the language.
[0] https://commandcenter.blogspot.com/2014/01/self-referential-...
Type hints then? I don't write much Python so your point might have be clearer had you provided an example. But even in the case of type hints, it requires the developer to be diligent about setting those hints -- Python will happily plod along without them.
That's actually one of the reasons Python isn't my preferred language. I generally prefer something where typing a lot stricter. But this is personal preference and not a judgement on Python.
> For what it's worth, I completely disagree with your point. Optional arguments are there to set default values.
Default values can be set via constructors. Which then allows you to define far more explicit APIs. For example a method that explicitly sets the optional properties when needed might be called `CreateFooWithOnions()` and that method is aware that `.bar` is required to be set for "Onions". Other methods that know the defaults don't need to be set can leave those optional properties with the default. Thus the developer doesn't have to consider if an optional parameter is required in specific use cases, they instead call the method for their use case that is aware of what optionals are required for that use case.
I went through a phase of using optional parameters in the 90s and as I worked with more contributors, and other projects interfaced with my own APIs, I began to realise that optional parameters aren't self documenting. They're not descriptive. Instead it requires the user to understand what's happening under the hood of the API. So I learned from that and moved away from optional parameters.
> Default values are so useful that even Rob Pike went through some efforts to use them in Go[0] after refusing to have them in the language.
That link was from early 2014. Back then methods were only 6 months old (in Go). In fact Rob Pike (and others) tried a lot of things in the early days of Go. Some of those ideas sucked and were never heard from again. And some of the ideas worked and are now part of the core library.
Also the ironic thing here is while the API is called "Option" what Pike is doing is not creating optional parameters but actually creating objects with optional properties. Exactly like I've been describing as the better solution. Albeit Pike's work created a bunch of additional boilerplate and ultimately ends up with something that isn't any more readable. Which is likely why that idiom never made it to Go 1.3 (and beyond).
One of the common arguments now for why C# is superior to Java is that it supports non-nullable references. As does C++, which for large latency-sensitive projects is generally picked over C.
Disclaimer: Using neither.
The thing is, the Java ecosystem is insane. What else comes close to it in breadth and quality? Python, Go, Ruby etc certainly don't. C++?
Even on the places where Java and .NET languages took over C++ hegemony, it is still there on the implementation of native/extern methods and COM/UWP libraries.
Also don't forget if your favourite compiler is a LLVM/GCC frontend, many of its improvements require a bit of C++ code changes as well.
I'm sorry you're bored and also annoyed in the possible universe where GoKart is your project. But it seems like this is a thing people want to talk about in a post about Go static analysis tooling.
I don't see why you're trying to police HN conversations.
One piece of code from a well established tech company would just crashloop if authentication failed. I've seen others just die if the RPC service couldn't make a connection.
So in practice, yes I do have to spend my time tracking down nil pointer runtime bugs both from colleagues and also from other organizations.
Getting a nil where you are supposed to have an Optional.
In "pure" Scala (not in the FP sense, but just without mixing with Java) something like that is almost impossible.
For Scala 3 there are improvements. It's "null safe" as long as you opt-in (modulo Java libs, and of course doing stupid things like casting a null to some other type).
https://docs.scala-lang.org/scala3/reference/other-new-featu...
When you have people without clue on the team no language will safe you. You can also crash Haskell programs by throwing exceptions or just using List.head…
Is there really that much of a difference between those cases?
I agree though that in an interface, Optional conveys a more explicit meaning than something pointer-like, which is always a good thing.
Go programs crash at runtime. In general, program failures and bugs should surface as soon as possible. Ideally no later than compile time. Instead, Go makes you wait until the app is running.
For an app that has a lot of configuration options, for example, there can be a latent bug that crashes the binary for some options. And that bug may not be detected for months because nobody was using that combination of config options.
The only real defense of this is to pepper your code with a bunch of nil checks. But these nil checks are also hard to test, so Go devs just learn to ignore missing code coverage. In fact, your code coverage metrics look better if you don't check for nil.
I'm sure at some point Go or a library will offer a version of optional types that is well-adopted. But my point is that by the time Go was designed, null references were already widely considered a bad idea and the source of a huge class of computer bugs. Go still deliberately designed them into the type system.
Well, of course, if your end users, the business users, are okay if you present them an "optional result" which might or might not be a result, then Optionals/Either _are_ the cure. Unfortunately most end users are pissed if you tell them that you optionally shipped their purchase or that the refund will either be credited to their CC or not.
I agree that it's nice to be explicit about optional stuff, but overall it's not been a huge deal in the projects I've been involved with.
If you don't need to manipulate pointers then nil really just represents a degenerate or optional value. For optional values these can be encoded any number of ways depending on the type system. One common pattern is an optional type. Another is to annotate the type to indicate that it might be null.
The idea is that if a programmer doesn't check that an nullable or optional type is missing then the program should fail at compile time instead of crashing at runtime. Golang chose to crash programs at runtime.
So for whatever reason, Go has decided that null pointer dereferences are not a big deal. But God help you if you try to comment out a variable use without assigning it to "_". Then the program fails to compile.
I think that's a good explanation of why people are so frustrated with this. There are lots of features like go fmt, go vet, the compiler checking that you use all variables and all imports that can feel a bit restrictive. But for something like null pointers, there is nothing. It's incoherent.
* separate pointer types (e.g. C++ pointers v references)
* a built-in sigil / wrapper / suffix e.g. C#'s Nullable / `?` types
* a bog-standard userland sum type e.g. Maybe/Option/Optional
In modern more procedural languages the third option often will have language-level (non-userland) facilities tackled on for better usability but that's not a requirement.
For cases (2) and (3) it can (depending on language and implementation) also provides a mechanism for making other value types optional without necessarily having to heap-allocate them.
* Just a forward-style abstract interpretation living on-top of Go's type system as an additional layer so you get explanations for why the tool believes that a nil-pointer dereference may occur, etc.