Pros:
Extremely good C and C++ interop
Significant indentation
Very good performance
Quick compilation
Terse, but readable
Easy cross platform
Powerful macros and close to trivial DSL construction
Very little code to do a lot of stuff
Incoming future features look very promising
Cons:
Hard to predict and control program performance, LTO does a lot of heavy lifting
Immature ecosystem, because only few users. Many libraries have bugs, missing features or just a very clunky API. Or maybe they are deprecated or abandoned all together.
Many different ways to do the same thing
everyThingIsCamelCase, ambiguous variable names (subjective)
Documentation and tutorials is mostly reading through the code and googling forum posts outside the core language
You compile either for C or C++, some libraries simply won't work without C++ compilation
For my contribution to the ecosystem see Nexus mentioned in another comment. If you see bugs please report them. Sometimes libraries are deprecated/abandoned because of new ideas, this happens in every ecosystem.
I personally use camelCase/PascalCase, but Nim is style insensitive, meaning you can call procs written in camelCase using snake case. However this is controversial and under discussion, my personal opinion is to make style sensitivity optional, with insensitivity the default.
Ambiguous variable names I hate, you won't see that in Nexus, if anyone does they should file an issue. That's really developer dependent.
For my part Nexus has some docs and a basic tutorial. But if people want more they need to ask for it. Why write docs nobody wants or will read? Anyway, this book (Mastering Nim) is one more definite step forward for learning Nim.
I think compiling to C is what mostly happens, C++ is probably an outlier. Even then, a C++ compiler isn't difficult to install if needed.
> Many libraries have bugs, missing features or just a very clunky API. Or maybe they are deprecated or abandoned all together.
For me missing libraries never stopped me, I could always port/wrap whatever I needed. However with the advent of AI assisted coding, working on libraries is even faster and at some point I hope I wouldn't spend much time rolling decent libraries that are ports of existing github projects.
I love nim, but I disagree with the "quick compilation" point here. The compilation is horrendously slow. (by default it compiles down to C, then to exe from there).
As with most things, "it depends". If you compile very macro compile-time virtual-machine heavy code that can be slow. If you compile to the c++ backend then that backend process can be slow. If you invoke some macro that generates mountains of Nim code translated to continents of C code it can be slow. If you use the default `nim.cfg` that has gcc -Og it can take a lot longer than gcc -O0, for example. Meanwhile, if you use the `tcc` backend even without incremental compilation it can be close to immediate feedback:
(I point my default backend compiler to tcc in my $HOME/.config/nim/nim.cfg.) There are some more details in this nim forum thread: https://forum.nim-lang.org/t/8677
Unless your standards are "single digit milliseconds per file like tcc itself, please!", 240 ms is not so bad. (EDIT: And this is just on some 2016-era Intel i7-6700k box, not some liquid helium cooled 10 GHz whatever.)
I just compiled my toy project (detecting anomalous parity in integers) in nim 1.6.6 (4.23s), go 1.17.7 (2.43s to create both aarch64 and x86_64 binaries), zig 0.8.0-dev.1140 (2.04s to create aarch64 and x86_64 binaries) and C via clang 13.1.6 (0.14s).
nim's compilation is 175% of Go, 207% of zig, and 3021% of clang.
how are u compiling (optimization, custom compilation flags etc.?) In my case https://github.com/mratsim/Arraymancer big project compile under your 4.2s so or you have like 10k+ lines of codes with macros or you just pass some debug flags to compiler :D
nim c -d:release --passC:"-flto" --gc:markAndSweep --out:ap ap.nim
I will add that once it's been run a few times, it does go a bit quicker (down to ~0.7s) but the Go also gets quicker (down to 0.28s for two outputs when files are cached.)
$ nim -v
Nim Compiler Version 1.6.6 [MacOSX: arm64]
Compiled at 2022-05-05
Copyright (c) 2006-2021 by Andreas Rumpf
active boot switches: -d:release -d:nimUseLinenoise
No, it is not - Nim's compiler backend is extremely complex and full of cruft. I've been around Nim for 7+ years now and there's a reason the compiler was hard forked.
Nim's compiler is definitely not speedy, and this is why so much effort has been spent on incremental compilation, which tmk, still isn't working - https://github.com/nim-lang/Nim/issues/19757.
I think Nim does DSLs particularly well and is the performant option for the Python class of scripty general purpose languages. I personally prefer more state controlled languages (Clojure, Rust) but I've considered pushing for Nim on shared/work projects. The main reason I haven't is network effects. The language niceties compared to other scripty general purpose languages aren't going to make up for the time spent writing all the libraries from scratch and I can't point to being able to control state as a motivation.
Odd, I've really yet to run into a key library that I needed and couldn't find. Not all libraries are listed in Nimble too. Granted I've not done much web server stuff in Nim. Sometimes a library needed a bit of polish, which is usually trivial given how concise they are. I've actually had better luck with it than say with Elixir on anything not web related. Occasionally I've needed to wrap or convert some C code on non-embedded projects.
By default a green thread is the atomic failure domain. A 'panic' in this green thread is isolated, but sends an uncancellable notification to anyone who subscribes to it. You can tie multiple green threads together so that when one goes down the others do too.
thats exactly how I feel when it comes to web frameworks. nothing else has anything good enough to give up all the nice toys elixir gives me.
haskell's types are cool
vuetify makes me consider nuxt
but only elixir has otp, immutable data structures, intercluseter message passing, channels, good performance, ease of use and descent ecosystem out of the box.
rust is the only other new language Im looking at but for things outside web development
Elixir is indeed the most loved web framework according to the latest StackOverflow survey. I'll be looking to Elixir for ideas for Nexus (web framework).
a lot of what makes phoenix amazing is directly inherited from elixir which are sub-derived from beam.
Beam really is a marvel.
copy one write and immutable data structures mean you ca have garbage collection reserved for the termination of a thread whihc would be a nontrivial task in languages that encourage mutability cough go cough
Beam processes are a blessing
its also extremely tuned for creating threads that are super lightweight. consequently, scaling strategies that are optimal in elixir would be a TERRIBLE idea in other languages. You could make a dynamic cluster of node/go instances that communicate over rabbitmq and have a supervisor process that can keep track of their state and resurrection in case of a crash. Its going to be error prone and take weeks of fiddling to get right. beam gives you that out of the box. Its not perfect but its more than good enough for your first 10000 customers.
This benefit extends all the way up to Phoenix. because threads are trivial to create and the overhead is low, its a viable strategy to generate a stateful process for every user as they interact with the system, this is what allows liveview to be so powerful.
Each channel connection gets its own thread as well. A single machine can handle thousands of threads this way with full isolation. one thread crashing won't affect your other connections. nodejs cannot provide that. if a web-socket connection crashes a node instance, it ends the connection for every customer currently connected to that node.
Every attempt I've seen outside beam to recreate this revolve around OS level process which have a higher overhead and then they still need to create a mesasge passing protcol and supervision system. since OS threads are epensive, it wouldn't be a. good idea to try creating something like liveview as you'll overload your machine.
So you might say, "ok, I'll craete a multicluster virtual machine optimized for immutable data structures with a built in intra process messaging protocol for communication as well as a higher level super vision process. at that point, I'll say "congratulations, you just reinvented the beam, lets see if we can port other languages to it!"
anyways, if you're looking for something a little smaller for now, I highly recommend really understanding ecto and how it has you interact with databases. its easily the best database library I've worked with. precisely because it isn't a orm. It maps sql rows to elixir records which has much less of an impedance mismatch. its achieves almost zero friction between your database and your api.
I’d be curious to get your Nim highlights.