News for hackers. Stuff that matters.
Re:Experience Report: 6 months of Go by throwaway894345 on Saturday April 30, 2022 @04:07PM (#31218833)
This is one of the warts I wish Go would fix (implementing Rust-like enums, and ideally getting rid of zero values and nils, but these things won’t happen). Even still, Go is the most productive language I’ve used because it turns out type-systems (cool though they are) are overrated—you only need enough of a type system to keep things documented for humans and tools. 95% type safety seems to be the sweet spot (peak productivity) after which productivity begins to rapidly diminish. It’s more important to have decent performance, good tooling (simple with sane defaults), small learning curve, great deployment story, etc.
Re:Experience Report: 6 months of Go by ttfkam on Saturday April 30, 2022 @06:30PM (#31220080)
I have never seen a language successfully eliminate nil/null and zero values after the fact. Once they're in, they're there to stay.
Re:Experience Report: 6 months of Go by dgb23 on Sunday May 01, 2022 @10:55AM (#31225506)
You can have robust and ergonomic code around nils if they are part of your type signatures and/or get some good language and standard library support:

In Clojure (Lisp) a nil is treated as a value which flows nicely through code, there are many idioms and utilities that are built for this and compose well. In Kotlin, Typescript, PHP there are unions which I find much more ergonomic than sum types for this use-case.

Re:Experience Report: 6 months of Go by throwaway894345 on Sunday May 01, 2022 @06:38PM (#31229416)
> You can have robust and ergonomic code around nils if they are part of your type signatures

Go has `nil` built into the type signature, but the problem is that all reference types are inherently nil-able, and value types can't be nil (although they can have their own in-band zero values). This means you either pass around values (with the entailed overhead and copy semantics) or you pass around nil-able references.

Why would unions be more ergonomic than sum types? Presumably they would have the same ergonomics?

Re:Experience Report: 6 months of Go by dgb23 on Monday May 02, 2022 @09:32AM (#31234887)
> Why would unions be more ergonomic than sum types? Presumably they would have the same ergonomics?

For this use case (can be a some type OR nil) they are more ergonomic because it is an actual OR, not a separate container. You want the thing as-is and handle the case where it isn't there not go through an intermediary type.

Re:Experience Report: 6 months of Go by throwaway894345 on Monday May 02, 2022 @02:12PM (#31238697)
I'm not sure I'm following. Rust allows:

    println!("{}", if x == None { "foo" } else { "bar" });
How would unions make this more ergonomic? For example, in Python (with type annotations), you would have to do:

    print("foo" if x == None else "bar")
Re:Experience Report: 6 months of Go by throwaway894345 on Saturday April 30, 2022 @07:59PM (#31220710)
Yeah, I have no illusions that Go will walk that back, especially considering its compatibility promise. It's a thorn in the side, but people also exaggerate it dramatically while overlooking major issues in other languages.