I've started a new blog with three articles on Nim so far: https://onlinetechinfo.com/tag/nim/
The articles include the top reasons to use Nim, some disadvantages of Nim (for now) and avoiding Nim gotchas. I will be adding more content during my journey with Nim.
Nice! I feel like its blog posts like you that get Nim out there and more popular. Thank you!
Your points about private access are really good, instead of saying undeclared identifier or function it should say trying to call or access a private identifier or function. Would be great improvement!
"Performance is typically on par with, or slightly trailing, C." Performance always depends on how well you write it. It's a topic I really like! One can write super slow Nim as well as super slow C. But I think nim offers is "no boundaries." In languages like python/js you are kind of just stuck. Having optimizing python/js you kind of hit a barrier where you can't go any further. And it sucks. I feel with nim, there is no barrier. You can always go faster! Slow? Try fancy C/C++ profilers like vTune. Figure out your bottleneck? Try ref vs regular objects, try arrays vs seq, try pointer arithmetic, disable array bounds checks, disable stack traces etc... you can always try faster and faster. Even crazy things like compute shaders or CUDA are available to you.
It's not that Nim is fast, it's that Nim does not have "optimization walls." This always allows you to be faster.
Performance is typically on par with, or slightly trailing, C.
You can always reach C performance in Nim.
It's not that Nim is fast, it's that Nim does not have "optimization walls."
Great quote! Can we put it on the website? It says in one sentence what I've always tried to express.
Sorry for nitpicking ... ;-)
> It's not that Nim is fast, it's that Nim does not have "optimization walls."
Great quote! Can we put it on the website? It says in one sentence what I've always tried to express.
If I was completely new to Nim, this sounded to me like "Idiomatic Nim isn't fast, but if you jump through enough hoops you can get it fast." ;-)
For me "a language is fast" if idiomatic code in that language (without or little focus on optimization) is about as fast as idiomatic C (again, with little focus on optimization). If this applies to Nim (which seems to be true), you can say "it's fast" instead of saying "It's not that Nim is fast".
So, yes, the point about no "optimization walls" is good, but without more context the sentence may give a wrong impression.
the sentence may give a wrong impression.
Indeed. And again I have the perfect wording in my book :-)
"Nim is fast. Generally performance is very close to other high performance languages as C or C++. There are some exceptions still — other languages may have libraries or applications that are tuned for performance for many years, while similar Nim applications are less tuned for performance yet, or maybe are more written with a priority of short and clean code or runtime safety."
Sure, how about:
"Idiomatic Nim code is fast and Nim does not have "optimization walls." "
"Idiomatic Nim code is fast and Nim does not have "optimization walls." "
To me, the "... Nim ... and Nim ..." doesn't flow so well. What about
"Idiomatic Nim code is fast and there are no "optimization walls" if you want to make it even faster."
(even if it's a bit longer)? But I guess this can still be improved by thinking more about it.
A question to @all : Do you think that "optimization wall" is understood by most people? As far as I'm concerned, without the context from this thread I would only have guessed the meaning.
@Stefan_Salewski , I think the point about tuned libraries is good. Whether we want to add this, too, depends on how much space we have. If we want to describe Nim with a few bullet points, I'd probably leave the library (dis)advantage out, on the other hand, for one or two paragraphs on Nim performance, mentioning the effect of libraries would be good.
I think "optimization wall" is not always understood without a bit of context. More importantly, languages can have a very steep climb, instead of a wall, that makes optimization possible but not worth the effort.
IMO Nim allows for progressive, smoother optimization.
[Ahem, if we exclude the parallelism/concurrency pains]
After thinking more about it, I suppose the problem with understanding isn't about hitting a wall, but the nature of the wall. ;-)
In this forum, there are frequently questions along the lines, "How can I make this Nim code faster?", so you could say the post authors did hit an optimization wall. It may well be that the language potentially gives you more control over optimization than many other languages, but in practice it may not matter that much, unless you can ask a Nim expert, and even this might not be practical if your software is propriety or you can't reduce the problem to a handy snippet.
So even though I understand the notion of "no optimization wall" in the context of this thread, in my opinion the term is too ambiguous to be used on the Nim website without describing the term more precisely.
write Nim code with performance close to other high performance languages as C or C++.
write Nim code with performance close to Assembly
Once Nim can intelligently add restrict to its generated C when it knows pointers are not aliased, it should be able to beat C ... because no C/C++ programmer I know of ever uses restrict, it's too confusing 🤣
(I say "once" because I saw an issue in the Nim bug tracker calling this out as work that hasn't been done yet.)
Having written a fair amount of Assembly, it's kind of hard to optimize. Most optimizations are done with taking a different approach to solve your problem and not some cleaver SIMD instruction, in fact a random single SIMD can really slow down your code...
I think this is what Nim does really well because of template and macros you can try a ton of different approaches and see what fits best.
I love optimizing stuff.
Hi
I like that description of Nim too as a snappy description / bullet.
While I have no problem what the word idiomatic myself, perhaps plainer language would be better too, for younger people, and perhaps non native English speakers to understand more easily?
At the end of the day it is about communicating something important, so the simpler and clearer it can be the better...
Anyway - some other suggestions:
If the word 'wall' is a concern, how about some alternatives:
Everyday Nim code is fast with no optimisation xxx
Thats plenty of alternatives that convey similar messages :)