[gmfawcett]

Fair point. I should mention that I'm not a Nim expert, and am not defending its design. It's true that 'nil' appears in Nim under both of its pointer types (GC traced "references" and untraced "pointers") -- which is unlike, say, Rust's safe references vs. unsafe (nullable) pointers. So 'nil' is not simply a systems level construct; otherwise you might expect Nim to have nillable pointers, but not nillable references.

You need nil/null when doing systems work -- and Nim is capable of that -- but I don't know the rationale for allowing 'nil' in higher level language features.

[Isomorpheus]

Thanks for the honest reply.

Nim interests me but this nil business seems questionable to me.

Just found this comment from the language creator,

https://github.com/nim-lang/Nim/issues/6638#issuecomment-487...

"We need the nil state to disarm pointers but that only means these can be nil and so would require a nil check before deref. Doesn't seem to be too hard nor too cumbersome."

Seems a bit dismissive to me

[mratsim]

`non-nil` was deemed too breaking to introduce for 1.0 or even as a default because if you tagged your input as `T not nil` the compiler was not powerful enough to prove that T was indeed not nil except in the most obvious cases.

The new battleplan is to integrate the Z3 theorem prover into Nim as DrNim:

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

The first use-case will be proving array bounds at compile-time and elide them. Future use-cases include not nil tracking.

[Isomorpheus]

This sounds pretty cool, but, two thoughts

1) Echoing the other comments in this thread about uneasiness with feature creep

2) Wouldn't have been a breaking change if the language didn't have nil from the beginning

[mratsim]

1: DrNim is basically additional annotations that are ignored, and you can choose to opt-in via a flag.

It's something you similar to MyPy for python and type annotations. The danger is if it becomes non-optional.

That said contrary too many languages, the core language doesn't need:

- threading

- async

which are huge parts to maintain, but thanks to metaprogramming you can implement them as libraries with very nice syntax as well. It also allows compiler devs to focus on what they know well, compilers and leave those 2 highly specialized areas to people who are experts (or become experts) in those.

2: There are 2 dimensions there: nil is used for C FFI, for higher-level primitives you can use Option. And C FFI was needed to bootstrap Nim with a useful set of functionality and has an escape hatch so that people could start building early on and not wait for the language. So both from a functionality and a time-to-market point of view it was necessary.

[gmfawcett]

I agree that it's a sharp edge in the language. Or at least it seems to be -- I've written a little bit of Nim, and never encountered a case where I was actually bitten by 'nil'. The language does have a 'non nil' annotation that can be used when defining structs (and maybe in other parts of the language, I don't recall), so there must have been some thinking about the dangers of nil pointers.

I would still recommend playing with the language for a while. It's quite practical, and the performance is very good. I've used it to write some utilities where I might otherwise use Python, but either needed more speed or needed to use it in a restricted environment where the Python interpreter wasn't available. The experience was mostly positive, and I would use it again.

[elcritch]

P.S., you can annotate procedure to help ensure you can’t raise certain conditions in code. Imho it’s nice for writing sections of “safe” code.

[Isomorpheus]

Thanks, I intend to give it a fair try

[planetis]

That's an old comment by the way. At that time the newruntime idea was tested (and now replaced by --gc:arc). One needs to be more careful when using others words, especially taken out of context.