[question] Current Nimskull vs Nim

[heysokam]

Hi there,
I took a look at this project some time ago, and I like what I'm seeing now in comparison.
I see some good effort put towards ideas that I agree and resonate with (thinking of the roadmap in particular)

I'm currently use a custom-built version of Nim, and I don't use choosenim, nimble or atlas anymore.
My n.1 project right now is https://github.com/heysokam/minc, so I don't really require much beyond the parser and the stdlib string management section 🤔

So, I was wondering:
What's the state of Nimskull "readyness" (to call it something) at the moment?
Considering I do everything on my own at this point, and rely only slightly on the ecosystem, what could I be missing if I switched to nimskull today?

[saem]

Thanks for taking interest, @heysokam.

You can either build from source, grab pre-built binaries + source archive, or use asdf to use the compiler and tools.

I took a brief look at your nimble file and you can easily pull those down with wget or the like, or you might be able to use nimph. IIRC @alaviss has a fork that works with nimskull somewhere.

You won't be able to target C++, we dropped that, but it doesn't look like you care about that. The only thing I spotted on my quick glance is the config.nims, that'll need to change to a nim.cfg, but it's really straightforward.

The C code we generate is a lot cleaner, our compiler is likely a good 20% faster and uses less memory, so your CI should be quicker.

We do break things but our commit messages are very detailed, and it's really easy to pin versions on your end until you're ready to upgrade. Most of the breakages are in corner cases noone notices or features noone seems to use. In addition as we test fairly heavily and push for the right abstractions, this trend to drive towards actually stability (unlikely to change), as opposed to pretending (semver nonsense).

No way to measure it but I suspect our language test coverage far exceeds nim's, but that's likely untrue for the standard library as we haven't reworked that much.

In terms of example, CPS and companion projects, which push the language quite hard came over successfully. This also resulted in fixing a bunch more bugs they surfaced.

But if a rambling reply, but I think it should cover a number of aspects. If you've got detailed questions, I would skim through the commits. We're also in matrix for ad-hoc discussions.

[heysokam]

I took a brief look at your nimble file

I don't use nimble at all personally. I only have that file for external support to other (potential) outlookers. I should probably drop it entirely, but I keep it because I still consider it a "nim library" at the moment. Might reconsider that in the future if nimskull covers my compiler goals.

The only thing I spotted on my quick glance is the config.nims

Which file you mean? I don't use any .nims file as configuration at all 🤔
The only .nims files I have are actual script files that run independently

You won't be able to target C++

1000% don't give a damn about that, yep. You got that perfectly right :)

Overall great to hear. Will give it a try ✍️

[saem]

The only .nims files I have are actual script files that run independently

Check your test directory

[heysokam]

oh! that's dead code. look at the files, their content points to nowhere 🙈
thanks for reminding me about them, I haven't cleaned that up in a while