10 ms·

NimSkull: A Hard Fork of Nim

77 points by cercatrova 4y ago

polotics 4y ago
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?
- ilaksh 4y ago
  This is how they decided to express that. Lol.
ch4s3 4y ago
What's the story here?
- giancarlostoro 4y ago
  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.
  - xigoi 4y ago
    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.
- frigid 4y ago
  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.
- haxscramper 4y ago
  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.
andsoitis 4y ago
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".
- Brian_K_White 4y ago
  I interpreted nimskull as self deprecating, IE calling themselves numbskulls.
  - haxscramper 4y ago
    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
    - ilaksh 4y ago
      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.
- boardwaalk 4y ago
  Nim was originally “Nimrod.” It’s probably a play on that.
  - cultofmetatron 4y ago
    the legendary hunter in the bible?
    - googlryas 4y ago
      More likely Elmer Fudd in more people's imagination
      - 4y ago
giancarlostoro 4y ago
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.
- dleslie 4y ago
  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.
StevePerkins 4y ago
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.
- elcritch 4y ago
  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.
- CJefferson 4y ago
  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.
  - HelloNurse 4y ago
    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.
- rootlocus 4y ago
  https://github.com/ayojs/ayo https://github.com/ayojs/ayo comes to mind.
dleslie 4y ago
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.
- sph 4y ago
  unpopular != not popular esoteric != novel Nim is not well known or used a lot in production, but it is neither unpopular nor esoteric.
  - dleslie 4y ago
    It's neither in the PYPL nor TIOBE top-20, or even top-50, for popularity.
    - Brian_K_White 4y ago
      so what?
      - deleted 4y ago
        [deleted]
- kamikazechaser 4y ago
  > already-unpopular esoteric language Bold assumptions
  - dleslie 4y ago
    It's neither in the PYPL nor TIOBE top-20, or even top-50, for popularity.
Sujeto 4y ago
Nim is still kicking. https://github.com/nim-lang/RFCs/issues/437 https://github.com/nim-lang/RFCs/issues/437
labrador 4y ago
the devs missed the boat by not calling it Nimble
- lf-non 4y ago
  They couldn't have. nimble is the primary package manager of nim ecosystem.
- deleted 4y ago
  [deleted]
- Spiritus 4y ago
  Nimble is Nim's build tool so that's already taken.
- imron 4y ago
  They missed the boat by not calling it VeoNim
  - xigoi 4y ago
    Oh, that's actually a great name. You should suggest it to them.
  - zem 4y ago
    hah, I like that (:
- smabie 4y ago
  Or they could go with Nym with the Pho file extension
yewenjie 4y ago
What is a hard fork (vs a soft fork) in this context?
- lf-non 4y ago
  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.
- catach 4y ago
  I assume: a soft fork would have a commitment to interoperability, or a future expectation of merging together again.
- mindwok 4y ago
  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.
  - lf-non 4y ago
    The hard fork nomenclature has been around in FOSS ecosystem for a long time.
  - cercatrova 4y ago
    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.
    - mindwok 4y ago
      Oh there you go, thanks I hadn't heard it in FOSS before.
jasfi 4y ago
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.
- haxscramper 4y ago
  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.
haxscramper 4y ago
!: 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-985981194 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 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.
- dmos62 4y ago
  > unraveling mysteries of the commit messages that were written with this attitude https://github.com/nim-lang/Nim/pull/19211#issuecomment-9859 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.
  - haxscramper 4y ago
    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.
  - benibela 4y ago
    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 https://github.com/BeRo1985/pasvulkan/commits/master
pull_my_finger 4y ago
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 https://github.com/ayojs/ayo
ThouYS 4y ago
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.
- xigoi 4y ago
  Qualified imports don't work well with uniform call syntax. How would you write "foo-bar".split("-") with full qualification? "foo-bar".(strutils.split)("-") ?
  - snthpy 4y ago
    You could have something like import strutils{split, trim} similar to how rust does things. What would be the problem with that?
    - xigoi 4y ago
      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.
  - gamache 4y ago
    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.
    - xigoi 4y ago
      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.
      - 4y ago
greybox 4y ago
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
- Brian_K_White 4y ago
  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.
dzonga 4y ago
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

77 points by cercatrova 4y ago

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?

ilaksh 4y ago
This is how they decided to express that. Lol.

ch4s3 4y ago

What's the story here?

giancarlostoro 4y ago
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.
- xigoi 4y ago
  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.
frigid 4y ago
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.
haxscramper 4y ago
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.

andsoitis 4y ago

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".

Brian_K_White 4y ago
I interpreted nimskull as self deprecating, IE calling themselves numbskulls.
- haxscramper 4y ago
  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
  - ilaksh 4y ago
    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.
boardwaalk 4y ago
Nim was originally “Nimrod.” It’s probably a play on that.
- cultofmetatron 4y ago
  the legendary hunter in the bible?
  - googlryas 4y ago
    More likely Elmer Fudd in more people's imagination
    - 4y ago

giancarlostoro 4y ago

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.

dleslie 4y ago
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.

StevePerkins 4y ago

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.

elcritch 4y ago
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.
CJefferson 4y ago
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.
- HelloNurse 4y ago
  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.
rootlocus 4y ago
https://github.com/ayojs/ayo https://github.com/ayojs/ayo comes to mind.

dleslie 4y ago

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.

sph 4y ago
unpopular != not popular esoteric != novel Nim is not well known or used a lot in production, but it is neither unpopular nor esoteric.
- dleslie 4y ago
  It's neither in the PYPL nor TIOBE top-20, or even top-50, for popularity.
  - Brian_K_White 4y ago
    so what?
    - deleted 4y ago
      [deleted]
kamikazechaser 4y ago
> already-unpopular esoteric language Bold assumptions
- dleslie 4y ago
  It's neither in the PYPL nor TIOBE top-20, or even top-50, for popularity.

Sujeto 4y ago

Nim is still kicking. https://github.com/nim-lang/RFCs/issues/437 https://github.com/nim-lang/RFCs/issues/437

labrador 4y ago

the devs missed the boat by not calling it Nimble

lf-non 4y ago
They couldn't have. nimble is the primary package manager of nim ecosystem.
deleted 4y ago
[deleted]
Spiritus 4y ago
Nimble is Nim's build tool so that's already taken.
imron 4y ago
They missed the boat by not calling it VeoNim
- xigoi 4y ago
  Oh, that's actually a great name. You should suggest it to them.
- zem 4y ago
  hah, I like that (:
smabie 4y ago
Or they could go with Nym with the Pho file extension

yewenjie 4y ago

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

lf-non 4y ago
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.
catach 4y ago
I assume: a soft fork would have a commitment to interoperability, or a future expectation of merging together again.
mindwok 4y ago
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.
- lf-non 4y ago
  The hard fork nomenclature has been around in FOSS ecosystem for a long time.
- cercatrova 4y ago
  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.
  - mindwok 4y ago
    Oh there you go, thanks I hadn't heard it in FOSS before.

jasfi 4y ago

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.

haxscramper 4y ago
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.

haxscramper 4y ago

!: 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-985981194 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 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.

dmos62 4y ago
> unraveling mysteries of the commit messages that were written with this attitude https://github.com/nim-lang/Nim/pull/19211#issuecomment-9859 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.
- haxscramper 4y ago
  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.
- benibela 4y ago
  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 https://github.com/BeRo1985/pasvulkan/commits/master

pull_my_finger 4y ago

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 https://github.com/ayojs/ayo

ThouYS 4y ago

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.

xigoi 4y ago
Qualified imports don't work well with uniform call syntax. How would you write "foo-bar".split("-") with full qualification? "foo-bar".(strutils.split)("-") ?
- snthpy 4y ago
  You could have something like import strutils{split, trim} similar to how rust does things. What would be the problem with that?
  - xigoi 4y ago
    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.
- gamache 4y ago
  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.
  - xigoi 4y ago
    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.
    - 4y ago

greybox 4y ago

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

Brian_K_White 4y ago
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.

dzonga 4y ago

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