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?
* _easy_ to use with the major editors (vim, sublime, VSC is the bare
minimum. Possibly others too, eg. emacs)
* _easy_ to use with a gdb GUI (gui in Capitals). Can be a plugin, can be via
Nemiver, etc.
* optionally an IDE would be nice. You should revive Aphoria or similar. Many
look down to "hobbyists" who need an IDE but you shouldn't underestimate the
number of companies where IDEs are used and the generations of developers who
are used to and want an IDE (I'm not one of them but I know many in companies).
All of the above for linux, Windows, apple [their OS] at the minimum.
* good documentation. For me personally I'm OK with what is basically just
nim-doc pages for most things. But I feel that at least the less common and
well known things (like macros!) absolutely need a _good and extensive_
tutorial and documentation.
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.
