NimSkull: A Hard Fork of Nim | Hacker News Reader

NimSkull: A Hard Fork of Nim

github.com

77 pointscercatrova89 comments

Community splits around concrete technical choices (e.g. NeoVim, and use of Lua as a scripting language) SOMETIMES survive and thrive.

Forks that seem to exist for no clear reason other than disgruntled person(s) thumbing their nose at an upstream maintainer never do.

If this were meaningful, then there would be clear roadmap (at least high-level aspirations without dates) announced with the repo’s creation. Without that, this is little more than a gripe post on a Nim mailing list.

It generally seems to the latter case with mostly disgruntled people with some areas where they were passionate. It doesn't seem to be "producing" anything, so it doesn't appear to be like NeoVim or similar. The Nim compiler/core seems to be progressing still and not stagnating.

The first such fork that came to my mind was the "egcs" form of GCC. Egcs thrived and in the end effectively took over the "main" GCC line.

There is a chance that this fork could be similar to egcs, following the same trajectory as "Nim done better" evolving into "the current Nim variant/implementation".

Conservative improvements like specifying some dark corners better can attract users (more than flamboyant novel features), and correction of bugs can retain them.

https://github.com/ayojs/ayo comes to mind.

!: this is mostly a personal note although I am one of the nimskull contributors

For now the aim of this project is first and foremost refactoring and making it easier to contribute and improve the main code base of the compiler, as indicated by the "near-term" timeline that is shown in the readme.

This is mostly a disclaimer for the common reaction that invariably starts to move the discussion in the direction of "why not contribute to mainline instead", "disgruntled people" etc. etc.

At the moment we are focused on making it easier to work with the codebase - more documentation, cutting down on decades-old cruft and legacy features, unraveling mysteries of the commit messages that were written with this attitude https://github.com/nim-lang/Nim/pull/19211#issuecomment-9859... ("I have no intention to follow this guideline so I cannot accept it.")

Applying data-oriented design principles, writing a specification, providing guides for compiler developers https://nim-works.github.io/nimskull/debug.html and focusing on what is important for people who work in the project.

At least that's why I work on nimskull. I don't want to go into another round of "stories" that describe some interpersonal issues (which of course exist) and we explicitly opted to keep this our of readme as well, even though other might be interested in dirty details.

> unraveling mysteries of the commit messages that were written with this attitude https://github.com/nim-lang/Nim/pull/19211#issuecomment-9859...

Curious to know what your vision of commit messages is. My commit messages look exactly like the excerpt in your linked issue: they describe what has been done.

Commits message guidelines are a part of the contribution guidelines and are available in the documentation (linked in the GitHub page). Concrete application of said guidelines can be seen in the commit message history.

That reminds me of another project. Whatever you do, do not write the commit messages like that, and your are doing great: https://github.com/BeRo1985/pasvulkan/commits/master

Someone's doing work.

My commit messages:

Fixes

Fix the fix

Frstegdghdsgsffff

More work

Fixes

Not everybody treats fixing software just as an excuse for writing detailed flowery diary of the development process itself consisting entirely of artisanal, handcrafted git commit messages.

Some people just fix software to fix software and for them the whole utility of git is to be able to see how the code looked earlier or even just keeping it in case they ever want to know that. They don't write commit messages because they don't read commit messages because they'd rather read code than prose. Trying to figure out what someone meant when they wrote the comment is sometimes harder than reading the code change itself. And if you need to delve deep into the prose here's the ticket number with all the words that were exchanged that lead to this change.

> Curious to know what your vision of commit messages is.

Not GP, but the postgres project is a pretty good example of what I strive for:

- a title explaining what the commit does (possibly expanding into the body if details would be useful)

- plus the body explains the background for the change (the why), ideally at all levels of resolution e.g. if it’s a 1 line fix to something deep inside the bowels try to trace the path from the original high-level report or issue, then why it was fixed where it was (especially if it took ages to track down and / or decide)

- and if useful or necessary, discussions of the implementation details / options / considerations

If there’s a mailing list thread, or a bug tracker issue, it should be included, but it should not be necessary: IME it’s way more common for the log than the bug tracker to survive the sands of time, because converting history from one VCS to the next is generally relatively easy.

Araq can be harsh sometimes, but what I'm reading in the linked github thread is a developer who at first doesn't see value in the PR (4th of december) but accepted the PR two days latter after being shown evidence that he was wrong. He didn't entrench, closed the PR without further discussion or requested an unreal ammount of proofs, which I have faced in a number of other projects. He just said: "so I'll try to follow this new guideline" and accepted the PR.

That does not magically rewrite all previous commit messages, although apparently the improvement is present https://github.com/nim-lang/Nim/commits?author=Araq - most of the total ~25 comments made in the last seven months since December 9, 2021 have more or less legible titles.

So nimskull is planning on rewriting all previous commit messages to be more legible? Or is that unreasonable?

Assuming unreasonable, isn't it unreasonable to expect someone to completely break git history for everyone, and or invent time travel?

Seems to be an absurd amount of condemnation over a mistake that did far less than hurting no-one

That's not what he's saying at all. He's saying that the maintainer now has better commit messages, but there is still a need to go back and produce documentation for undocumented code with inscrutable commit messages. e.g. doing better now does not undo prior damage

ok, how?

ok, why can that method that you choose not be applied to nim?

On how: The "method" is to just respect the future contributors from the start, instead of waiting for ten years until someone tells you to write better messages.

Why can't it be applied: no idea, writing sensible commit messages seems like a basic necessity if your goal is sustainable project development, but that's just me

ah, the time machine method then

Well good luck hard-forking backwards into the past to re-write commit messages.

I think it's great that you're tinkering with a compiler. But a language is more than a compiler; good language design requires a lot of programming experience, good taste and intuition, an ability to absorb programming language theory, and, yes, good programming skills. Araq has proven that he is a very capable language designer.

It sounds like you're taking Araq to task for trying out new things. And indeed, Nim is certainly a fairly expansive language. But a lot of the things he's trying are really cool, and I want to see the person with the _actual vision_ get a chance to try those things out without being encumbered by the need to write laborious commit message, because "democracy" and "best practices". Between Araq spending a marginal x minutes doing more on value types, and writing "clearer" commit messages, I'll choose the former, any day. I also trust him to jettison ideas that don't work.

I really think it's red flag when someone proposes to fork a language without being able to offer single reason that's actually related to language design. Sorry, I do realize this may come across as a bit aggressive, but I'm inclined to view you as a presumptious ingrate.

And really: when you come up with an original language that captures the imagination of scores of developers, I'll pay you the same respect.

Right now we are not forking "the language" as a collection of ideas etc. as you seem to think. Instead we are doing a much simpler thing - we are forking "the code". Of course former is built on latter, but current focus is making codebase usable for other contributors.

The main difference here seems to be that I interpret the need to "write laborious commit message" as a basic human decency that shows I'm respect other people's time. Five minutes on "value types" is not a lot all things considered, but pretty much enough to write the commit message.

This attitude always puzzled me to be honest - you just spent half an hour, maybe more, to write the code and have a good understanding of what you had just done and for which reasons. How hard would it be to sit down and type it out and save time for someone who comes next?

It would be nice if difference of code/features were described in some human readable form. E.g. there were various forks of DosBox which added some other features.

Perusing the Nim discord, it looks like some of the people behind this project were once Nim devs (think maintainers), but this project is also considered unusable and constantly under development. There is also talk about Nim not accepting PRs soon enough, and knowing ahead of finishing your work that your PR will be approved with NimSkull.

I could spend more time looking, but really these are the sort of things that should be in their own readme in plain English instead of leaving me and everyone else who has no context confused.

AFAICT, it's an opinionated refactoring of the core because... Reasons.

The devs might want to consider the lost time, and ultimate impact, of Flickr rewriting its internals for... Similar reasons. Sure, the project may seem unwieldy, but major refractors or rewrites are never worth it.

I can't think of a single grievance fork of an already-unpopular esoteric language that went on to become a serious industry-shifting project.

What's the elevator pitch, is it just social grievance with the Nim developers? Because that's all I get from the readme.

unpopular != not popular

esoteric != novel

Nim is not well known or used a lot in production, but it is neither unpopular nor esoteric.

It's neither in the PYPL nor TIOBE top-20, or even top-50, for popularity.

so what?

> already-unpopular esoteric language

Bold assumptions

It's neither in the PYPL nor TIOBE top-20, or even top-50, for popularity.

Courageous, but seems to be an immature decision and tactic to me. They haven't even figured out a name for the project and chose to instead signal "death to nim".

I interpreted nimskull as self deprecating, IE calling themselves numbskulls.

That is a correct interpretation, we decided some humor won't hurt at the start, and it certainly wasn't as venomous (aka "death to nim") as parent comments suggested

It "wasn't as venomous" .. implies there was some venom, and that you are not being truthful in the first half of your comment, because you actually meant to call Araq a numbskull.

Nim was originally “Nimrod.” It’s probably a play on that.

the legendary hunter in the bible?

More likely Elmer Fudd in more people's imagination

Funny how that worked. Bugs called him Nimrod, a great hunter, sarcastically. Everyone today uses it to mean stupid/inept in any situation.

Akin to one day, Einstein being known mostly as meaning 'idiot' rather than a physicist.

I believe it’s more of American thing to put the opposite meaning into a word.

Universal human trait.

Look up the history of the word "nice" in England, sometime. But no, it is not just an English-speaking phenomenon, either.

Right, irony and sarcasm are universal (afaik). But I had in mind that americans tend to use e.g. “so bad” in a sense of “so good”, which is not so ubiquitous. (I’m only familiar with English, Russian, Deutsch and Tatar really, so my thought is limited to these four.)

One summer when I was at Bloomberg, there was an announcement that some interns had been assigned to implement an internet sarcasm detector, and that they had been completely successful. No one questioned it.

BTW when I told my wife about this, she thought I meant they had been completely successful.

Bugs Bunny is the source of a lot of weird misconceptions.

Example: people think rabbits mostly eat carrots because Bugs Bunny likes to snack on them while leaning on something and saying "What's up, Doc?". Except Bugs doing that was a reference to a movie where Clark Gable... ate carrots while leaning on a fence and calling people Doc.

And somehow a parody of a Clark Gable movie turned into most people believing that carrots are a staple of leporine diets.

> people think rabbits mostly eat carrots because Bugs Bunny likes to snack on them

If that is the case, why is the misconception also widespread in countries where Bugs Bunny wasn't part of the popular culture? E.g. USSR/Russia.

Rabbits do actually love carrots.

It is apparently a temporary name, but yes that's what it read like to me.

I assume it's from "Numbskull".

To me it seems like the people who created the fork may literally not have any known means of judging engineering merit aside from how detailed commit messages are.

If it's a large group then detailed commit messages are critical. If it's likely that between 0-1 people are actually going to read the message in the next month and there are a long list of other plans you have to implement with between 0 and 1 people actually helping you, then the value of more detail in commit messages moves toward the limit of 0.

I don't get the concrete failings of nim from the readme. Even though I have one of my own: They should have adopted a python-style import system and not a C-style omnibus import system. You don't always have a properly configures IDE by your side to resolve imports.

Qualified imports don't work well with uniform call syntax. How would you write "foo-bar".split("-") with full qualification? "foo-bar".(strutils.split)("-") ?

You could have something like

    import strutils{split, trim}

similar to how rust does things.

What would be the problem with that?

Nim does have that:

    from strutils import split, trim

Most people don't use it because it's annoying to constantly add and remove imports when changing your code, but it's definitely an option.

In some languages there is a pipe operator that does the job well. Elixir example:

    "foo-bar" |> String.split("-")

IMO method chaining is a lot better this way, much less desire for monkey patching, etc.

There's no need for monkey patching in Nim. x.f(y) is fully equivalent to f(x,y).

The functional approach requires currying and data-last parameter order, which are both unidiomatic in Nim.

Thanks, TIL! Obviously I have no experience in Nim. This convention reminds me of Perl, which works much the same way.

How is it possible, then, to call a function that lives in a different namespace as part of a dot-chain of methods?

The Elixir approach does not rely on currying; like much of the language's fancy parts, it's a macro.

Nim generally doesn't use namespaces, so… that's how.

I didn't even know Elixir had macros…

Elixir is a homoiconic language with hygienic macros. Macros are a great tool when you need them!

Thank you. That is my single biggest gripe about nim as well.

If you believe, as I do, that code is read more than it is written, then this becomes a big deal.

Clearly readability is important to nim's design so this departure from that seems inconsistent.

Also for new people trying to learn the language, it really helps to be able to see what modules/packages functions come from.

See comment above. Nim does have it. Lol.

> They should have adopted a python-style import system and not a C-style omnibus import system. You don't always have a properly configures IDE by your side to resolve imports.

I've had this issue with Python as well, if you use virtualenv for enough projects, you might just run into it, PyCharm is an amazing IDE but sometimes I have to literally reconfigure it a dozen times because it defaults to this or that, or in the more famous case I had: an API written for Python 2 vs a web service written for Python 3 and it was problematic to switch context because you had to change interpreter for entire project, though debugging the two was no issue. I suppose the more obvious fix would of been for me to open the client library directory in a separate PyCharm IDE instance in retrospect, but my point being, even Python can run into this under niche circumstances.

Nim is still kicking.

https://github.com/nim-lang/RFCs/issues/437

This fork reminds me of the Ayo[1] fork on Nodejs. At least NimSkull actually has some plans/motivation to do work beyond adding an administrative document.

[1]: https://github.com/ayojs/ayo

this is sad. Nim deserves to get a lot more traction than it does now, and a distraction like this will just muddle search results and give a false impression of immaturity. could the forkers express their grievances and the steps they have taken to resolve them before?

This is how they decided to express that. Lol.

Seems a little petty, just because someone's making something you are using for free, doesn't mean you should get to decide on it's direction

They aren't. They are doing the exact opposite. The original version is free to continue as it pleases, free of annoying disruptions.

This process is literally the most fair and least offensive thing possible, and yet people still try to make it some kind of wrongdoing.

If they had tried to alter the original project to suit themselves, you would have said "they can just fork if they don't like it"

So what you're really saying is they should just shut up and like whatever already exists and neither change it to suit themselves, NOR go off and make their own thing. I have some bad news, saying that is about 1000x more offensive than forking something.

There is just not one tiny microscopic shred of validity to this line of thinking.

This is not necessarily a bad thing. Ideas that prove worthy in NimSkull could be incorporated into Nim, if the Nim maintainers decide to do so.

We are certainly not opposed to this, although some of the more fundamental structural changes in the codebase might temporarily hurt the stability - this was one of the friction points with the mainline. While stability is important it was never clear where sound judgment ends and "don't touch this 14+-year-old code transpiled from Pascal" begins. We are almost a year in and among several former contributors we still sometimes have troubles figuring out the logic behind certain decisions. Now imagine doing all the digging and expecting to fight an uphill battle to prove the necessity of the changes. Maybe if we do it in the nimskull then mainline decides to adopt some of the improvements after seeing their real worth.

nim is a nice language. but the lack of consensus amongst small languages is why they never get adopted. and people wonder why stick with c++ ? because c++ comes with a kitchen sink of features and you pick what suits you and never worry about adoption cz it works everywhere

What's the story here?

I read through the wordy description and still feel more confused about why they did this. I also feel like missed the opportunity to call their language "Rod" in reference to Nim's original name Nimrod.

I assume they didn't like something about the maintainer or the community.

Nim has a plan to add incremental compilation, saving the compiler state in files with the .rod extension. So naming a derived language Rod would be confusing.

It's a bunch of people who like working on the compiler, working on the compiler. Nim proper doesn't have as much flexibility to make breaking changes, and this has limited much-needed internal refactoring.

There was a falling out between some developers on the Discord that led to personal attacks and an eventual banning a while back. If I recall, nimskull started shortly after, and has attracted a few other compiler developers since.

There is no singular "story" here, mostly several former contributors decided for one reason or another (of course there are a lot of small "stories" behind this, but writing them all down would just come out as being "disgruntled people" (as already theorized in one of the top comments) to most readers) to spend their own time in a different projects.

the devs missed the boat by not calling it Nimble

They couldn't have. nimble is the primary package manager of nim ecosystem.

Nimble is Nim's build tool so that's already taken.

They missed the boat by not calling it VeoNim

Oh, that's actually a great name. You should suggest it to them.

hah, I like that (:

Or they could go with Nym with the Pho file extension

What is a hard fork (vs a soft fork) in this context?

I don't think this is common nomenclature outside crypto, but if I had to guess the distinguishing factor is that (according to their FAQ) they don't intend to merge upstream changes into the fork. So basically completely separate development histories from this point on.

The hard fork nomenclature has been around in FOSS ecosystem for a long time.

No, the crypto community took this term from the FOSS community, particularly due to how coins that did hard fork are open source (usually) and they did exactly what you stated, not intending to merge upstream changes into the fork.

Oh there you go, thanks I hadn't heard it in FOSS before.

Soft forks are usually created for development & experimentation with the intent to eventually merge back upstream.

A hard fork is intended to diverge and evolve into an independent project.

I assume: a soft fork would have a commitment to interoperability, or a future expectation of merging together again.

Reply on news.ycombinator.com