They just offer convenience on top of it, most common example is the `=>` lambda operator from the `sugar` module. I do agree, that the pattern matching macro presented in the article is a bit hard to get used to, but you don't have to, if you don't like pattern matching. And of course there are plenty of alternatives available as well, the simplest one imo is https://github.com/andreaferretti/patty
Macros are not different than functions: one can create readable or crazy spaghetti code in any language.
If you find a codebase full of unreadable macros it's not different than any other type of bad code: stay away from it or simplify it.
Personally, I'm yet to find a macro that makes the code less readable or more difficult to understand.
proc: 401673
macro: 1869
template: 16255
func: 8746
converter: 3538
iterator: 1833
method: 9025
> Style note: For code readability, it is the best idea to use the least powerful programming construct that still suffices. So the "check list" is:
> Use an ordinary proc/iterator, if possible.
> Else: Use a generic proc/iterator, if possible.
> Else: Use a template, if possible.
> Else: Use a macro.
Note that I did the full clone several months back, and it is missing around two hundred packages that were added in this time, but I doubt it changes numbers greatly.
Basically your question is equivalent to asking whether the language has green threads. The original article describing color (http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...) says it's just threads, but it glosses over why a language like C# decided to add async-await and why Java now has its ongoing Loom project.
System threads are heavyweight and as a result usually unsuitable as your concurrency primitive for highly concurrent applications (although you can and most runtimes do build on top of threads). And so if you only have that, you inevitably get what the article calls the "color problem" (see e.g. in Java the async IO APIs, which the article laments, but doesn't explore why they exist and moreover are often preferred by Java programmers over their synchronous equivalents), because system threads aren't enough and a color-based solution inevitably must appear on top of them.
So the question to ask is "does Nim have green threads?" To which the answer is no (and then by extension it does have the color problem, in this case via async-await).
Of course, the downside is that it relies on library authors to use this mechanism.
There's also a new library for 2d graphics being written and figma like UIs: https://forum.nim-lang.org/t/7559 I'm hoping items like the DSL help people write more interesting Nim libraries.
I wonder why.
Then I started looking at Rust. For my purposes, first reaction to Rust was that I hated it. Borrow checker, lifetimes, all the stuff everyone complains about. But once I got over the initial bump it ticked all of the above boxes that Nim didn't, and I ended up appreciating the guardrails it provides around safety that Nim doesn't (or didn't, a lot has happened with garbage collection etc. since I last looked).
If I had more free time in life I'd absolutely be making side projects in Nim.
fwiw this is plain wrong, a garbage collected language in general is memory safe, just with a different scheme (a garbage collector) than rust's memory model. Both are better options from one that is unmanaged.
I hate to attract negative attention from rust fanboys. But none likes Rust's borrow checker and hopefully language developers can come up with a better design.
FWIW the core devs and many others are present on the #nim channel on Freenode with bridges to Discord, Gitter, and (non-Gitter) Matrix.
According to Wikipedia it started in 2008 and is still very alive. It's a good sign.
Some people prefer "There is Only One Way to Do It" languages.
Some people prefer "There is More Than One Way to Do It" languages.
Nim is more like a "There Are Seven Ways to Do It and the Eighth Way is Planned" language.
Also looking code around I think style and usage is pretty consistent and Nim idiomatic code is certainly a thing. Overall I think it is a definitely consistent language. It is definitely evolving but you can go a long (loong way) with 1.0 features.
I also believe “there is only on way to do it” is more of a slogan/goal than a real thing.
Consequently, people disagreeing the way they do in their opinions, even if there were not seven ways to do something in the core language/stdlib, libraries would add those ways. So, the ecosystem would still have them all and more (eventually).
Personal opinion, but I would say Nim is remarkable in being able to support & manage all this diversity. One does not see Nim style guides like C++ style guides where you are only supposed to use the 5..10% or whatever of the specified language that everyone on a team understands, for example. { Yet! Famous last words... :-) }
any examples?
While it may be great for beginners or for short scripts, over time it becomes a real pain when refactoring. Editors mess up indentation all the time when copying and pasting. You only have to inadvertently make a statement either incorrectly part of, or not part of an if a few times, before you become leery of that choice.
Coded in C#, python, go, ruby, elixir, nim, rust, javascript, typescript. Not once felt this.
Most of the time (more often than Python), you can use parentheses if you really want. Getting everyone else on your team to stick to that formatting convention..maybe not so easy because, well, not everyone shares your opinion/values. :-)
(Or we could be using a lisp, but that's another problem :) )
related discussion in nim forum (started because I had question about fusion): https://forum.nim-lang.org/t/7608
if this keeps staying in front page, maybe it makes sense for @dang to fix the typo in the title (Patten -> Pattern)