I'm new here so I'll first quickly introduce myself. I'm developing software for a living, mostly in the field of IT security, crypto and networking. Having used C for many years, with some not insignificant experience in Ada, Pascal, Python and some more esoteric security centric or formal verification "languages", I was always searching for "my perfect language" - and seem to have largely found it in Nim, albeit with with some buts (after trying many ranging from C++ (yuck) to some functional languages and D, Go, ...).
I might be wrong but it seems to me that the Nim team is quite concerned with the question why professional developers and companies use or don't use Nim and on the other hand I'm quite concerned too. After all, the language I use is of high importance to me (and certainly others too). Hence this thread.
Frankly, I was a bit unhappy with how the survey was handled. Not only took it an eternity to get the results but those were - at least from my point of view - sometimes quite superficial and occasionally even misleading. Example in question: Visualstudio Code which strongly grew over the year and is clearly leading. Hurray. Or not? I hate Visualstudio Code. It has lots of quirks, it's an insanely large monstrosity, it often quite retardedly autocompletes, etc. Yet I use it. Why? Because I'm forced to; at least it seems like that to me. Reason: I'm not interested in editor wars (vim or emacs) nor am I interested in becoming an editor wizard (e.g. knowing all key combinations of vim). And I NEED A DEBUGGER. Granted, I'm amazed how rarely I really need a debugger with Nim (as opposed to e.g. C) but still I need a debugger. If there is no debugger for any given language I don't even use it and take it be a toy, simple as that. And the only way I found so far to get someting like a debugger with a GUI working with Nim is VSC plus some plugin. It's ugly and quirky but it kind of works.
So, to call out VSC as the happy winner seems akin to asserting that Breshniev was an excellent leader whom the Russians loved because he got 99% of the votes.
In that context I should also mention that I'm one of those guys who actually downloaded and tried Aphoria. And I also noted @Araq using some Nim editor (of his own?) in a presentation but I failed to get at that editor and to get it properly working.
Ladies and gentlemen that is a quite poor status quo for Nim. About the only way to use it in a halfway decent way is giving in to the VSC rape (sorry, that's how I perceive it. Take it as a compliment. I like Nim so much that I was willing to install and use that VSC monster).
No matter how nice the language is; if you want considerable uptake in professional contexts one extremely decisive point is practical USABILITY. In capitals. Unlike hobby hackers a professional programmer can't (and usually won't) spend lots of effort and time just to be able to actually use a language. And "real world usability" is also my title for a whole group of problems that plague Nim.
What is needed?
All of the above for linux, Windows, apple [their OS] at the minimum.
My other problem with Nim is (I might be wrong; it might just be a subjective and misguided impression) that the core team seems to care an awful lot about ever new gadgets rather than about getting a stable solid basis. That basis doesn't need to be (called) 1.0; it can be 0.20 ... 0.21 ... and there can be some changes, preferably in the form of new things rather than wildly changed existing things - but it should be reasonably stable and solid.
Now to my personal and honest responses:
Do you use Nim? - Yes. Actually I use it even professionally. In the beginning I was quite mistrusting but I found Nim to be pleasantly good and reliable (modulo experimental and some bleeding edge or exotic stuff. But that's OK)
How could we help make Nim more accepted at your company? - See above, plus: Right now, no chance. My colleagues just grin. Gladly I'm in a position to do what I like (as long as the results come and are of good quality). Sidenote: I can't quite follow the "we need v. 1.0!!!" argument; seems "corporation" minded and I do not see any real benefit in just calling, say Nim 0.20 "Nim 1.0" but obviously that would make many quite happy.
What editor(s) do you use when writing Nim? - I use VSC - because I'm basically forced to. But I would very, very, strongly prefer sublime.
What is your experience with the following tools? - They seem to work. I'm (as a personal taste thing) not too concerned but I like Nimble.
How did you most recently install Nim? - github ... build. Old school.
Top reasons why programmers stopped using Nim - not even almost. if at any point I had stopped it would have been over the editor and debugger issue. But I didn't - for good reasons (see more below). TL;DR Nim is so good that it's worth some pain.
Top reasons why programmers are not using Nim - From what I see in companies: see above.
Do you feel well informed in the direction that the Nim project is heading? - No. For mainly 2 reasons, (a) too much info too spread all over the place, and (b) I don't care that much, I trust Araq; he has provided enough reasons over the years to trust him.
Should Nim 1.0 have been released already? - Personal answer: I don't care at all. General answer: Probably. There are many out there, particularly in companies who think more "formally".
What improvements are needed before Nim v1.0 can be released? - Docs (incl. tutorials), tools (editor, debugger, optionally IDE), stability, both as in "reliability" and as in "stable state" (to which is added but which is hardly ever changed in not insignificant ways). A mixed model comes to mind. One stable branch and a dev. branch the letter being switched/copied to new stable only after extensive testing.
Finally I'll add some points and thoughts why I LOVE Nim:
To understand my line one must understand and consider where I come from: I'm obsessed with safety and security - which also is the main reason I left C. And I'm not just obsessed, I'm also dead serious about it. For me that issue is not about blabla, mode du jour ("design by [insert this weeks "wisdom"]). A language, for example, without a strong static typed type system isn't even worth a look in my minds eye. And I can say based on quite some experience, both academically and professionally and pain suffered, that Araq made a very smart set of decisions. He understood and picked up just the right mix from different languages (only exception imo: he should also have picked up Wirth's ':=' assignment operator). Plus, unlike many smart people in academia Araq also understood something else: Whatever good and safe and secure and whatnot language you design, it also must be easily and comfortably usable (many programmers are lazy). In fact, one of Nims real powers is in the fact that the strength of the language does not get in ones way (e.g. Ada, sigh) but actually helps the developer and is comfortable to use.
There seem to be quite many complaining about Nim not having enough "standard" libraries. I disagree. For one Nim has a nice set of the usual stuff, but (imo by far more important) Nim makes it easy to bind or port C libraries. I know what I talk about because I had to bind or in some cases just rewrite (in Nim) some stuff, mostly crypto libraries. It's not (yet) well enough documented and I had to spend a lot of efforts and time to get all the relevant info together but once you master it, it's a breeze.
Another set that Nim has got just right is threads and async. Once more Araq chose perfectly well and smartly by picking up the await model. Compare that to Ada which has excellent multithreading facilities but when async was desired some of the Adacore developers who thought about binding libuv pretty much gave up (it seemed to me. afaik it's still not finished and possibly even just dropped). And it would have been a pita to use anyway.
I have looked at quite some alternatives (before Nim). To name just a few, D is a weird zoo (imo) and anyway just yet another "a better C(++)" approach. Regarding Rust I better just politely stay mum other than mentioning that it too is but yet another "a better C(++)" approach. Regarding Go I'd like to praise the channels (which Araq correctly identified as very desirable and picked them up) but Go is not up to par, sorry. TL;DR there is no competitor. Yes, some (more or less) new languages have more uptake or are more well known and trendy or ... but when summing up what really counts there is but Nim that has it all and does it well. My search has come an end. I have found my perfect language.
Thank you for taking the time to write this long, constructive article with an ending that makes me proud. :-)
The GDB integration is ongoing and works quite well, of course integrating the harsh GDB command line interface into an editor is even more work. At one point I tried to patch "LLDB" instead, but that is an interesting "experience" too.
Regarding editor support, we strive to support VS-Code, Sublime, Emacs, Vim well, not only with nimsuggest but also investing into their Nim plugins, so if your favourite editor is among these, the chances are high Nim will improve on that front.
The editor that you have been looking for is https://github.com/araq/nimedit. It is not dead yet, but before somebody patches its font rendering not even his father can love it. Apart from that it is a nice opinioned editor that is written in Nim and scriptable with NimScript, so at least contributors don't have to mess with TypeScript (VSCode), Python (sublime, Vim) or Lisp (Emacs).
I'm glad to learn that I could contribute to making you - deservedly - proud, @Araq.
Thanks for the link to your editor. Unfortunately this leads me to a point that is sad for me: I can hardly help. I simply don't know anywhere near enough about fonts and GUIs. Similar wrt GDB. My capabilities are nothing to be ashamed of but they are quite limited in scope (you want a nice prng or some crypto (native or ported); we can talk about that).
To avoid the wrong impression of me simply slime crouching towards you: I had heard of Nim first when it was still called Nimrod and from time to time had a quick look. The moment that piqued my interest was when I saw you mentioning something about not being able to verify something related to some type-related discussion. "Verifying?" I thought, that guy seriously is concerned about actually verifying types (assertions, ...)? It was then when I started to look closer at Nim, to read some discussions and to more frequently look at what's happening at/with Nim.
Another point I like(d) very much is your almost brutally pragmatic approach, always with real world developers in mind. Most others (Rust .. cough) grossly misjudge and underestimate the "keep it simple!" rule. In fact, it's proven again and again that one of the major C bug culprits is something as mundane as readability.
There are other languages that do some things right but only Nim does all of them right (looking from a safety, reliability, security fanatic perspective) -and- offers all the needed mechanisms (threads, async, ...) and in a really practical and well usable way. The one thing I missed came when of the Nim contributors created the "contracts" module (A big thank you to him).
Some (more or less urging) suggestions:
Thanks again both for creating Nim and for being a productive, wise, and energetic king of Nimland ;)
While Visual Studio Code certainly isn't the best editor in the world, there are still enough reasons why a thin majority of the Nim users(according to the survey) uses it, other than because everyone else does.
The IDE part is true. VSC is horrible when it comes to intellisense and auto complete.
You can't blame VSC in most cases for inaccurate or slow suggestions and linting because VSC (or to be more accurate the Nim VSC plugin) does nothing more than serving nimsuggests results. I think here's a rather huge knowledge gap, according to the survey the majority said that they never used nimsuggest, which I deem to be very unlikely.
And if we are coding a project which contains, say, 20 modules. And we always want to run one nim file. (say, mainFile.nim) But in VSC, we need to activate that tab and then press run every time.
You can define a task build and/or a test task, which you can run with a single hotkey: https://code.visualstudio.com/docs/editor/tasks
Thanks for the link. Yes, i missed it. But i got these details from other sources. Or do i miss this in documentation ?
# if x = untyped body in a macro which used as a pragma, then
x.name # proc name
x.params # proc parameters.
# you can loop through like this
for i, p in x.params :
if i > 0 :
p[0] # is param name
p[1] # is param type
one solution, which probably has been brought up numorous time, would be to implement the language server protocol.
Absolutely right, LSP would be THE solution because all the major IDEs/editors mentioned here either support it or are about to. Status apparently already has the the technical ground work laid. I had really hoped that the first sponsored project coming from the Status-Nim-coop would be LSP support (or typeclass consolidation, i.e. generics and concepts).
Its ok, Do i need to delete my comments ?
Create a new thread and delete your comments here or take the lesson for the next time and do nothing.
To avoid misunderstandings: I spoke about my personal perception wrt VSC (but included it nevertheless in my "most important editors" list.
My point isn't about VSC and certainly not about yet another editor war. My point is about Nim. Having become a heavy Nim user (and fan) I look at any editor with Nim in mind.
As I mentioned practical usability is a very major factor for a young language. That also means that Nim must have good support for (be supported by) at least the major editors. Developers using Vim, Sublime, [other major dev. editors] -will- look whether Nim is well usable with their editor. The lack of an IDE might be forgiven but editors are among the very core tools of developers and many will even hesitate to switch to a language without support for "their" editor.
VSC is a big fat thing; I don't say that to belittle it, I might just as well say that Vim (for many) is a six legged creepy horror editor. The point is that whatever happen to be the major editors (for whatever reasons) MUST have Nim support available - or else quite many people won't use Nim or leave it again soon. And indeed there are quite many leaving Nim again; some of course just had a peek at it anyway but others are more serious and found - not Nim, the language but working with it - unattractive, uncomfortable, etc. I happen to have been one of them re. some young languages and I would in fact have put Nim aside too for the editor (and debugger) reason if Nim had been a little less convincingly great.
We should apply Araq's pragmatic view and see what someone who is looking at Nim actually sees.
He already has his favourite editor. It's not the editor that is the newbie in his world, it's Nim and hence it's Nim that's (subconsciously) expected to adapt. On Nims side he has some starter tutorials, some articles (one of which might have led him to Nim) some curiosity and probably some mistrust too.
I think it's really decisive what that potential new Nim developers first experience is. Is it easy, can he concentrate on the new language and easily play around? (one big plus of Nim: getting the thing itself installed is easy and comfortable). Or does he have to first install this or that specific editor (to reasonably work, have syntax highlighting, etc) or even to build a patched special version of some compiler or gdb or whatnot (yes, there are languages like that. Seriously)? And keep in mind that that Nim newbie does not yet fully see all Nim gives him; for him Nim probably is just another new language (many of which are indeed not worth a lot of effort).
The other classical entry is what I'd call group power. Java, C or C# are good examples. "Everybody uses XYZ!", "In our company we develop in XYZ", "A serious server is written in XYZ" give the language a strong advantage, up to the point that the user is usually willing to adapt both himself and his tools. Having done some work in Nim and having seen its beauty and strengths and value are somewhat similar. That's why for example I myself (curse and) use VSC. Nim is worth it, simple as that. But that is not the situation of most people who just are looking at Nim the new language.
Looking at the real world it seems Vim, sublime and VSC are the most important editors, so we need support for Nim in those as a bare minimum. Not having that will continue to make it harder to gain traction.
That's why I brought up the idea to support the development by small payments (couple of hundred $) of such (and other) vital things. There are people who are capable and willing in our community; that's why we have what we have now. Maybe a friendly small push and some small monetary support could motivate them to enhance their Nim supporting tools and to include better gdb support and other important things.
If we achieve that for Vim and sublime we very much gain in attractivity in very, very large developer groups (with millions of developers each). Simple as that. Plus we get more easily digestible for many companies (most of which strongly shy away from changing their tools).