Patten Matching in Nim(nim-lang.org) |
Patten Matching in Nim(nim-lang.org) |
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.
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)
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 :) )
It's true the "just web search it" approach may be weaker than other programming languages. That's a late stage network effect (as is lower latency of Forum/IRC responses).
[1] https://nim-lang.org/docs/theindex.html
Anyway, since Nim has user-defined new operators, using those might also bother some. E.g., there could be a proc `=>` meaning something very different from that sugar module macro of the same name. Really, these work just like other procs modularity-wise. The syntax/grammar does not actually change, though. It's just flexible in the first place.
These complaints sound more like excuses to me. Every language has calls, styles, idioms, etc. you need to learn as a client of whatever it is you're calling/doing. And every language has quirky syntax corners. E.g., many are unaware that C lets you say "(a,b,c,d)" { which evaluates but ignores the result of "a,b,c" }. Yet you still often hear people proclaim how simple C syntax is. "Compared to what?", I guess (e.g. C++).
I do get where you are coming from "overloading"-wise - not just operators, but also regular procs (which in Nim are the same...there is just a proc `<`). When learning an alien language/code-base/libraries it really helps to have jump-to-definition. Nim via nimsuggest has great support for this if you configure your editor (vim, emacs, VisualStudio Code, etc.). You may have skipped that step but might love it more if you did it next time. nimsuggest can be aware of local and global --path modifications and the type context of the jump-to-definition. So, it can do a much better job than, say, ctags. (and yes, nimsuggest works for all the various definition types like macros, templates, etc., even the ones named like an operator such as `<`).
and if you somehow confused about choice (of gc), you should stick to default.
also, there is no such thing as "There is Only One Way to Do It" languages. your entire argument is just a circlejerk point.
When it is garbage collected, how is it garbage collected? There is no simple answer to that.
As stated in my original comment, I prefer languages which are more opinionated than that. Nim is a Swiss Army knife; some people like that, but I prefer choosing a fixed-blade knife to suit my current purpose.
Yes, Nim v1 is a garbage collected language. It also shipped with custom destructors support https://nim-lang.github.io/Nim/destructors.html.
Nim v2, which is hopefully two releases away, will ship with a memory management scheme called "orc" https://nim-lang.org/blog/2020/12/08/introducing-orc.html
However right now, it is recommended that all new code is written with the `--gc:orc` switch.