Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?
The adoption isn't like Rust and Go, but Nim is growing: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim and the community is active across all socials.
Some downsides: not a big ecosystem(tho can piggyback off C libraries) and tooling isn't great.
Advent of Code would be a great way to dip your toes into a language you might not really care about!
It's certainly been getting better and the focus is also on tooling, so I'm hopeful!
I've just looked at some benchmarks, and even though Nim claims C-like performance, that never seems to be confirmed by independent tests. It is usually a bit behind C / C++ / Rust / Crystal, and roughly on-par with Golang.
Fast enough for sure, but "half the speed of C" would be more honest it seems?
nim c -d:danger -d:lto --opt:speed
https://nim-lang.org/docs/nimc.html
Also, --gc:arc and --gc:orc are going to bring a stronger game to the table as they continue to mature (already pretty far along).
The word "danger" is scary, but it's simply disabling debugging code: debug assertions, full stacktraces, extra safety checks.
What you want are comparable compiler flags across languages, say "optimized for performance, yet retaining safety" and "go as fast as possible and disable all brakes". Which, to be fair, is the default for C anyway, but this is not a desirable default. I'm sure you can similarly game Rust bechmarks by using "unsafe".
Removing debugging features is reasonable for such benchmarks, especially if comparing with languages that don't have them.
Such functions can only be used in an unsafe block, and should only be used if bounds checking is handled elsewhere such that it would be impossible to cause an out of bounds error at runtime.
It’s also often possible to get rust to elide bounds checks by using iterators, which often don’t need them as they know the length up front.
it depends a lot on where you are coming from. If you are a Python developer/user (without any other information it is possibly the most likely case nowadays), you might find it solves a lot of current Python pain points (speed, portability, lack of typing, package system) and it has some added bonuses (great macro system, compiles to JS, works great for embedded).
If you are not a Python developer/user but you are somehow interested in new languages like Rust, Julia or Zig (you might be both), you might want to hear a different take on how Nim is also able to solve some of the problems they solve (a better C++, a better Python/R/Matlab for scientific computing, a better C - not that those languages reduce to those aspects...).
I think that what is happening now with Rust, Julia and Zig is great and I am happy that many people are looking at those languages and growing their ecosystem and their communities. Part of the drive of people there is to be able to make a significant improvement in the evolution of those languages (harder to do that in C, C++, Java, Python, C#, Swift, ...). I just happen to particularly like Nim and love being involved in it so far.
A recent article that explains the philosophy of Nim is the Zen of Nim by Araq (Nim's BDFL) [0]. Nim has some universal vision in the sense that it can be really used for everything (from kernel programming to web development, from scientific computing to game development, from embedded to devoping compilers and interpreters, from short throwaway scripts to critical infrastructure). Not necessarily it is for _everyone_. Taste of people varies a lot and that is a good thing.
The killer feature for me is that it transpiles both to C and to JavaScript and I like the clean Python-like syntax.
I now use Nim whenever I write a decent chunk of "pure logic". By that, I mean something that does something complex and useful without leaving the confines of its own codebase all too much. In those cases it's nice to have the option of portability between the C ecosystem and JavaScript ecosystem.
When I write "glue code" (and, unfortunately, most code that most people write falls into that category) where I basically just put bits of language ecosystem together in a trivial way to achieve something useful, then I use Python because for such tasks the sheer size of the language ecosystem is king.
Araq created Nim because he wanted to. Others use it because they want to. Why does it need a raison d'être ?
What it has: garbage collection with option to turn off, small binaries, compiles to C (and other languages) as intermediate step so it's easy to integrate into existing codebases, it's very fast without needing much trickery, it has all the features everyone always asks for with more being added all the time, etc...
Is it better than Rust, C++, Go, Java, whatever? Probably not in a strict sense. But it's pleasant to write plus above features. It's like Pascal meets Python meets Go but compiles to C and JS.
> https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
Why this was implemented into the language itself, instead of left as a suggestion or a standard is beyond me.
quick edit: also, everything is imported globally (if that's the right term? like in python `from package import *`). So when you see function call, you need to look it up all the time where it comes from.
edit2: apparently I am not alone :)
> Not to mention that reading code requires extra mental overhead (especially being new to the language), that `getAttr`, `get_attr`, etc., are actually the same thing.
On the contrary, the language prevents confusion due to mixing getAttr and get_attr in the same codebase and bugs from using the wrong one.
Unsurprisingly, many safety-critical environments have policies to enforce consistent naming styles.
The linter will convert both to "getAttr" and the compiler will complain if the user tries to define the same proc twice.
Yet, checks on function definition and types has the same benefit of case-pedantic language, without forcing a specific style on the developer.
If you install Nim with choosenim[+], nimgrep will be available in ~/.nimble/bin along with the compiler, nimble, and some other helpful executables.
yes, that is the default, but it is also possible to
`from package import nil`
which gives you python's `import package` behaviour or
`from package import symbol`
which is just like python
I can do `mypackage.mymethod` but it will only be in my own code, because it's not the convention
- if it's a builtin or in the current package, you usie it directly
- if it's in another package the identifier is always prefixed with the package
Case insensitivity is a Western-only concept that should die ASAP, it's immensely complicated to pull off right and it opens a massive can of worms that makes no sense (see the Turkey Test for more about this).
Pascal and old basic (among other languages) have been case insensitive for decades, and that has not been a problem.
In UI, you are by all means correct. But code is a formal language that happens to be expressed in Latin letters. APL is the only real language that doesn’t impose a western character set.
... because back then Unicode was still a pipe dream in the mind of some visionary. Everything used 8 bit encoding, and everyone assumed ASCII or at least something compatible with the 7 bit subset of ASCII.
Nowadays files are formatted in UTF-8, and most modern languages actually fully support UTF-8 identifiers. Nim itself supports UTF-8 "letters" in identifiers, and what is "upper case" or "lower case" 100% depends from the current locale. Restricting your case normalization logic to ASCII is __really bad__, because it basically means that non-Latin letters in identifiers won't be normalized, with possibly unexpected consequences.
> APL is the only real language that doesn’t impose a western character set.
- Rust uses UTF-8: https://doc.rust-lang.org/reference/identifiers.html
- Go allows any Unicode letter in identifiers: https://go.dev/ref/spec#Identifiers
- Swift is also famous for allowing you to use emojis in identifiers.
- Python supports non-ASCII identifiers: https://www.python.org/dev/peps/pep-3131/
And the list goes on. Even C++ can optionally support Unicode in identifiers (for instance, Clang and GCC do indeed support things like `constexpr auto 黒 { "lol" };`).
They could still have been case sensitive (C was), so I don't understand how that's relevant to the idea that "case insensitivity is a problem".
> Rust, Go, Swift, Python
All of these languages impose ASCII for their keywords and directives. They allow you to use other characters for identifiers, but impose ascii in everything that has pre-defined semantics. Original APL is the only "real"/practical language that I'm aware of that gave up the "western centric view" of the world to the point that it doesn't have a single English keyword. (Brianfuck, etc. exist as well, but ....)
And they all impose a left-to-right reading order, which is just as western-centric. Arabic/Farsi/Hebrew go right-to-left, and there are languages that can also go top-to-bottom.
I think the outrage about "western centrism" is misguided. This is a formal system, and just like math, it reflects some history by using latin letters and left-to-right for the predefined symbols, and even preferred use of latin characters in identifiers.
> Nim itself supports UTF-8 "letters" in identifiers, and what is "upper case" or "lower case" 100% depends from the current locale.
If that's true, that may be a problem. I'll look into that, thanks for pointing out - from memory, Nim only folds the lower 7-bit by a 32 difference in ascii code, so it is well defined regardless of locale, but I'll check.
The whole idea of utf-8 in identifiers is a minefield, whether you fold case or not; e.g:
"Εхаｍрⅼе" and "Example" have no single letter in common (I chose them that way using[0]) and no language that allows utf-8 identifiers is going to warn you about that.
The point here is that case insensitivity is only a viable option if you severely limit the encoding allowed in whatever you are using - be it a programming language, filesystem, etc. If the encoding of your files is something is basically akin to ASCII or ISO-whatever (which was what BASIC and Pascal used back in the day) then case insensitivity is trivial and safe.
This whole thing breaks apart as soon as you enter a Unicode world and start accepting identifiers containing more than ASCII, and then the whole concept of "case insensitive" becomes obsolete and outright wrong.
The Unicode equivalent of "case insensitive" is Normalization [0] and it's a big heck of a minefield because it is defined depending on the locale in use. For instance, "FILE.TXT" and "file.txt" are to be considered equivalent under en_US, but not under tr_TR, where the lower case version of "FILE.TXT" is "fıle.txt" and the upper case version of "file.txt" is "FİLE.TXT". This means that normalizing strings can cause to unexpected results depending on the locale, which is especially problematic with filesystems (where a path may exist or not depending on the locale).
> Nim only folds the lower 7-bit by a 32 difference in ascii code, so it is well defined regardless of locale
yes, it is well defined but allowing the entirety of the Unicode letters also means that identifiers may contain glyphs from alphabets that have separate cases, chiefly Greek and Russian, or even accented letters such as `è` or `ö`. Case insensitivity instead of proper normalization makes them potentially confusing, and quite breaks the intent behind allowing Unicode identifiers by making non-US locales second class citizens.
IMHO it is arguably very confusing to non-English speakers that 'mela' is equivalent to 'MELA' but 'tè' isn't equivalent to 'TÈ' while 'Tè' is. It basically means you have to remember what letters are ASCII and what are not, which makes the whole "case insensitive" a potential source of confusion.
I think it is safe to say that in 2021 case insensitivity is an obsolete concept and an obstacle to proper internationalization. Case insensitivity only really works on legacy encodings and with the basic Latin alphabet, and you can rest assured it will be almost always improperly implemented anyway.
The ascii case folding, as employed by Nim and Pascal refers to 26 specific well known characters. It's a non-issue.
It's interesting that some languages, like Go, are specifically designed to avoid it (there's a built-in formatting tool for a single coding convention), while in other languages having a zoo of different styles is viewed as a great idea and the language is designed for it. Or is it about linking with existing C libraries? In that case, I'd introduce some sort of name mapping via attributes/annotations as a whitelist, instead of allowing this behavior by default.
I know there is a `collect` macro in `sugar` module but it is nowhere close to the python comprehensions. The code is too verbose and basically is just the same multiline for loop :-(
[x.name for x in someList if x.age > 5]
Is the same as:
x.filterIt(it.age > 5).mapIt(it.name)
In a way it reads better.
Python is a dynamically typed cowboy land and is painfully slow for many applications. People want types, speed, and fixes for decades of baggage, but they like Python ergonomics.
Go until recently lacked generics (it still doesn't have full generics), has bad error handling, and other weird features.
Rust and Swift also seem to be interested in this space. Rust can be heavy. Swift too Apple-centric.
Nim is doing a good job and is growing at a steady clip.
That's just, like, your opinion man ;)
It makes me productive and it's really fun to use.
The language that is missing is a simple language that can work well with C or C++, compiles fast, is easy to read, has a good lib, etc.
There are not enough non-GC languages that are statically compiled.
I really, really want a pythonic, statically compiled language. I don't want templates, OOP, abstract stuff, just A C-like language, more readable, with good syntactic sugar. My dream is that there would be as much time money and effort spent on python, than was spent en js engine like v8 and spidermonkey.
There are barriers that make python not really viable everywhere, and I wish it would not be the case.
I mean, I would feel like an idiot when someone would point out a feature that makes Python code faster. Python classes are quite massive and complicated (with a bunch of tweaks one can do through attributes).
There's also no need to use any of the language features that you don't want?
Sure. I maintain an internal performance dashboard web app that is fully Nim. Backend uses Jester and the frontend uses Karax + Vega-lite for charts.
You definitely shouldn't. If you need a reason to care, then Nim is simply not for you. You won't benefit from Nim, and Nim won't benefit from you. It's best to agree to disagree and walk away from each other (assuming Nim can walk).
EDIT: I got downvoted a bit here, probably because the above seemed rude and/or dismissive? If so, sorry, that wasn't my intention. What I meant to say is that with languages like Nim it doesn't make sense to be interested in them if you're not already interested in programming languages. It'll be another 10-20 years before Nim becomes something the general populace of programmers should (or, if we're lucky, would have to) care about. So if you don't have a particular reason to be interested in Nim, chances are you won't get such a reason from anything that can be said about Nim at this time.
Basically, asking the quoted question already means that there's nothing you'd care about in Nim.
The default runtime also doesn't have stop the world pauses and uses a similar message passing mechanism to Go.
It's as fast as Rust, nice to look at like Python, easy to write like Python, and compiles to static binaries for any platform you can think of.
There are a lot of other great things about the language but this should get anyone excited.
It also has one of the better macro systems out there. I was interested in developing a programming language with macros, and it has a ton of documentation about it. It’s really well thought out.
I’m not saying to run a business on it, but there are lots of interesting things out there. Language design is still a very active area of innovation.
I wouldn’t make a career or company bet on it (compared to Rust which I think is a very sensible choice) but I’m always keen to noodle away at new hobby projects in Nim.