Recently, the idea has formed that we should release a V2 that systemically breaks things "while we're at it", since a v2 was announce anyway.
Originally, the v2 discussions started as an idea to celebrate ORC/ARC and the switch to a new GC - this will bring many changes to how canonical Nim code should be written - it will also require reviewing existing code as semantics of freeing resources in general will change - files will close at different points in time, some finalizers will run earlier, the performance profile of operations will change significantly (ie when cycles are spent on clearing memory and the cost of allocation etc etc - in high quality code, this matters significantly) and many other small and subtle changes that come with the new model.
One can think of this journey as being similar to when C++ moved to version 11 - move and unique_ptr where introduced which significantly changed what well-written C++ looked like. Notably though, for the most part, the C++11 change was backwards-compatible - it would have been nuts to break decades of work and thousands of libraries just to get move support into the language, or add other, unrelated breaking changes just because r-value refs where new and important.
Somewhere along the way, people started associating the celebration of ORC/ARC with the idea that we should piggyback lots of other breaking changes on top - many done simply for the sake of breaking code, to address frivolous issues like the existing names not fitting someone's taste, or removal of working API only because a slightly improved version also exists.
This piggybacking is problematic for many reasons, so let's list a few:
Now, to many of the v2 problems, there actually exist simple and systemic ways that deals well with change:
Thus, rather than making one big V2 bang thinking that this will somehow "fix everything that's wrong with Nim" within a reasonable timeline, what's needed is a structure under which change can be introduced over time, so as avoid staleness in the language, and at the same time promote a mindset and culture that values the contributions of existing Nim users and sees them for the asset they are.
Of course, I'm writing this with a vested interest: we have written lots of Nim code that covers a wide range of topics from CLI parsing to cryptography, user interfaces, web services, distributed peer-to-peer systems and more - we value every effort that goes into keeping Nim the fantastic language that it is and expect to see its evolution accelerate with the techniques discussed above, simply because this plays well with a distributed and lively community that can grow without relying on and waiting for the core Nim team to do all the heavy lifting and thus becoming a central bottleneck that has to deal with everything from faulty json parsers to ftp clients.
I feel like if I have the right flags I am already on Nim 2.0, it's just as a library author I can't dictate them top users. Please just enable the features we already have so that they work well for everyone. And SSL continues to be pain. I made whole library - puppy - to get around these issues. Some thing needs to get fixed here.
I vote no on:
I would edit, but it doesn't work:
When splitting up the std lib, this doe not mean that they need to be handed off to a different set of maintainers or have lower quality standards applied!
In fact, the whole thing can stay in the same git repo, as long as each part gets versioned separately (andt therefore can be released independently: important fixes don't have to wait for a nim release and vice versa)
Agreed with treeform on these: > - Make Orc the default gc. > - Threads on by default (including new isolate/channels/threading). > - Get many of the experimental features stable: overloadable enums, the dot "." macro, default object values... > - Make -d:ssl as default, fix bugs around SSLv3 and having to ship dlls/certs on windows.
When these are done, I'm okay with breaking changes. But right now stabilizing stuff and making sure everything works as they're supposed to is the way to go.
Please split the stdlib and move it to its own repo so that people can bikeshed in that repo's issues. And of course versioning the stdlib will be useful too, especially if newer stdlib versions keep supporting LTS Nim versions. C# people do that too.
Somewhere along the way, people started associating the celebration of ORC/ARC with the idea that we should piggyback lots of other breaking changes on top
Well, that's because ARC/ORC were released rather long ago and "celebration" can't happen if the standard library is not utilizing the new model fully and there's not enough users to feel the change for the better.
the desire to remove things will not die with v2 - this is a problem that every project that lives for some time has to face, and continuously - a single breaking v2 does not actually solve the issue, instead it just kicks the can down the road
The desire never dies, but the freedom to act on it can only decrease (if the language is living a healthy life of course).
To be frank, no offense, but in the grand scheme of things Nim has almost zero public software products built with it in use to show, with a few notable exceptions, such as Status and Nitter. So, the only proper time for a breaking change is now, not later.
splitting up the standard library into smaller components that can be developed, upgraded and deprecated separately
That is formulated very poorly, because the context defines everything here, in my opinion. If the only things that change are internal structure and governance, it's fine and probably the way to go. But if it results in depopulating standard library and increasing the reliance on the Nimbleverse, I'd be totally against. I could expand on whys if anyone feels like asking.
what's needed is a structure under which change can be introduced over time, so as avoid staleness in the language, and at the same time promote a mindset and culture that values the contributions of existing Nim users and sees them for the asset they are
Strongly agree.
My comment may seem contrarian, but I get Arne's drift and support it. Some of the ideas in the other v2 thread, while interesting, are really ridiculous. Nim, like any growing project, has problems, and that's ok. What's not ok is it sometimes feels there's just not enough hands to deal with them. So, this leads me to believe that instead of whishlists of things to add and change, we should discuss priorities and structural changes dealing with the concrete issues at hand.
Thus, my list is:
In fact, the whole thing can stay in the same git repo, as long as each part gets versioned separately (and therefore can be released independently: important fixes don't have to wait for a nim release and vice versa)
It never occured to me that we can do it this way. Requires some thorough thinking but I love the idea.
It never occured to me that we can do it this way. Requires some thorough thinking but I love the idea.
this is part of our nimble requirements and lockfiles before we can move to it, that we can use a monorepo seamlessly - it applies equally to many of our own projects - it'll take some figuring out because the "git version" of a library will no longer be the "most recent commit" but rather "the most recent commit of the most recent change in the library + any deps that library has" - it requires that each library declares its dependencies explicitly (or implicitly via some mechanism, but it must be deterministic).
It gets really interesting with go's "minimal version upgrade" strategy which avoids changing dependencies unless explicitly asked for.
Do we want Nim to go this way?
because the "git version" of a library will no longer be the "most recent commit" but rather "the most recent commit of the most recent change in the library + any deps that library has" .
Why not utilize submodule for this? It seems easier to implement and more flexible.
Why not utilize submodule for this? It seems easier to implement and more flexible.
Because submodules are difficult to work with, when wanting to perform an atomic change to several related libraries - i e few developers reach the level of skill needed to perform such a change correctly, and even for those that do, it's a tangled mess that is best kept at arms length.
The outcome is usually that libraries end up bigger than the "natural" boundaries of the problems they solve (the std lib is an excellent example of this), just to not have to deal with said mess, which in turn makes it more difficult to manage change and adaptation.
See also https://github.com/status-im/nimbus-build-system/ where we do exactly that - it's neither "easy" nor "flexible", by any definitions of those words ;)
C++'s obsession with backward compatibility is the reason that it has
...become one of the most successful languages on the planet.
I've said it before, but the pathological thing about breaking changes is that they punish the most dedicated users -- the ones who invested the most in the language by writing large codebases in it (including the author of this thread, of course). These are the users who write our libraries and make the nim ecosystem better.
Of course there are things i'd like to break if it had no consequences. In the Nim 2.0 thread i even expressed some sympathy for removing case insensitivity, but after thinking more about how much breakage it would cause, i can't get behind it. Small breakages that are necessary for important changes (like ARC/ORC) are tolerable, but we really shouldn't be breaking things for superficial reasons.
C++'s obsession with backward compatibility is the reason that it has become one of the most successful languages on the planet.
You're saying that as if it was a good thing.
For most breaking changes, it's easy to write an automatic conversion tool, so it's not that much of a problem in practice. Or we could do it like Rust with its “edition” system.
For most breaking changes, it's easy to write an automatic conversion tool
Thank you for volunteering to write it :D I think you are underestimating how hard this is to do for anything beyond simple things like function renames. And even if this tool is written, everyone will be forced to wait for all the library authors to run it and tag a new release (or they must fork the library and run it themselves, fragmenting the ecosystem in the process).
Rust's editions are neat, but they are used sparingly, mainly for things like introducing new keywords. Rust is not using editions to introduce sweeping changes to APIs or syntax -- even when technically possible, it'd be a bad idea, because updating your code to a new edition would be painful, and old tutorials/docs with invalid code would pollute the web for many years to come.
Thank you for volunteering to write it :D
No problem, let me know when there are any changes to apply it to. Though someone who knows how the compiler works may be a better candidate.
And even if this tool is written, everyone will be forced to wait for all the library authors to run it and tag a new release (or they must fork the library and run it themselves, fragmenting the ecosystem in the process).
We could have Nimble automatically apply it on download to packages made for the old version of the language.
We could have Nimble automatically apply it on download to packages made for the old version of the language.
I do admire the self confidence that leads one to think that their source code transformer is 100% bug free and will never produce invalid code, making it safe to automatically apply to every downloaded package. While you're at it, you should make a browser extension that automatically transforms all the old invalid Nim code on the web into Nim v2 🤯
I bet that a half-decent conversion tool will cause fewer bugs than C++'s preprocessor.
While you're at it, you should make a browser extension that automatically transforms all the old invalid Nim code on the web into Nim v2
I'm pretty sure the Nim compiler doesn't transpile to JS, so with a converter using it, that would unfortunately not be possible.