So many replies, pardon me for cherry-picking. @archnim
> I think that you shouldn't abandon the community. We are here for Nim. We are hobbyists, Nim is for most of us a pastime, if it becomes a chore why should we spend our limited energy after work and family on it. So the question becomes, how to keep Nim enjoyable. The answer is obviously different between hobbyists and those that start to rely on Nim for production. > > the Nim compiler has become insanely difficult to work on > You are certainly the only person to think that here I agree with @carterza, sigmatch and semcheck in particular are Lovecraftian eldritch horrors. They produce bugs over and over and pushing generics/distincts/`when` types triggers all sort of issues that eat days: <https://github.com/status-im/nimbus-eth2/issues/2219> @carterza > Dominik's community policing is only one aspect of the damage their > leadership causes to the community. Abdication of responsibility for > maintaining tooling which was cargoculted and evangelized is another. There > are plenty more. If you want to say you're the only mature one because you > have gotten over criticizing Dominik's leadership then fine - but I'm also > not the only "immature" person complaining about them or their decision > making and leadership tact. To expand on that, I have noticed many events where Dom could have or may have done significant damage to the community and Nim: * The Nimble package structure is overly zealous, and AFAIk he is the only one defending the status quo: * <https://github.com/nim-lang/Nim/issues/6700> * <https://github.com/nim-lang/nimble/issues/472> * <https://github.com/nim-lang/nimble/issues/653> * <https://github.com/nim-lang/Nim/issues/7250> * <https://github.com/nim-lang/nimble/issues/993> * The nimble security vulnerability was mishandled despite 6 months lead time. It's hard to write something secure, but people will absolutely look at how we handle responsible disclosure: <https://consensys.net/diligence/vulnerabilities/nim-insecure-ssl-tls-defaults-remote-code-execution/> Then there are a couple other events that marked my mind: * asyncdispatch that had to wait for a fork to happen (see <https://github.com/zevv/nim-async-issue> for a neutral party overview), * wanting to freeze the standard library causing rot in key components like streams, sequtils or strutils, * recommending not to use commit hash in nimble dependencies even though this is a requirement to prevent supply chains attacks: * <https://blogs.sap.com/2020/06/26/attacks-on-open-source-supply-chains-how-hackers-poison-the-well/> * <https://www.esecurityplanet.com/applications/open-source-sabotage-incident-hits-software-supply-chain/> @r3c > imo there is desperate need for Roadmap * <https://github.com/nim-lang/RFCs/issues/437> * (and also <https://github.com/nim-lang/RFCs/milestone/5>) @carterza > Look at Odin, Rust, Zig - all of these other languages achieving mainstream > success. You know how they got there? Good marketing and allowing the > compiler devs to focus on developing the compiler and left running the > community up to folks with experience there. Andy Kelly didn't decide with > Zig that he knew how to best run a community or software project - he found > someone dependable with experience there and they've done a pretty amazing > job if you ask me. They didn't have Mozilla money either... Same story with > Odin, which has now been used in a commercial VFX solution that is being used > by AAA studios throughout the games industry. It's a baby in comparison to > Nim. > > It's just one example of a misallocation of resources and miscalculation > about what might attract people to Nim. No one has done any research about > how many new users the forum has brought in because it's such a marvel of > technology or the proof everyone wants that Nim is a capable PL worthy of > their attention. Leadership actively fights with anyone who disagrees though > and instead of empowering the community with decision making capabilities > they conduct a survey every year which is never consistent and doesn't really > answer any real valuable questions. Not to mention there's no real roadmap > for the survey to influence so.... Interesting data points. @euant > At this point in Nim’s life, in my opinion there should be a concerted effort > to stabilise the standard library and the compiler rather than adding > anything more. There are so many features and switches and toggles that even > if you look away for a month or two there’s something totally new or > different. While not as radical as NimSkull, I'd rather we deprecate, delete and redesign part of the standard library that is core to any languages and is currently reimplement often: streams and sequtils/strutils (and a couple others). The standard library should embrace the fact that specialized Nim devs can write better tuned code and also maintain it. And for compatibility/interop what is important is a consistent **interface**.
