I am very new to Nim so take everything I have to say with a brick of salt.
However, perhaps my newcommer point of view can be useful.
Immediately one of the things I noticed about nim is how little time it took
for me to be productive in it. I went from not having really seen the language
before to writing a working app in a single sitting. That's really nice.
My exposure to nim started with me reading the nim manual. It's actually quite
long, and I didn't have the stamina to get through the entire thing in one go.
I thought about how I had learned other languages, like C# and Java and I
realized that I had not learned the entire thing in one sitting. I learned the
basics, got good at those, and then steadily learned about all the various
obscure things those languages could do. I figured I'd give nim the same
treatment, and it worked. I went through the manual and learned just enough to
be dangerous with nim, and from there I started hacking away. The less you need
to know in order to get going with a language, the easier this approach is.
That entire paragraph can be summed up in a single sentence: _Nim has a low
barrier of entry._ I believe that has also been google's approach with go: to
make being productive in that language happen as fast as possible.
Now let's look at rust: it has a complex ownership model that has a steep
learning curve. It's significantly harder to jump into rust with both feet and
be productive from the get go. Talking about memory ownership and what not
makes me fear that nim might go towards the path of rust. That is, raising the
amount of mental overhead that's needed for a newcommer to become productive
with the language. It's great that you don't have to think about memory
management with nim. I think as soon as we have to start thinking about that
sort of stuff, nim will lose a big selling point.
As far as I know, the main benefit to such an ownership model is performance.
Reference counting has a bit of a performance overhead that an ownership model
like the one proposed would remove that overhead while maintaining the safety
we've come to expect. My knee jerk reaction is that this sounds a lot like the
root of all evil: premature optimization. We are now forced to think about
memory a little bit for the sake of having nim perform slightly faster.
My naive thoughts on this is: why not both? By default, everything is exactly
how it is now. Reference counted and safe. No thinking about ownership needs to
be done. Someone can be productive in nim without even needing to think about
memory management. But for those who do want that extra 5-10% of performance,
they can opt into a more strict/performant and complex memory model. These
could coexist side by side in the same nim project. Some (probably most)
objects are reference counted, and some of them can be ownership managed. The
nim compiler would know which one is which, and would handle their allocation
and deallocation accordingly. It is the programmer who explicitly decides
whether an object is counted or owned though. Perhaps something like this would
work:
# Normal ref counted object, old code still compiles and behaves as expected
type
Node = ref object
data: int
Run
# This object is owned. It has the semantics proposed in this thread
type
Node = owned ref object
data: int
Run
For the sake of completeness, perhaps add something like:
# This is the same as the first code block, but is very explicit for
readability
type
Node = counted ref object
data: int
Run
I really liked the [research
paper](https://researcher.watson.ibm.com/researcher/files/us-bacon/Dingle07Ownership.pdf)
from Google/IBM. Their decision to add the ^ operator to make it clear that
ownership semantics were in play seemed like a good choice, and would overall
reduce confusion.
Anyways, that's my perspective as someone who's just starting to get exposed to
nim.
