They really ruined Optional not solving this then and there

"If you really don't want people instantiating instances of a type on their own, can't you just make the type private but make a factory for the type public?"

"Yes", but really, no. It is syntactically valid to write a function that returns an unexported type, and you can technically get an instance of that unexported type in your other package by using := to assign it to a variable. However, you can not name the type in the other packages at all. So, you can not say "var x mypkg.unexportedType", even if you can "x := mypkg.ReturnUnexportedType()". You can not put it in a struct/channel/slice/map/whatever, since you can't name it and there's no equivalent of := for types. You can't refactor the function that contains the "x" in any way that involves passing it to a new function because the type signature for the new function would have to mention the unexported type, which it can't do, and there is no inference for function types that would let you elide it. Reflect restrictions on unexported types are still in effect so even trying to put it in an "any" isn't really all that useful.

Basically, it's useless, even though it's just barely sort of valid, because it's much more than just creation that is blocked. In practice you have to export types you want users to be able to assign to, put in structs, etc., and if they are exported, their zero values can be created by any package that imports them. One of the standard linters in golangci-lint will warn you if you accidentally write an unexported type into an exported type or value, because you didn't mean that, even if you thought you did.

You can write an interface that you export, and then return an unexported data type that conforms to that interface. However, you then can't prevent someone from having a nil instance of that interface, so in terms of preventing invalid data, this doesn't really do anything useful. This is more useful for manipulating package documentation by not exporting types unnecessarily and having to write docs for them (or, if you don't write docs, having them appear in the godoc) then as access control.

Dangerous by default is still a pretty bad design choice.

But the point is Go still allows bad patterns. You can always avoid bad patterns, but not everyone will. See C++20.

Perfectly possible to write beautiful code. Alas, hell is other coders, or something.

Edit hot take: I wish Go would just have been Pascal/Delphi rebranded. All language discussions just ignore we had a contender against C for decades.

If you say it’s too weird, don’t come dragging in Go in the same breath, thanks.

I worked at a Java shop for a while, with a small and new-ish codebase built by experienced devs, and most of the errors we encountered were null pointer exceptions. It was always just, "alright where do we need to add another if-statement this time"

Of course you could be "defensive" by adding an if-statement every single time you use any object. But that would mean an order of magnitude more lines of code, and even then it would be easy to miss cases

Every thread about null has someone come in and make this claim that it doesn't come up in production in well-maintained codebases, but it feels very No True Scotsman: every counterexample that someone can point to immediately doesn't count, because the definition of a "well-maintained codebase" seems to be one in which null pointers aren't an issue.

I guess that's a fine definition in theory, but every codebase that I've ever worked in that was written in a language with null references has had null pointer exceptions as one of the top recurring bugs. Maybe that means all my codebases have been poorly maintained, but if so that's a very good reason to design languages that require less maintenance.

Of course it's physically possible for a software project to exist where all contributors flawlessly handle nullability.

The point is rather that, because this can be automated, it ought to be automated.

The same could be said of automated tests ("in well-maintained codebases contributors manually run through a large suite of tests to ensure there are no regressions.")

This is the “as long as programmers are perfect and remember to always do the right thing everywhere, everything will be great” argument.

Developers are not perfect and the footguns in languages have a cumulative effect. Any one thing isn’t necessarily a big deal but when you have multiple interacting footguns (always check for nil, nil interfaces don’t actually equal nil, default zero values need to be sane even when they make no sense, etc.) both the surface area for errors and the level of care needed to avoid them increases dramatically.

Do you have null dereference bugs that you occasionally solve, even if only during development? The "billion dollar mistake" is a reference to the economic cost of all bugs it created as a concept. That doesn't mean you don't build techniques to work around it, but it does mean that that's the economic efficiency left on the floor.

In other words, the cognitive overhead you spend on worrying about nulls (however you do that), programmers in other languages spend on other things.

Finding out a piece of software I'm using is written in Go because crashes with SIGSEGV does not spark joy.