Prolog
I wasn't here for a long time because I felt disapointed by Nim. I'll put it nicely (for you): For a while I used D but finally largely returned to ADA - and D turned out to be a clusterfuck; while as a language it's nice (modulo the braces), practically it was so cumbersome and useless that I gave up on it. Just two examples: code that compiled and worked fine on linux failed with a ridiculous error on FreeBSD (with setting timeout socket option), and their LSP (serve.d) didn't even compile, at least not on FreeBSD. So I returned to ADA because it just works and also has a decent, not bloat-monstrous IDE.
Return to Nim
While I had gotten increasingly unhappy with Nim I didn't forget it and my hopes for it. Recently came across some projects that IMO pretty much begged for being done in Nim. So I returned, installed v2.2.4 - and found myself in the middle of a clusterfuck. One of the culprits: nimlsp. Trying nimble install failed because it couldn't find nimsuggest. Compiling it also failed. The fact that it needs an "emergency brake" at 4 GB RAM doesn't help either. Now, ladies and gentlemen, maybe I'm a pampered spoiled brat, but IMO a properly working and easily buildable LSP is an absolute MUST, especially for not exactly small projects. And the problem IMO isn't just with both the nimble build and compilation failing, nope, it goes deeper and creates an impression of Nim that should be avoided by all means. It actually starts with the question why the hell one needs to nimble it. Why doesn't it come by default with the compiler build? So as to avoid wasting a few MB if someone doesn't want nimlsp? Hardly, after all I had to find out that my standard build took over 2 GB on my disk (due to c_code I think).
Do you guys WANT to make it cumbersome and hard to use Nim?
A few more remarks, related:
Nim doesn't offer 1 but multiple (I almost wrote 'plethora') web servers/server frameworks. I appreciate that, especially after seeing that D pretty much only had 'vibed', a somewhat oldish it seems, on offer which to add insult to injury seems to be not exactly fast. But, sorry to spoil the party, I don't give a flying fuck about many projects, most of them anyway abandoned, half cooked, experimental, etc., if the BASICS arent rock solid and easy to build/get/included! I get it, Nim always is in developement, and that's absolutely a good thing in my books, IF there also always is a stable not too old version available (which seems to be the case). But frankly, e.g. ever changing memory management doesn't inspire trust, especially not with a language outside the mainstream. Don't get me wrong, I appreciate and value A. Rumpf's striving for better, faster, less error prone etc. memory management! But, sorry, I don't want to serve as lab rat, I want a stable versions that is easy to use and provides at least most of the "goodies". And most importantly, if a new version doesn' compile my, say 3 year old, code that begging for a death sentence in my eyes.
Can I please, pretty please, get a working troublefree Nim + environment (e.g. LSP, package tool, etc.)? If yes, I'll stay, if not I'll leave and bite what I consider to be ADA's only major drawback, strings/text, and a bit less comfort than Nim promises.
Sorry for my rant-like thread but I had to get this off my back. Because I remember well liking Nim a lot and having high hopes for it.
Oh, and: I still need a working LSP for Nim, one that actually builds without jumping through weird loops. Please.
My 2 cents:
nimlsp: project from PMunch https://github.com/PMunch/nimlsp
nimlangserver: official Nim Language Server https://github.com/nim-lang/langserver
while I agree that tooling generally doesn't work easily out of the box and it can get worse when applying it on larger projects, there are some sweet spots and it does work if you learn how to tame it. Please consider understanding how lsp work before expecting turn-key solutions.
Peace
Can I please, pretty please, get a working troublefree Nim + environment (e.g. LSP, package tool, etc.)?
Assuming you're not, as you say, a pampered spoiled brat, maybe you'd like to be a part of this happening? Donate and open a priority ticket, https://nim-lang.org/donate.html
Why doesn't it come by default with the compiler build? So as to avoid wasting a few MB if someone doesn't want nimlsp?
nimlsp is a third-party package. There's an "official" langserver but it's not bundled by default because it's just not good enough.
Nim doesn't offer 1 but multiple (I almost wrote 'plethora') web servers/server frameworks.
Like any other language? There's only one server in the standard library. Though, you're probably better off using something more actively developed from the community packages.
But frankly, e.g. ever changing memory management doesn't inspire trust
Nim 2.0 is more than 2 years old and arc/orc were available and actively used long before that. Things hardly changed for the regular users since then.
Regarding the state of the LSP+nimsuggest I don't know the situation exactly but I bet it boils down to lack of resources and people involved in development + probably some required changes to the compiler to support it being done the right way.
When I started running a background loop bumping nimsuggest processes' oom_score my life got much calmer, though it's hardly a great user experience :D
Well, I finally got it to work. By installing a VM and doing the whole shebang again but this time using choosenim (which I dislike for diverse reasons). Then I scp'd it to another box from which finally I scp'd it to my development box.
If I didn't already like Nim and that effort and jumping through weird loops would have been required by any other kind of new to me language I'd have left it - as I did with D for similar reasons.
TL;DR I stand by what I wrote above.
Re. memory management: I get your point - as well as the fact that as lead developer of Nim your point of view hardly is that of "just any user" - and my main worry in that regard boils down to the last years suggesting an expectation ("it'll change again ..."). That said, the current official situation in that regard (arc/orc) is OK.
I understand you're being a bit confrontational to provoke discussion
Nope, that wasn't "confrontational to provoke discussion", it was ranting and venting, but not for myself only. The driving force behind it was disapointment that one of my major hopes, Nim, is in such a state.
nimlsp is a third-party package. There's an "official" langserver but it's not bundled by default because it's just not good enough.
You see, that's basically one of my major points: I do not care. All I see is whether it works easily and well or not, period. Of course a project in development goes through changes and hardly can be 100% OK and working, that's OK. But lots of cruft, half cooked stuffed, more or less dead and/or unusable crap, etc. is not OK. One major reason (although, granted, not re. myself) is this: what's the experience of a new Nim user and I mean one who actually wants and needs to get work done, not someone basically just playing with "hey, another language, cool!".
IMO the border between acceptable and not acceptable is at the very least something like a tag like "tested, fully working", "still alpha/beta" and "don't care just experimenting".
Btw, another important point is docs, a very major weakness of very many foss projects. My point of view has evolved to "no reasonably complete and helpful doc? Keep your crap!" And yes, IMO that is one of the major plus points with "official" Nim. Usually it's reasonably documented. But there is way too much worthless crap that nimble lists/offers as if it were reasonable packages (and no, I don't mean nimlsp by that; it's documentation is far from good quality and complete but it's not crap).
["web servers/server frameworks]" - Like any other language? There's only one server in the standard library. Though, you're probably better off using something more actively developed from the community packages.
Regarding the state of the LSP+nimsuggest I don't know the situation exactly but I bet it boils down to lack of resources and people involved in development + probably some required changes to the compiler to support it being done the right way.
Then I have to say: congrats, you have a half cooked thing in between a toy and a tool here, sorry (and I really am sorry!)
To be fair I'll tell you my reference: does it work with Kate (as opposed to the vscode abomination) and does it meet TODAY's expectations? (e.g. an properly working LSP.).
When I started running a background loop bumping nimsuggest processes' oom_score my life got much calmer, though it's hardly a great user experience :D
Frankly the fact that nimlsp has an "emergency brake" at 4GB RAM due to nimsuggest seeming to be so shoddy, almost frightens me - and yes, IMO it colors off on Nim.
I'll close with something I find important and stating it clearly may help to not get my intentions wrong: When I have a reasonable dev-environment working I really like to develop in Nim. What I said yeasr ago still holds true for me: I think that A. Rumpf created something great, even brilliant (he, not Nim), although today I'd complement that with the question whether he still is guided by Wirth, Meyer, Ichbiah, Dijkstra, I'm not so sure.
Anyway thanks for the discussion and being open-minded enough to recognize that loving something sometimes may show in what seems to be a harsh view.
this time using choosenim (which I dislike for diverse reasons)
You might like grabnim Also, choosenim was known to cause problems with nimsuggest (OOM, too many processes). Not sure if they're all fixed or not.
Switching to grabnim solved 90% of my problems with Nim's LSP.
In my experience Neovim + nimlangserver is pretty stable even on 4GB RAM linux system. And installation is not that bad: "nimble install --useSystemNim nimlangserver", system nim flag is needed to avoid compiling Nim 2.0.8 as a dependency (obv slow).