Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typed nils in Go 2

dave.cheney.net

Post reply on HN
Print view View original

101–110 of 119 posts

Re: Typed nils in Go 2

#101

Post by laumars »

masklinn wrote: post #98
laumars wrote: post #63

Earlier quoted context omitted.

> You're not "checking the value of a property after you've nil'd the parent object", you're checking if you were given a nil. Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Just to be clear, I'm not trying to defend nil here, but I do think it's important to understand the issue because I think the authors code would have failed regardless of the…

> Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Not really, Go supports (and encourages properly handling) nil method receivers. > Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type. Setting aside th…

> there is a gulf between "failing" as a clear runtime (or compile-time) error at the point of an incorrect invocation, and "failing" by silently yielding a nonsensical state

Of course. But then I also made that point too. Frequently in fact and in the very post you're replying to as well. Plus also in the other reply that echoed the same point you're raising here. I'm not justifying Go's behavior here. Absolutely not! It is unexpected and bad. But we have already established and agreed on that point so moved onto another question regarding whether the authors example is an issue that is likely to arise often. I was attempting to explain why I felt it was a poor example and not trying to justify Go's behavior - which at risk of repeating myself: we all already agree is bad.

Re: Typed nils in Go 2

#103

Post by mrkgnao »

laumars wrote: post #95
mrkgnao wrote: post #93

Earlier quoted context omitted.

Again, at the risk of repeating myself, it's not Haskell, it's "many languages other than Go, of which Haskell is one I'll be using by way of example". (I'm not sure why you made that edit, but I've made a mental note of what the last bit said. Arguing on the internet is a difficult, if useless, skill, and I'd hate to be tiresome.)

I made the edit because on reflection the part i took out was blunt and unnecessary. I felt I crossed the line so I apologize for that.

That's gracious of you. :)

Re: Typed nils in Go 2

#104

Post by camus2 »

ZGF4 wrote: post #100
pyrale wrote: post #18

Gotta love how the initial problem (a typed language in the 2000s having nil and empty interfaces) degenerates in workaround suggestions such as hacking nil and the interface system to give it a special type.

It is interesting how Go seems to be doomed to head down the same path as other languages it accused of being "bloated." No one intends to design a complicated language but the reality is that the problem space is complicated. The only thing that isn't so forgivable with Go is that these aren't new problems this time around. Go is still struggling to get over challenges that were first seen a long time ago. It's a gr…

> It is interesting how Go seems to be doomed to head down the same path as other languages it accused of being "bloated." No one intends to design a complicated language but the reality is that the problem space is complicated.

It's not surprising, it stems from the arrogance of Go designers who think they can eliminate complexity by deeming it irrelevant and making the user carry the weight of the complexity they refuse to deal with. Simplicity isn't hard, like Rob Pike says, it's a trade off.

If you're not going to have enums in your language for instance, you are forcing your users to implement their own, badly and in incompatible ways.

If you're not going to have generics, well you'll get this stupid situation where users are expected to "augment" the compiler with code generators, leading to an increase in complexity in building a program, or worse, ignoring compile time type checking since it's the path of the least resistance when dealing with generic container types.

Re: Typed nils in Go 2

#105

Post by Veedrac »

junke wrote: post #72
BlaXpirit wrote: post #67

Earlier quoted context omitted.

I thought it did not need to be mentioned, but dynamically typed languages don't count for this comparison. Every value is like a union of every type, and compile time type checks are impossible.

Why would a language define an empty type if not for static type checking?

I'm confused. Nil isn't an empty type. Why are you introducing them?

Re: Typed nils in Go 2

#106

Post by [deleted] »

ghthor wrote: post #60
mrkgnao wrote: post #53

Go is a lesson in how complexity can't be eliminated, only distributed properly from the beginning so that one doesn't have to hack it in later with messy special-casing that needs you to know how the compiler represents things under the hood. What happened to "lightweight typesystem that reduces cognitive load"?

It's really easy to criticize where mistakes were made. The intention was to make a simple language and it worked. The idea resonates with many many engineers even ones such as I that love writing powerful pure fn code. The intention was great and the result wasn't that great, but it still works pretty dann well. Go is an open language and they are asking for well thought out proposals on where & why the problems exi…

[deleted]

Re: Typed nils in Go 2

#108

Post by marcus_holmes »

sorkin2 wrote: post #88
marcus_holmes wrote: post #21

Earlier quoted context omitted.

I think they're referring to outer-joined tables. SELECT a.id, b.name FROM a LEFT JOIN b ON a.id = b.id If you get a NULL in the name field, you don't know if that's because there's no record in b for that id, or if there is a record in b for that id but it has a NULL name value. Sometimes that difference will be important.

While admittedly this could be seen as a mistake in SQL, you can differentiate by looking at whether b.id is NULL or not.

true, but that's not the point the OP was making, I think :)

Re: Typed nils in Go 2

#109

Post by Veedrac »

mrkgnao wrote: post #91
laumars wrote: post #89

Earlier quoted context omitted.

I used to fight Go's error system by creating wrapper functions to mitigate the need for nested blocks - essentially trying to "Haskellify" the code a little (for want a _very_ crude description). With time I realised I was spending more time over thinking a solutions and pontificating instead of just writing code and handling errors. Since then I've given up fighting against the language idioms I personally disagree…

I use Haskell examples because that's the language I'm most comfortable with, but, e.g. the Result type used in Rust is another example of how this can be done better. https://rustbyexample.com/std/result.html Ergonomic error handling or generics/parametric polymorphism aren't "Haskell methodologies". Go is one of a very small number of languages that have been designed in the last decade and lack features like this.…

Rust is my favourite language, I beg to disagree that its Result or Option types are more concise or require less boilerplate. The only real differences are that Rust's are type checked and harder to use.

Re: Typed nils in Go 2

#110

Post by junke »

Veedrac wrote: post #105
junke wrote: post #72

Earlier quoted context omitted.

Why would a language define an empty type if not for static type checking?

I'm confused. Nil isn't an empty type. Why are you introducing them?

It goes like this: the claim is that dynamically typed "don't count for the comparison" because "compile time type checks are impossible". Even if we suppose that nil values or union types are useless at runtime (they aren't), it is not true that dynamically typed languages could not be analyzed statically. Not only compile time type checks are possible, they are sometimes expected to happen and already part of some language's design.

Python added type hints recently, but in Common Lisp, there is not only a null type (which contains the nil value), but also an empty type: there is no practical use in defining a type for which there is no possible value at runtime, except if the language and its type system are designed to support static analysis. It it expected that a compiler can optimize away things that are known in advance to be impossible, or help you detect errors statically.

Post reply on HN