5 ms·

I've been following Nim for a while now (including back when it was called Nimrod), but the big reason I've never dug much more into it is because it repeats th

I've been following Nim for a while now (including back when it was called Nimrod), but the big reason I've never dug much more into it is because it repeats the Billion Dollar Mistake[1] of allowing values (yes, not all values, but important ones) to be nil without explicitly using Option types. It's disappointing that Nim has not (perhaps cannot, for backwards compatibility) learned the same lesson here that most other modern languages have, and used explicit nilability embedded in the type system. And to preempt the argument that "you can't, for performance reasons!", you could do the same thing as Rust does and explicitly opt-in to having your code break if something is nil, via a call like `.unwrap()` which the compiler may optimize away. [1] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/ https://www.infoq.com/presentations/Null-References-The-Bill...

rezeroed 6y ago
https://nim-lang.org/docs/options.html https://nim-lang.org/docs/options.html
- cheriot 6y ago
  The real question is: how much of standard libraries and broader ecosystem use them? Scala has null values, but broad usage of Option and Either so I can often write code as if null didn't exist.
planetis 6y ago
> ... allowing values (yes, not all values, but important ones) to be nil ... What!? What that even means? Value types can't be nil in nim-lang, these are always initialized, but you can use Option[T] when you need it. If you mean reference types (`ref`) hopefully this PR will land soon https://github.com/nim-lang/Nim/pull/15287 https://github.com/nim-lang/Nim/pull/15287.
- Conlectus 6y ago
  Reference types were indeed what I was referring to.
rayman22201 6y ago
This is currently being remedied as we speak: https://github.com/nim-lang/RFCs/issues/250 https://github.com/nim-lang/RFCs/issues/250 https://github.com/nim-lang/Nim/pull/15287 https://github.com/nim-lang/Nim/pull/15287
elcritch 6y ago
Unfortunately, it'd be impossible to work effectively with C code without `nil`. You can create objects set to `not nil`. To be fair, I've had a few points when creating a new type that I forgot to allocate a new instance properly, but option types wouldn't have saved me any work. It would've produced a similar stacktrace. I think the compiler produces a warning, but I'm still working down the warning's lists. You can see more discussion on defaulting not nil here: https://github.com/nim-lang/Nim/issues/6638 https://github.com/nim-lang/Nim/issues/6638
- Conlectus 6y ago
  Having all references that are returned from C be treated as Option types would resolve this difficulty, no? Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed. Though yes, I'm glad to see this is being addressed :).
  - elcritch 6y ago
    > Having all references that are returned from C be treated as Option types would resolve this difficulty, no? Perhaps, but there's more than just returns. Dealing with most C code there's a fair bit of pointer passing and manipulation. It's nice being able to deal directly with C code and not have to worry about the impedance mismatch, but still be able to move up the type system. It's more a pragmatic choice. > Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed. In this case, mostly its just me not using the type system well. :-) But that's the price I pay for a using a flexible language I can readily use in embedded work. NPE's really don't cause me any headaches compared to most of the other aspects of integrating heavily with C code in embedded systems.
    - nine_k 6y ago
      All the convenience and all the unsafety of C code while interacting with C code? Why not just use C, or C++ if expression power is needed?
alehander42 6y ago
I am the guy assigned to work on that: sorry for the delay, but it is being worked on.
- Conlectus 6y ago
  Excellent news! I read the discussion that has since been linked elsewhere, and got the general impression that there wasn't going to be a change for backwards compatibility reasons. Glad to be proven wrong!
  - alehander42 6y ago
    the default might not be changed in 1.x, but this shouldn't make it less typesafe: access to nilable types would be checked. there are also the z3-integration related checks which might even apply to index bounds or eventually other invariants, so this kind of safety is important for Araq and Nim https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html

rezeroed 6y ago

https://nim-lang.org/docs/options.html https://nim-lang.org/docs/options.html

cheriot 6y ago
The real question is: how much of standard libraries and broader ecosystem use them? Scala has null values, but broad usage of Option and Either so I can often write code as if null didn't exist.

planetis 6y ago

> ... allowing values (yes, not all values, but important ones) to be nil ... What!? What that even means? Value types can't be nil in nim-lang, these are always initialized, but you can use Option[T] when you need it. If you mean reference types (`ref`) hopefully this PR will land soon https://github.com/nim-lang/Nim/pull/15287 https://github.com/nim-lang/Nim/pull/15287.

Conlectus 6y ago
Reference types were indeed what I was referring to.

rayman22201 6y ago

This is currently being remedied as we speak: https://github.com/nim-lang/RFCs/issues/250 https://github.com/nim-lang/RFCs/issues/250 https://github.com/nim-lang/Nim/pull/15287 https://github.com/nim-lang/Nim/pull/15287

elcritch 6y ago

Unfortunately, it'd be impossible to work effectively with C code without `nil`. You can create objects set to `not nil`. To be fair, I've had a few points when creating a new type that I forgot to allocate a new instance properly, but option types wouldn't have saved me any work. It would've produced a similar stacktrace. I think the compiler produces a warning, but I'm still working down the warning's lists. You can see more discussion on defaulting not nil here: https://github.com/nim-lang/Nim/issues/6638 https://github.com/nim-lang/Nim/issues/6638

Conlectus 6y ago
Having all references that are returned from C be treated as Option types would resolve this difficulty, no? Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed. Though yes, I'm glad to see this is being addressed :).
- elcritch 6y ago
  > Having all references that are returned from C be treated as Option types would resolve this difficulty, no? Perhaps, but there's more than just returns. Dealing with most C code there's a fair bit of pointer passing and manipulation. It's nice being able to deal directly with C code and not have to worry about the impedance mismatch, but still be able to move up the type system. It's more a pragmatic choice. > Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed. In this case, mostly its just me not using the type system well. :-) But that's the price I pay for a using a flexible language I can readily use in embedded work. NPE's really don't cause me any headaches compared to most of the other aspects of integrating heavily with C code in embedded systems.
  - nine_k 6y ago
    All the convenience and all the unsafety of C code while interacting with C code? Why not just use C, or C++ if expression power is needed?

alehander42 6y ago

I am the guy assigned to work on that: sorry for the delay, but it is being worked on.

Conlectus 6y ago
Excellent news! I read the discussion that has since been linked elsewhere, and got the general impression that there wasn't going to be a change for backwards compatibility reasons. Glad to be proven wrong!
- alehander42 6y ago
  the default might not be changed in 1.x, but this shouldn't make it less typesafe: access to nilable types would be checked. there are also the z3-integration related checks which might even apply to index bounds or eventually other invariants, so this kind of safety is important for Araq and Nim https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html