
Nim Community Survey 2019 Results - open-source-ux
https://nim-lang.org/blog/2020/02/18/community-survey-results-2019.html
======
mindv0rtex
Funny, today's when I finally decided to start learning Nim. I do C++ with
CUDA and Python on top for work. Having looked at the Arraymancer lib, I
became interested in the language. Between its outstanding meta programming
features and its ability to be compiled to C++, I think it is perfect for the
scientific computing domain.

~~~
logicchains
Thanks for pointing it out, that library looks quite interesting. A question:
it mentions it "Supports tensors of up to 6 dimensions.". Sadly some of us
have to deal with tensors of even more dimensions sometimes. Does Nim support
some kind of equivalent to C++'s variadic templates that would allow creating
tensors with an arbitrary number of dimensions?

~~~
mratsim
Author here:

Actually it's 7 [1]

But in my future backend revamp I plan to make the default 6 [2]

Note that the line can easily be updated to

    
    
        const MAXRANK* {.intdefine.} = 6
    

as in the planned revamp and then you would be able to change the MAXRANK with
a compile parameter

    
    
        nim c -d:MAXRANK=16 path/to/my/app
    

[1]:
[https://github.com/mratsim/Arraymancer/blob/6fddfa9a734ac01c...](https://github.com/mratsim/Arraymancer/blob/6fddfa9a734ac01c13a9595adccaac571aa75093/src/tensor/backend/global_config.nim#L22)

[2]:
[https://github.com/numforge/laser/blob/d1e6ae6106564bfb350d4...](https://github.com/numforge/laser/blob/d1e6ae6106564bfb350d4e566261df97dbb578b3/laser/dynamic_stack_arrays.nim#L6)

------
lasagnaphil
Nim would be really competitive in the gamedev/graphics field if there was a
standard library that you can use without the GC. (Technically you can turn
off the GC entirely, but you can’t use the current standard library without
it.) The language’s especially good for gamedev because of its extensive
metaprogramming facilities, a sane build system (which lets you write build
scripts with a subset of Nim itself), and the fact that you can load C/C++
libraries with ease.

~~~
pjmlp
Unreal and Unity appear to be quite competitive with GC.

I love Tim Sweeney quotes:

"Programming languages without garbage collection send us down a long path of
design decisions that lead to slow compile times and fragile runtime
performance cliffs."

[https://twitter.com/timsweeneyepic/status/122367043109542707...](https://twitter.com/timsweeneyepic/status/1223670431095427072)

"It's interesting that many games can afford a constant 10x interpretation
overhead for scripts, but not a spikey 1% for garbage collection."

[https://twitter.com/timsweeneyepic/status/880607734588211200](https://twitter.com/timsweeneyepic/status/880607734588211200)

~~~
jstimpfle
Except, especially regarding the former tweet, I get the impression that he's
having a pipe dream (with all respect), and he's heavily criticized. Did he
actually program anything serious recently? He seems to be mostly tweeting
about languages instead of actual technology.

Honestly I can't make sense of what he's saying there, so there's a chance I'm
not getting an important detail, but GC has nothing to do with function
specialization. What does the following even mean?

> Without garbage collection, offering an array of bytes where an array of
> integers is required requires stack-allocating an array of integers and
> converting each byte to an integer every time a subtype is used in place of
> an actual type. This is so absurd that it’s not done.

The only interpretation of this that I can come up with would be just
factually wrong.

~~~
pjmlp
Except that ignores the small detail that his company is selling a game engine
with heavy use of GC, via Blueprints and C++ classes marked as UOBJECT.

I bet he understands one or two things about shipping games with such engine.

The sense I get from those tweets are the usual anti-GC discussions, mostly by
folks that usually are even against modern C++ (as recently seen on some C++20
related discussions), which eventually derailed the discussion into something
else.

~~~
jstimpfle
> Except that ignores the small detail that his company is selling a game
> engine with heavy use of GC, via Blueprints and C++ classes marked as
> UOBJECT.

Yes I've heard that there are some high-level things and _some_ amount of GC
in there. And I'd wager that this is about where _your_ knowledge about UE
ends as well. If that is so, better don't make bold statements like "heavy use
of GC".

And Mr. Sweeny is obviously not only accomplished, but extremely sharp. But
being sharp doesn't protect anybody from buying into stupid ideologies without
any actual real world validation.

Just as it doesn't protect HN trolls from collecting little factual nuggets
from the internet and then spreading misinterpretations (i.e. falsehoods)
hundreds of times. For example, the kind of "Data oriented design" that has
been all the rage recently is so definitely no concession to OOP.

Regarding Mr. Sweeney, the German Wikipedia page for example states that he
didn't have any significant programming involvement anymore since Unreal
Engine 3 (which was released in ~2006; Unreal Engine 2 was released in ~2002).
Regarding programming, all I've read from him on twitter was just language
related stuff, frequently mentioning theoretical blah-blah, such as
covariance, monads, higher-kinded, blah-blah, and oh it is sooo practically
relevant that C function pointer syntax is unusable if you want to return
pointers to functions that return pointers to functions that return pointers
to functions...

> The sense I get from those tweets are the usual anti-GC discussions

I suggest trying to make sense of his actual statements in the first place.
Any offering from your side is very welcome! Again, I'll collect all the
arrogance that I have in me, to criticize this man, who is obviously much
sharper than myself, of blathering in this tweet a load of BS that hasn't
undergone real world validation.

Again, I might be missing the valid interpretation of what he's saying, but to
me all evidence points to him needing a little refresher regarding the real
world, in practice.

~~~
pjmlp
Any C++ developer worth their salt is perfectly able to understand that blah-
blah.

~~~
jstimpfle
You know, I once learned category theory, at least to the point where I could
explain from the ground up what a monad is, as well.

And the most important thing I've learned in the process is that these
theoretical buzzwords don't have any relevance to programming whatsoever. This
theory stuff is not a means to an end. It's a means unto itself.

> My answer to this is: the ultimate type system is constructive logic
> (following the proofs-as-programs direction), the ultimate typechecker is a
> theorem prover, and theorem proving technology improves over time.
> [https://twitter.com/TimSweeneyEpic/status/123141241308757196...](https://twitter.com/TimSweeneyEpic/status/1231412413087571968)

People who say such things have simply drunken the kool-aid, big time. When
it's about practice instead of theory, I prefer to listen to people who have
actually made stuff in the last decade.

------
awb
25% reported having never used the language. Surprising that so many people
outside the Nim development community would fill out this survey.

~~~
codexon
I used it a few times before but I stopped once I realized it was a long way
off from being worth using.

The lack of tooling, libraries, and numerous compiler bugs meant that it would
be easier for me to write the same thing in C++ even though nim is a superior
language.

I'd imagine many people came to realize this before even trying it out.

~~~
gameswithgo
how long ago? I tried it maybe 3 years ago or so, and also ran into a lot of
compiler bugs, which I reported. The good news is I saw all of them get fixed!
Haven't tried the language since it hit 1.0 recently.

~~~
codexon
I don't remember, I tried it out a little before it was renamed from Nimrod I
think.

~~~
stolen_biscuit
I don't think you should be commenting about the current state of the
programming language (which is how your first comment comes across) if you
haven't used it in over 6 years.

~~~
codexon
I tried it a few times after that and it still seemed like it was many years
away from being competitive with C++/Java/Go

------
jarredkenny
Very happy to see Nim gaining some adoption. I started using Nim about a year
ago and could not be happier with the language.

I do wonder what it might take to take Nim towards "main stream" status.

~~~
ac29
I think it needs a "killer library". The core language is pretty easy to learn
if you've used Python, but there aren't a ton of third party libraries, and
the ones that do exist seem to be incomplete, poorly documented, buggy,
abandoned, or some combination thereof.

~~~
blackrock
I got annoyed when it didn’t have a decent standard library to handle command
line flags and arguments.

The examples given so far, are mediocre.

parseopt is incredibly cumbersome.

docopt is an incredibly poor design, that I can’t believe anyone thought this
was a good idea.

And failing to have such basic libraries, I realized, this language has a long
way to go.

I contemplated building my own library to handle such a need, but why, this
doesn’t solve my problem of building something. And if it’s missing such basic
libraries, then what else is it missing? The odds were too great, and too
risky for me to commit my time to it.

~~~
pathsjs
There are many libraries for that, but I suggest cligen. It is the simplest
command line parser I have found across all programming languages.

~~~
s_gourichon
What if the Nim maintainers made some kind of continuous popularity
measurement to let good libraries bubble up? Opens other problems I know, but
may fix such scenario and accelerate Nim adoption?

~~~
pathsjs
There was an attempt a few months ago, but it was a little weird. But if you
just want to find libraries relevant for your task (e.g. parsing the command
line), there is [https://nimble.directory](https://nimble.directory) where all
Nim libraries are listed

------
rishav_sharan
Speaking for myself, as an absolute novice, OOPs in Nim is not great. it feels
shoehorned in, rather than being a primary citizen of the language design.
There is too much fiddling with methods vs procs, pragmas and such involved
for the most basic stuff.

I am tinkering on a small 2d game using Nim. I was planning on using OOPs for
most of my game objects. Now I am debating if I should make the effort to
actually learn OOPs the Nim way or just do it procedurally.

Considering that my project is tiny, I might go for the latter and skip OOPs
altogether. So for me right now Nim is a better C, with nicer syntax, simple
build system and a package manager.

~~~
dom96
I would say that this is in some ways by design. Nim offers some OOP features,
but in general does its best to discourage the use of OOP. In that sense I
would say you should skip OOP and implement everything in a procedural style
(it will be more efficient too).

~~~
auxym
The only OOP-ish thing I've really missed in nim is interfaces. It seems to be
a really convenient way to re-use code: "this function (proc) can operate on
any type that has implementations of this and that other function (proc)".

Googling has left me with suggestions of using macros to re-implement similar
functionality, which I guess is in line with nim's philosophy of "small core
with powerful macro system". Looking into it however, developing macros seems
like more effort than a simple interface.

Just the impressions of someone not super familiar with metaprogramming.

~~~
dom96
The idea I think is that someone needs to implement it using macros and get it
into Nim's stdlib. Then we can all make use of it. If you're passionate enough
about interfaces then you may just be able to implement something that works
beautifully and get it merged into stdlib (that would be awesome).

------
simias
I wonder what causes the strong European bias in the results, in general in
those surveys I'm used to seeing USA #1.

Beyond that it actually looks pretty good for the language, it seems popular
among experienced developers and they seem pretty happy with it and consider
using it for serious work (although obviously the fact that they even bothered
to reply to the survey probably biases that).

~~~
tokai
Of the top ten contributors on github, nine of them are Europeans. I think all
nim meet-up/conferences have been in Europe.

Makes me wonder if the language would have more mainstream traction if it was
more of a US project.

------
blackrock
I like the Nim syntax, but I’m not certain why they chose to transpile it to
C.

Why not just go all the way, and encode it in assembly?

Yes, I understand their reasoning, to make use of all the advanced C compilers
out there. And to make the code compatible with existing C libraries and APIs.

But I feel this is more of a shortcut, and a crutch, that will prevent them
from fulfilling their expectations, of being a C language and systems
programming replacement.

I think the better approach would have been to target assembly code instead,
and then, build connections to existing C APIs.

~~~
WalterBright
D doesn't compile to C code because I found C to be a rather limited platform.
By generating native code, I could go beyond what C supported. The vagaries of
various C compilers was also a problem.

~~~
Reelin
Given that C has raw pointers and inline assembly, what is D doing that it
couldn't (easily?) express?

~~~
WalterBright
1\. cannot support anything but the C ABI

2\. cannot support exception handling

3\. cannot support types that C doesn't

4\. stuck with C symbolic debug info, not your language's

5\. cannot innovate with things like how strings are stored

6\. many C compilers do not emit COMDATs

7\. no thread local storage

8\. chained to slow compilation speeds

9\. stuck with trying to find a way to work around C compiler bugs

10\. stuck with whatever C compiler the user has, i.e. one has to support
multiple versions of multiple C compilers

11\. C compiler can change, breaking your compiler

The original C++ compiler, cfront, had a LOT of problems with these issues.

~~~
Reelin
Thanks for taking the time to respond, compilers are always interesting to
learn about!

Point 7 was (finally!) addressed by C11.

Points 6, 8, 9, 10, & 11 are all good ones that hadn't occurred to me.

It seems like points 1, 4, & 5 could be worked around, but I can see where the
added complexity would be unwelcome.

On the whole, I can see why you made the decision you did. However, I don't
buy points 2 (exception handling) and 3 (type support). Certainly C doesn't
have these things built in, but appropriate code transformations seem to
suffice in practice. For example, the CHICKEN Scheme to C compiler employs
continuation-passing style [1] and Embeddable Common Lisp [2] manages to
compile to C without (to my knowledge) breaking either its type system or its
condition and restart [3] system.

[1] [https://wiki.call-cc.org/chicken-compilation-process](https://wiki.call-
cc.org/chicken-compilation-process)

[2] [https://www.cliki.net/ECL](https://www.cliki.net/ECL)

[3] [http://www.gigamonkeys.com/book/beyond-exception-handling-
co...](http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-
and-restarts.html)

~~~
WalterBright
2\. yes, it can be done with setjmp/longjmp, but that's a terrible solution

3\. if the C compiler doesn't support 80 bit reals (and D does), you're out of
luck.

I looked at the C code generated by C++ cfront. No thanks.

The worst is, the C compiler vendor owns you, and they couldn't care less
about you.

------
jrvarela56
Just discovered the HN ‘past’ tab. Went back 5 years in order to find
something that also appeared today. Nim was the only topic I found in a front
page article today and 5 years ago. Maybe just random but I’ll give it a try
and report back.

------
Koshkin
> _Efficient, expressive, elegant_
    
    
      let people = [
        Person(name: "John", age: 45),
        Person(name: "Kate", age: 30)
      ]
    

Verbosity at its finest. Compare with C++:

    
    
      Person people[] {
        { “John”, 45 },
        { “Kate”, 30 }
      };

~~~
kazinator
This is a false comparison because you're really comparing by-order-of-
argument initialization/construction ("BOA constructors") versus keyword-value
initialization/construction.

BOA is more compact, but it's possible to get the arguments wrong, and the
type system won't save you if you exchange two arguments of the same type.

There is no reminder anywhere that 45 and 30 are ages.

That's also true in function calls that do not use keyword arguments (the
vastly prevalent paradigm in mainstream languages), but function calls specify
a function name which can reveal something, like set_age(john, 45).

Some languages have both.

No knowing anything about Nim, I have no reason to believe that it has no way
to achieve a compact way for initializing an array or list of objects using
just positional arguments, and no repetition of the type name. If nothing
else, surely there has to be a way to write an array of tuples, and that
aggregate can surely be passed to some function that iterates over it and
constructs the implied Person objects.

On the C++ front, I seem to recall C++ recently adding C99 designated
initializers or planning to. If so, then { .name = "John", .age = 45 } will be
possible, and C++ coders will end up using it.

~~~
pjmlp
C++ designated initializers are not like C99 designated initializers, rather a
subset.

For example, just like initialization lists on constructors, initialization
order is relevant.

~~~
kazinator
Order is unspecified in C initializers, including designated ones. That
quickly becomes relevant when the program depends on it for expected behavior.

