> 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: 1. Dealing with bugs. For the last few years I've been coding only occasionally and my projects are tiny. Nevertheless, even I encounter compiler and other tooling bugs, as well as little issues in the standard library pretty regularly. This is truly a new experience for me, but I can live with it, while for some people considering Nim professionally it might be a dealbreaker. 2. Fully embracing already released features and adopting the ecosystem to fully utilise them. Namely: view types and concepts in standard library as much as possible. They should be normalised in the eyes of the Nim users as the core features of the language. 3. Increasing the velocity of the development. Currently the main team looks overwhelmed, so small changes and fixes should be made possible to implement with minimal involvement on their part. Decisions have to made faster where the possible damage area is small enough to afford mistakes. I don't say I know how to do it, but at the very least it would be wise to consider this as a goal. Some ideas by Arne will bring Nim closer to achieving this. 4. [3.2] Increase the involvement of the community. This requires: even more verbalised plans and roadmaps, more smaller task (with clear requirements and boundaries, not just open issues) which can be delegated, community initiatives, bounties, some structural changes which decrease interdependence of parts of the language so small breaking changes and mistakes can be more easily dealt with.
