
Pros and Cons of Nim - navdb
https://onlinetechinfo.com/pros-and-cons-of-nim/
======
sherincall
While I rather like nim as a language, there's a few more cons that need to be
considered for any real use of the language:

\- It has a bus/lottery factor of 1. The vast majority of all the changes were
done by Araq and I have very little faith that the language would survive
without him. This is even more pronounced with Zig (mentioned in comments
here).

\- It has had some very embarrassing bugs after the 1.0 milestone. Most of
them were specific to Windows (e.g. [0]), which casts a lot of doubt on its
cross-platform promise. Multiple times in the last year, when debugging a nim
program, it turned out that the problem was in the language/standard library.

Now, these might not be reasons enough to not use nim, since it's a lovely
language when it works, but a pro/con list should be honest.

[0]: [https://github.com/nim-lang/Nim/issues/12315](https://github.com/nim-
lang/Nim/issues/12315)

~~~
dmix
> \- It has a bus/lottery factor of 1.

What was Rusts early years like? Was it one developer for the first part?

I'd imagine this is not a big deal in the early days, where the benevolent
dictator is as much the language as the project itself, not all technology
adoption happens on the same timelines. Matz with Ruby took a long time to
become super popular, Rich Hickey with Clojure seemed to be a powerhouse even
as that found quick adoption before stalling.

~~~
fluffything
When Rust 1.0 was released it had in the order of hundreds of developers doing
work here and there.

When Rust started as a hobby project it was a one man effort, but it was also
a project with ~1 user. It grew developers before actually growing users, and
for a while, it had more developers than users.

~~~
dragonsh
Rust is design by committee with complicated and large syntax area and to
solve one problem of memory safety created a mountain of borrow checker syntax
and a steep learning curve.

So only time will tell if BDFL based language comes up like Linux or design by
committee like language. Right now Rust is not that significant like Nim and
Zig so all have a chance to come up.

Once there are substantial software written in them like C or C++ than only
will know, right now among modern language only golang and Swift reached that
stages as being significant systems programming language in spite of GC.
Indeed I doubt if Rust will be as revolutionary as Lisp or Haskell or
Smalltalk in terms of contributions for the development of compilers and
language designs.

~~~
fluffything
Not bad for a bot, tell your master that your coherency levels are well down.

------
drenvuk
He missed two that I think are really important.

1\. Arraymancer
[https://github.com/mratsim/Arraymancer](https://github.com/mratsim/Arraymancer)

2\. The new version of the garbage collector understands move semantics to
optimize its reference counting so unlike Rust where you have to deal with it
yourself Nim will handle it for you at the expense of a reasonable amount of
memory.
[https://youtu.be/yA32Wxl59wo?t=855](https://youtu.be/yA32Wxl59wo?t=855) Watch
the whole video for more context if you care.

I think it's a really nice language, too many pragmas but still really nice.

------
rishav_sharan
I love Nim as a language. I do not love the Nim ecosystem. It is too sparse.
Even now there isn't a good web framework that folks can use in production.
Jester is ok but it doesnt inspires the same kind of confidence that Echo,
Fiber etc would do. Jester still doesnt have its own web page marketing it.

I really think that the folks behind Nim need to focus on getting some killer
apps in the ecosystem and in marketing them. That's all Nim needs. Just some
useful tools wrapped in a nice package.

------
jbotz
It occurs to me that the although they were aimed at different uses cases the
language that's actually closest to Nim today is Julia. Python-like syntax,
compiled to native code, significant meta-programming capabilities, some
native support for concurrency. The biggest difference seems to be the
approach to types, since Julia is a dynamically typed language (with optional
type annotations) and Nim is statically typed, but Julia's type systems is
powerful enough that in practice the difference may not be so big.

Anyone out there who has used both and has more observations?

~~~
vsskanth
Last I checked, Julia is not AOT compiled, and some people don't like Julia's
startup time.

For numerical computing however Julia wins hands own purely based on the
community and libraries.

~~~
eigenspace
Julia can be AOT compiled, though it's still experimental progress is being
made quickly.

------
thewisenerd
Oh!

I have another use-case; first-class (easier-than-others?) cross-compilation
support.

I had to build a one-off tool that was a a glorified "curl wrapper" with
validations, for Windows; on a Mac. Wrote a simple nim script, cross-compiled
for Windows, and it's been fine and dandy for a year now :)

I'm sure other languages support this (golang?), but Google's SEO suggested
nim-lang.org

~~~
PMunch
This, for sure. For my work I wrote a dynamic library in Nim. The library is
loaded by an application written in C, and I needed it to work on both Windows
and Linux (Windows for customers, Linux for myself and the server back-end).
Setting up a Docker container that runs the entire build and integrates well
into the existing build-system we had was fairly straight forward. All Nim
needs to cross-compile is a C compiler that can do it (in my case that was
MinGW). So now I'm happily running the same Nim dynamic library compiled to
both a DLL and a .so.

~~~
saagarjha
To confirm, that’s two dynamic libraries, right?

~~~
PMunch
Yes, it's compiled into two different libraries. Nim hasn't magically made
cross-platform dynamic libraries. But the code for both libraries is the same,
just compiled for two different platforms.

------
rlp
I'm a big fan of Nim, but I really wish it supported cyclic type declarations
in separate files and out-of-order functions without forward declarations. As
it is, I'm constantly structuring things around those limitations. Big
projects often end up squeezed into a single huge file (or a few huge files).

~~~
beagle3
consider `include` instead of `import` if you want to break things down to
smaller files.

Also, I'm with Araq on this one -- in my experience, every time I reached for
a cyclic-cross-file-type-declaration, there was a much simpler acyclic
solution I found later.

~~~
rlp
Include doesn't work for cyclic types, they need to be in the same "type"
block. I do not agree with Araq's stance here, there are often cases when
closely-related types need to reference each other, and it's not always
convenient to put them in the same file. That's why you see the "types.nim"
file in larger Nim projects -- no one has a good solution and just shoves them
all together. And, if you use types.nim, you no longer have proper visibility
control, since fields cannot be private and there is no package-level
visibility. Most languages understand this, C/C++/Rust all allow at least the
ability to forward declare a type (and Rust allows cyclic, out-of-order
types).

------
The_suffocated
What is the current state of REPLs for Nim? If I remember correctly, Nim had
an official REPL a long time ago, but it was abandoned a few years back.

~~~
bashbjorn
There is one bundled with a standard nim installation, and I use it regularly
(when working in nim). It works, but it's not very good.

I expect the developers to know this, since its accessible only though the `$
nim secret` command.

------
karmakaze
The thing that put me off was the allowed inconsistent name formatting:
snake_case, pascalCase, (and is it case-insensitive too). This makes it hard
for text editors to find all references besides feeling like you're reading
multiple codebases.

This feature is meant to make linking easier but it shouldn't have leaked into
variability of a single module's sources.

------
peheje
If you like Nim also check out Crystal.

------
thelazydogsback
I really like Nim and have been eager to try for a project -- though for
anything other than a simple script/wrapper I'd really want to see source-
level debugging support in VSCode for one or two of the backends.

~~~
retro64
Neverwinter Nights nwsync tools are written in Nim and the source is available
to tinker with. I've compiled and used the tools on my FreeBSD box to break
apart the modules and prepare them for nwsync distribution (nwsync is used for
client/server asset management mostly for persistent worlds, but is handy for
just running a one-off server with your buddies).

Now you can learn a bit about Nim and have fun doing it :)

A couple of links:

[https://docs.google.com/document/d/1eYRTd6vzk7OrLpr2zlwnUk7m...](https://docs.google.com/document/d/1eYRTd6vzk7OrLpr2zlwnUk7mgUsyiZzLoR6k54njBVI/edit#)

[https://github.com/niv/neverwinter.nim](https://github.com/niv/neverwinter.nim)

------
j88439h84
Why use Nim over Go?

~~~
lactobacillis
People complain about lack of generics and proper try/except/finally in Go.
Nim has both.

~~~
sagichmal
And no native concurrency.

~~~
PMunch
Nim has thread support natively. And an async implementation in it's standard
library which is made entirely as a library, so you're free to write your own,
in fact there exists alternative implementations of async/await in Nim. Just
the fact that a feature like this _can_ be implemented as a library is a
testament to how powerful of a language Nim is.

------
m4r35n357
Nim currently in uber-cool phase. I love it.

After adding a million requested features it will end up bloated like all the
others . . .

~~~
PMunch
Nim has been trimming stuff out of its stdlib instead of adding them lately.
And because of its huge focus on meta-programming almost anything can fit in
an external package anyways (even async is a module in Nim, without any
specific support in the compiler). The Nim language as such seems to be
"complete" as it is now, and I'd say it's quite unlikely to gain bloat in any
way that would affect people not using the bloated parts (i.e. the compiler
will still stay fast).

~~~
m4r35n357
Great to hear. Just hope they can resist the inevitable flood of "good ideas"
and stick to their design.

[EDIT] recognized your nick from IRC a while back, my "good idea" is still to
add support for 80-bit floats ;)

------
tomp
_> Memory leaks are not a concern as Nim uses one of several available garbage
collectors. The new ARC option works with reference counting instead of a GC._

Using "no memory leaks" and "reference counting" in the same sentence is
_#fakenews_. Reference counting leaks cycles unless accompanied with a tracing
GC (at which point reference counting makes little sense).

~~~
beagle3
> Reference counting leaks cycles unless accompanied with a tracing GC (at
> which point reference counting makes little sense).

Python proves otherwise. Reference counting gives you deterministic memory use
and finalization _except_ when a cycle is involved. The tracing GC helps for
those cases (and libraries) that do introduce cycles.

If each one of your objects is in a cycle, then -- yes, reference counting
makes no sense. If only 1% of your objects are in a cycle, it makes 99% sense.

~~~
tomp
Python is a trivial special case as it has no concurrency. In a single-
threaded language, that indeed makes sense. Multi-threaded RC is extremely
tricky to implement efficiently, so unless you can prove there's no cycles (or
you don't care it it leaks memory), it makes little sense.

~~~
beagle3
Oh, so now it's about "efficiently". Goal posts have moved.

No, it's not hard at all to implement efficiently as long as objects don't
cross a thread boundary (and e.g. Nim's older GC used to enforce that
condition, an old version of K tracked it and switched to "lock; xadd" to
count references when something did cross a thread boundary IIRC, which made
it inefficient only for those objects that crossed the boundary which usually
weren't many.

It's way simpler than multithreaded mark&sweep, for example. Regardless - it
makes a lot of sense. It might not make a lot of sense to you, but it does in
general in most contexts.

------
Syzygies
These pros and cons appear to have been curated from around the web; this is a
secondary source. If the final selection has passed throught the filters of
passion and bitter experience, the author doesn't say. The parent site aims to
fill itself with "Useful Tech Content", and this article reads like an
assignment completed by a strong student.

So anyone can dress like Moses, come down off the mountain with tablets, and
we'll debate the scriptures without considering the provenance? Good to know.
California ballot initiatives often work that way.

~~~
navdb
It's a mix of research from the web (and I don't mean copy & paste), questions
I and others have asked, and my own experience with Nim. This is not simply
copy/paste. The rest of the comment I won't even bother to address as you
sound like a troll.

