On another thread @carterza commented that he was unsure of the direction of Nim and unenthusiastic about the effect system and enhancements to it, and that he'd be more interested in half baked features (concepts) being made solid and less used features being deprecated. Multimethods are deprecated, maybe the effect system should follow, if it's a productivity killer.
I share his concerns. I like Nim a lot, but I'm also unsure of its' direction. My interest is Nim as a systems programming language. It would "compete" with C, C++, and Rust. No required tracing GC and no need for a D-like DasBetterC. The ability to interface with existing C++ code is a "killer feature" for me. I also see Nim being used as a high performance scientific computing language; again, competing with C++. IMO, a lot of the effort to make Nim a web development language is pissing in the wind.
What are the plans for Nim? I know incremental compilation is desired, and looking at PRs, I see that solutions for cyclic module dependencies may be in sight. Will we see significant deprecations in Nim 2.0? When is that expected to happen?
Sorry for rambling. I'd prefer not to see Nim play out as D has.
IMO, a lot of the effort to make Nim a web development language is pissing in the wind.
That is an interesting take. I have just started using Nim for web development and really enjoy using it vs. Go.
I don't consider Go a web development language any more than C++ is, so sure, competing with Go for spinning up servers should be in Nim's wheelhouse IMO. I'm glad you prefer Nim to Go for this and I think work to make this better is important. Perhaps if I said "front end development" my intent would have been clearer?
In case you think I'm joking about C++ as a webdev language, take a look at the TechEmpower Web Framework benchmarks. Which language is at the top? Nim should be up there.
To improve the language as a product, you need to be confident in its design. You need to pretend that the plan you have laid out makes the most sense to implement. Nim is different from languages like Rust or Zig in that it doesn't have a clear general plan for the entire language, but rather accumulates unique design choices which increase productivity over time, all over a strong base language. That's the narrative in my head anyway.
While Nim still has the room to play around with design, I think it should. Nim's metaprogramming is one of the biggest productivity improvements I've seen, and it's still not perfect. Features like the effect system are currently pretty useless, but it could help immensely in the long run to improve them and build off what is already there.
I'm personally more interested in how far Nim can go rather than see it become more usable. It being very barely usable is of course bad, but holding out for it to be a professional, spotless product is way less rewarding to me than the ability to experiment with new things. I'm also not dealing with systems programming, which demands perfection more than other fields.
The one thing I disapprove of is waiting around so long hoping that already implemented features will be useful before even considering changing or deprecating them. You will usually already know if they are useful when they are proposed lol, effect system as is isn't really even theoretically useful. Sometimes hesitation like this also leads to mediocre implementations. At least the features aren't enforced, unlike some features in some other languages.
The plan is "IC", plain and simple. It allows us to get rid of "nimsuggest" having to run as a server, improving the "tooling"/IDE story.
It's ok not to be excited about IC but Nim+ORC+IC is my vision and my dream. I don't personally mind forward declarations and the lack of cyclic imports but we'll get a solution for this too.
Would the language be better off with fewer features, the ones I don't personally use? Likely, but I'm a compiler writer so there is an inherent danger of removing the wrong features. So let's say we get 1.8 with IC working, can we remove features for 2.0? Yes, make a proposal, remove code from the compiler and see what breaks and then offer alternative solutions to the packages that broke. These packages probably used feature X for a reason. We should not add more features and we should be scientific in our analysis in what to remove.
I would push back against making any sweeping claims about what Nim is for and what it isn't for. After all Nim is the one language to rule them all :)
It's important to make a distinction between the Nim core devs being spread too thin (because we are trying to implement features for all domains) and the community being empowered to work on whatever they find valuable (the community is unlikely to be spread too thin, people work on what they find interesting and if they are told that Nim isn't for that they'll just leave). The former can certainly be problematic, but what you've said runs the risk of discouraging the latter.
But even aside from that, web development is a very wide domain. Indeed, it goes from the backend to the front end. Nim in fact has historically been targetting the front-end (the JS backend) and @Araq himself has implemented Karax which is a front-end SPA framework for Nim. So I don't think it's fair to even discourage Nim gaining support for doing front-end developement.
So instead of trying to put some sort of restrictions on what Nim is and isn't for, how about we instead focus on making it better for the domains we are passionate about? :)
What is missing for ORC ?
Nothing but bug fixes and as far as I'm aware all major bugs have been fixed.
I just see Nim trending more and more towards some high level language. --gc:none is being removed because it was a "failed experiment" and "ARC" succeeded yet I still have no good way to opt out of manual memory management / write my own custom allocators. Your solutions of override malloc or patch the stdlib aren't good enough...
I understand you're a compiler developer but the rest of the leadership is not and no one is doing Nim any favors by cargo culting bad software and steering the direction towards a different audience than Nim was marketed towards when I joined.
When I joined no one was using Nim for JS and karax didn't even exist yet. Now I see more focus and attention on that front from core devs than on development of tooling / the language itself. I'd say more but I risk a ban by doing so, so for now I'll stop typing.
What do you want? Do you want it "Soft" or "Aggressive"?
If I had my druthers, I'd take a Nim-like pseudocode, with a side by side comparison with Nim CPS on a simple example, and a light explanation of the expected compilation. I'd skip the almost 30 page ICFP paper.
Almost two weeks later, fusion is not tagged (surely it was hard to do), released roadmap does not even mention it, nimble is briefly described as "We hope to be able to ship a new Nimble with the 2.0 release but we are happy to ship it whenever it's ready."
So I think that
I'm really sorry for your bad experience and I hope you'll come back
Pretty much amounts to "I will pretend I care, but I really don't, and this is certainly not something worth mentioning on the readme"
Reply prompted by review on the https://github.com/nim-lang/fusion/pull/16 (I haven't unsubscribed from notifications) - well, looks like it takes about a year to get someone to review stuff. I should've waited more, damn these slow email services.
released roadmap does not even mention it
Fusion is not part of the plan. You want me to make decisions, I make decisions, and then I make the wrong ones. It's inevitable.
nimble is briefly described as...
I could have linked to your RFC yes. Would it change anything? Would you be happy and not complain here? Exactly.