nim-lang
Deprecate Fusion
Abstract
Deprecate Fusion as "Official" part of stdlib, remove Fusion from official documentation sidebar, whatever misc change is needed too.
Motivation
Always open to new ideas about how to evolve the Nim stdlib.
Description
Fusion is abandoned with >1 year without any relevant commits, Fusion is in the official documentation sidebar for the users, it is not really maintained, nor improved in any way at all, it lacks the proper CI and unittests that Nim itself has, theres open pending abandoned bugs and pull requests since years ago, it lacks very basic features like a version number since years ago, it is a very poor first impresion of Nim for new users and companies, the Nim v2.0 is a good opportunity to deprecate the abandoned stuff, it failed to gain its own traction and should go the way of the dodo...
Code Examples
No response
Backwards Compatibility
No backwards compatibility problems AFAIK.
Isn't the solution to bring fusion up to date and improve quality rather than "give up"?
Why was fusion needed at all? Wouldn't it have been easier to maintain the libraries separately?
In the case of boost, it was convenient to dump everything into one large library, because C++ has terrible build system. But Nim has no such problem.
Why was fusion needed at all? Wouldn't it have been easier to maintain the libraries separately?
As a staging ground for libraries that might integrate the stdlib.
See also: https://github.com/nim-lang/RFCs/issues/310
Maybe we can move the modules in fusion to their separate repos then make fusion a nimble package that depends on all of them. i.e.
# fusion.nimble
requires "matching"
requires "smartptrs"
...
Sorry I don't know too much about fusion.
Maybe we can move the modules in fusion to their separate repos then make fusion a nimble package that depends on all of them. i.e.
Sure, making module independent between them allows for more flexibility but that won't solve the issue of fusion being left to perish (when there's some good stuff in there)
I think modules will have activity as long as people use them. The issue with fusion seems to be largely with visibiliity, or people just don't know how to install it. Does it ship with Nim? Which versions of Nim does it ship with? Do you need to require "fusion" to use fusion modules? I doubt fusion was even included in a changelog or blog post.
As long as Nim deems modules "official" or "recommended" or advertises them (even if they're not developed by Nim devs) I think they will be used. Ambiguity just makes things worse.
rather than "give up"?
No one is giving up, we say we need to continue thinking new ways to evolve the stdlib.
The idea of fusion might not have been executed well but I agree the modules in it are definitely worth preserving with at least the same degree of respect as intended. The situation with matching was such an easily resolvable mistake in my opinion. We can't afford to not compromise on anything.
Just read into the listed issues carefully - this is a textbook example of "nobody gives a shit about the project" - >1 year without commits, unfixed issues, no documentation updates, not enough tests, barely tagged for new versions - this is a dead project, plain and simple. No amount of repository shuffling will make anyone care more.
Isn't the solution to bring fusion up to date and improve quality rather than "give up"?
It was the idea ... about 1.5~2 years go, since then nothing happened, so ...
it was convenient to dump everything into one large library, because C++ has terrible build system. But Nim has no such problem.
Still have to install packages, though. The aim was to provide some "extra batteries" out of the box, like pattern matching, ordered associative containers, smart pointers and some other things.
Maybe we can move the modules in fusion to their separate repos then make fusion a nimble package that depends on all of them. i.e.
The main issue with fusion is that there is no maintainer, nobody cares about it, so splitting it will just rearrange the problem a bit differently - and most likely only exacerbate them, since they are unrelated to how files/repositories are organized in any way.
The situation with
matchingwas such an easily resolvable mistake in my opinion
It wasn't even a mistake per se, it's just how things are fundamentally managed with fusion - I moved my library into a separate module as the previous quote suggested, and it happily stays there, not bothering anyone [1]. Other modules did not have anyone who cared enough to even handle the transition like this, so they are staying in a dormant state indefinitely. They are either good enough (and for some modules it is the case) and don't need any changes, or there is nobody who would be willing to work on any improvements.
[1] I could have continued working on it with the same energy, in theory, but of course after all of this I had a kind of "meh" attitude towards doing this.
The main issue with fusion is that there is no maintainer, nobody cares about it, so splitting it will just rearrange the problem a bit differently
Splitting it allows each module to be maintained differently, by any amount of people. What I see as important is getting the modules used enough that they can be actively maintained. If Nim advertises certain modules, those modules will get used, getting used will make those modules better over time.
Installing packages isn't a problem either. Fusion can be a generated collection of specific approved versions of certain packages that comes with some Nim installations. Those modules can get developed and release new versions for people to use, and fusion is still "static" or whatever.
The single biggest problem in my opinion isn't the lack of maintenance, it's the lack of advertising. I guarantee >70% of Nim users have never heard of fusion. If people did know about it and used it, maybe it still wouldn't be maintained, but it would be less dead.
Edit: Sorry I'm actually not that invested in this, I might be missing context. It just seems like there are really simple solutions to me.
Lack of advertisement/contributors etc. are effectively symptoms. The bottom line is - if the core team does not care about any of that, you can't make them care, it's as simple as that.
If someone wants to fix the issue, the best thing they can do is write an article on the website, or series of tutorials on the library, or something along those lines. Raising awareness about an existing issue is nice, but historical evidence suggests it will amount to nothing.
I would be happy to be proven wrong, but at this point I just want to avoid illusions about what can and cannot be done with fusion via RFCs/requests etc.
Fwiw I use fusion/astdsl all the time and there is nothing I wish to be added or fixed, it's just done. Is it going to be added in the stdlib? Or moved in a separate package? Please let me know, for the latter I would like to be the maintainer.
Also fusion/smartptrs is superseeded by threading/smartptrs. Another repo we need to discuss if it's abandoned or not.
My stance on fusion is that it should all be separate repositories - I don't mind them being under the nim-lang organization (much) but I don't see the point in having them be all in one package.
Fwiw I use fusion/astdsl all the time and there is nothing I wish to be added or fixed, it's just done.
This is the case for a lot of libraries. As in, this is just something that fusion requires, libraries like this don't necessarily benefit from being in fusion.
Is it going to be added in the stdlib?
I would guess almost definitely not, as stated before being in the stdlib is usually a detriment to productivity.
Or moved in a separate package? Please let me know, for the latter I would like to be the maintainer.
You should be able to make your own package for it even now. This shouldn't be a problem if fusion is supposed to be "static". In fact I would implore you to do this as you seem to basically be the only author. It can be moved to nim-lang later, but even this doesn't have to be done to ship it with whatever fusion becomes in the future.
My stance on fusion is that it should all be separate repositories
I would support this as the main RFC. Separate packages for each module, then maybe ship a collection of handpicked versions of certain packages as a replacement for fusion.
@planetis-m If you feel that a fusion module (or any other module) is complete, stable, and appropriate enough to add to the standard library, write up an RFC for it.
The RFC would need to:
- Justify the module's inclusion into the standard library.
- Explain the motivation for the module's API design.