It has their easy-to-learn properties, but has a better type system, the generics system and macros are arguably more useful, and more usable than what is offered in either language.
It deserves far more attention than it currently gets.
But no, Nim is not everything "python should/want to be".
The name case insensitivity and the implicit imports on the global namespaces are perfect examples of stuff that are better in Python.
In my opinion, this is the correct default, at least for Nim. Operator overloading and UFCS (https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax) don't really work if I have to prefix everything with a module name, and the static nature of Nim means that I'll get a compiler error if there's any ambiguity. There are downsides as well, but language design is all about tradeoffs, and I think Nim got this one right.
Regarding the case insensitivity, I was initially put off by this as well, but in 2 years of using Nim as my primary language, I have never, ever, encountered a real-life issue with it. I've never seen a Nim code base that uses mixed casing, and never encountered or heard of a bug caused by this behaviour. However, it has allowed my own code bases to stay 100% consistent, regardless of the code style of my dependencies, even when those dependencies written in other languages. Contrast this with Python where the `logging` module uses different casing than everything else, so you're forced to use an inconsistent style if you want to consume it. This type of thing is a non-issue in Nim. I think a case sensitive Nim would still be a fine language, but in my experience the pros of being mostly insensitive outweigh the cons.
In the end you may still disagree with both of these decisions, which is fine. Just understand that it's a nuanced discussion, and there's some solid reasoning behind their choices.
Case insensitivity is somewhat complex topic in Nim, as there are some places where the case actually matters, plus there are some more rules for equivalence of identifiers (related to `_` IIRC). In any case, it was never a problem for me in practice; nimsuggest works quite well.
1) The compiler gives you an error, this would be my preferred solution though I'm not aware of any language that does that.
2) These end up referring to the same variable with no error. Nim's solution.
3) These are actually different variables with no error. The common solution.
Again, I would prefer (1) but I think that (2) is a safer way of handling the situation than (3).
If nim picks up pace in a few years and I already have a sense of it, it may be a good for prospects too.
One advantage over C++ is that you don't need to learn make, IDEs or a complex build system. The nim compiler and the nimble package manager just takes care of building for you. "nim c main.nim" and off you go, ending up with a single executable, no matter how many imports, modules, etc you have.
I do recommend this as a gentle introduction: https://nim-by-example.github.io/ and recommend you use VS Code with the Nim extension by saem.
The documentation is good enough that I don't need to google most of the stuff while writing Nim, having types definitely help with that.
I'll be much happier when I can cruise along with choosenim[3] and lockfiles and not have to worry about Makefile + submodules shenanigans.
[1] https://github.com/nim-lang/nimble#readme
A giant makefile shudder, that's the complete anti-thesis of Nim :)
Lock files have definitely been needed for a while though, I agree.
I'm getting tired of how cumbersome Go is and have had my eye on Crystal. Anyone have any insight on how Nim stacks up to Crystal?
The Nim compiler is as fast as the Crystal compiler is slow!
I think Crystal is more enjoyable to use, personally. I am not a Ruby programmer, but Crystal just somehow feels fun to use. Nim by contrast feels very utilitarian, and frankly more practical.
I found the Nim language documentation better than Crystal, the Crystal standard library docs are just as good as Nim.
Nim overall feels like an "early 1.0-ish" language. Crystal feels like they went to 1.0 m too early. I would probably consider using Nim in a medium-sized application for work, whereas I wouldn't feel comfortable with Crystal for more than a personal hobby project.
They do have some things in common (macros, C interop, static types), but aren't really similar languages. I used to lump them together in my head as "those two new languages", but I don't anymore after trying them both.
If you are checking out new-ish languages, I hear Kotlin has some good design decisions that people appreciate (but that the tooling is pretty bad outside of Jetbrains IDEs).
- advent of nim (advent of code with nim): https://forum.nim-lang.org/t/8657#56695
- call for participation to FOSDEM: https://forum.nim-lang.org/t/8671
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!
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?
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 :)
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).
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 :-(
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.
Zig is (a much) better C. Few solid features.
Nim is a better (Pascal+python+lisp)/3. Lots of features. Some are solid.
zig: no macros plz
nim: macros are amazing
Looking at https://nim-lang.github.io/Nim/lib.htmlIt seems to have many of the batteries built in - HTML, JSON parsing, nice set of collections. I wonder how good SQL and especially noSQL support is.
My worry is that there must be rough edges. Plus pandas (not just numpy) is just so convenient at times.
I’ve always meant to take a proper look at Nim, and maybe WASM could be the perfect place for it.
SFML binding probably will be updated to use RAII when ORC is made the default GC.
See this document for more info on Nim's destructors: https://nim-lang.org/docs/destructors.html
Erm, what? How about letting the user decide that?
