Unbundle DrNim

[juancarlospaco]

"Do not bite off more than you can chew" kinda situation with DrNim,
I think it should be unbundled from the compiler installers, because is not very useful in its current state.

• No one is actually using DrNim daily in production.
• It failed to attract any hype or active contributors in a looong time.
• It often fails to compile or run (tried Windows, Linux, different PC, etc).
• "Cant load Shared Library libZ3".
• DrNim out-of-the-box user experience is not great, you gotta koch it.
• No development-relevant commits in DrNim in a long time, besides typos, documentation fix, etc.
• Nim team work is better spent elsewere, in things used daily by users and companies.
• Less code to maintain, free up more resources to fix important stuff (IC, ORC, etc).

https://github.com/nim-lang/Nim/tree/devel/drnim

[Araq]

I'm not against it but historically projects of mine that depend on the Nim compiler API bitrot quickly unless they are part of Nim's repository.

[juancarlospaco]

I'm not against it

Ok, then it can move forwards (?). 🤔

[PMunch]

I'm not against it but historically projects of mine that depend on the Nim compiler API bitrot quickly unless they are part of Nim's repository.

Maybe this should be a sign that the Nim compiler API should be a bit better defined/documented. NimLSP seems to work fine (well, it doesn't crash more the further along the version of Nim you go), but I suspect that is only because it wraps Nimsuggest which does all the actual interfacing. Maybe moving some of your tools into their own separate repositories and maintain them there with the compiler changes would benefit other users of the same API.

[juancarlospaco]

Rotten code in your compiler distribution is not a good Marketing for new companies to migrate to Nim.

[Araq]

As if they would know, but fine, migrate it to nim-lang/drnim or araq/drnim then.

[juancarlospaco]

@Araq
Companies do check issues, pull requests, documentations, licenses, github stars, github repo stats, etc when evaluating new programming languages to use.

I have seen it multiple times, thats the reason I try to remove the Telemetry from choosenim,
some open source companies do not like bundled Telemetry, not even disabled Telemetry,
simply because they can choose other languages that dont need that (Nim really dont need it neither),
it is a random example, but just another thing of Nim Marketing that can be improved...

[juancarlospaco]

Roadmap for future is here #437 (comment)
No mention of DrNim developments, so I think is more reason to unbundle it, how can nim-lang/drnim be created?.

[juancarlospaco]

So this RFC has no concrete response since 2021,
is a ton of code to maintain that nobody is using in prod everyday,
maybe 2.0 is a great opportunity to Deprecate the old dead code?.

See also #476

[Araq]

It's just a bad idea. The compiler API keeps changing and at the same time ensuring DrNim keeps working is close to zero work.