This is a really fantastic resource for learning programming with Nim. I've started recommending it to folks that are newer to programming that want to try Nim out for various reasons. The only downside is that it is written by a non-native english speaker, so some of the phrasing feels awkward at times. Of course, that's a non issue for this kind of technical material, it's very understandable and useful! You can also view the source of this material here: https://github.com/StefanSalewski/NimProgrammingBook
For folks that are more experienced and learn by doing, the two resources I would recommend are https://nim-by-example.github.io/ and https://xmonader.github.io/nimdays/. The first is a solid overview of the basic language, while the second is a bunch of example projects. Other good resources if anyone is interested:
My favorite talks were on Polymorph (a really fast compile time ECS), Pararules (a super cool implementation of a rules engine) and Nim Metaprogramming in the real world (very useful lesser known patterns for using Nim's capabilities in a variety of projects).
Sidebar: I’m excited to see Nim get LLVM support via nlvm. I haven’t read this document yet but I just remembered that Nim is an advancing language and checked GitHub for new developments.
It seems to be that Crystal has made some leaps and bounds in picking up some of the Ruby slack, though I see Nim lagging behind of taking up some Python users.
I’d feel 100000x more comfortable as a potential user if they had a little more corporate support and some mainstream use cases.
I think I’ll take this post as the wake up call to take Nim more seriously in my own hobby programming. I’ve had my eye on it since they changed the name and I discovered it; but I didn’t realize until today people were building such thorough resources.
Whether or not you agree with the many people who think cryptocurrency is the biggest grifting scam to ever grace the internet or not, the bottom line is that as long as they think that and as long as Status is the sole corporate interest behind Nim, then it faces real and several difficulty in picking up steam.
The reality is that most people are not going to use cryptocurrency anytime in the next 10 years. Landlords won't take it, grocery stores won't take it, the whole thing is a mind-boggling waste of time and energy.
Even still, while the tech Status is producing might be cool, surely you can't be so naive as to overlook the obvious tinge it places on other potential Nim adopters.
I'm a crotchedy 50+ yo fart, so pay me no mind if what I say bothers you.
My own experience and interest in cryptocurrency is zero. But my interest in Nim is .GT. 0.
I will say it doesn't bother me personally about the current sponsorship, but I see your point. The linked book is in my reading list - it is the sort of online book that I would love to see professionally typeset for hardcopy.
I'm a 45+ yo fart, and all my learning, experiences, and talents have in many recent years been and are being poured wholeheartedly into blockchain/crypto-related tech (which is all Open Source software), no regrets on my part whatsoever.
you can't be so naive as to overlook the obvious tinge it places on other potential Nim adopters
I've done a lot of soul-searching on this front, and I can't even conceive of a "tinge" on rational potential Nim adopters.
41 yo fart. Rational at times. The tinge, in general, comes from the huge number of crypto projects that are indistinguishable from Ponzis, vehicles for what would be a financial crime if done with regulated instruments, or just the counterproductive inclusion of a blockchain. Nim itself never felt tinged to me back when I tried (and enjoyed) it. But I generally won't touch anything "crypto".
Nim itself never felt tinged to me back when I tried (and enjoyed) it. But I generally won't touch anything "crypto".
Fair enough (I guess). But if you work/play-with with Nim these days, and the libs available from https://nimble.directory/, do you feel you're "touching crypto"? If so, why?
huge number of crypto projects that are indistinguishable from Ponzis, vehicles for what would be a financial crime if done with regulated instruments, or just the counterproductive inclusion of a blockchain
Well... I feel I stand little chance of convincing you of anything, but feel free to checkout the status-im GitHub org I've linked to previously, and you're also very welcome to ask Status core contributors the most scorching questions you can think of via our desktop/mobile app, or on our Discord server, or on https://discuss.status.im/.
From the perspective of an individual, I have no qualms with it, but that doesn’t matter.
I haven’t had to report to a traditional manager for some years, but I can imagine the guffawing of bosses I’ve worked for in the past if I was pitching Nim for something and explaining the lay of the land. Especially since those big buy/sell decisions are often made by non-technical people.
How am I supposed to convince someone to take a ride on Nim when they could point me at Go, or Clojure, or Elixir, etc? I’m just pointing out there’s a lot of choices with very strong corporate third-party adopters.
I’m not an advocate for the way things are, but it’s just a fact of the world that ecosystems with strong corporate backing have a higher likelihood of survival and success.
I hope Nim succeeds, as I assume you do also. I hope you personally succeed. Crypto though, I kinda just hope it all goes away soon, and people look to change society in more pragmatic ways. I know a young fella in a PhD program, goes to my church, he’s getting a tooth pulled because he can’t afford dental coverage. It’s not the fiat currency that’s the problem. Crypto won’t fix these kinds of problems. Anyhow.
If the Status team ever comes around Indiana I’ll take you all out to dinner!
I did not feel it with Nim at all, so I guess the team have done a thorough job of separating concerns. I'd happily write more Nim actually, just checked and the compiler is still there :).
Thanks I'll drop in there some time, always up for learning something new and it doesn't sound like it's ... the laser eyes crowd.
Because it's a single company in an industry infamous for an insane boom-bust cycle, insane levels of fraud, insane levels of criminality. I don't want to develop on a platform whose finances rest on something so shaky. For me it isn't about the morality of crypto "tainting" Nim somehow; it is a simple perception that Status might disappear tomorrow for any number of reasons, and then what happens to Nim?
> it is a simple perception that Status might disappear tomorrow for any number of reasons, and then what happens to Nim?
Status only started sponsoring Nim in 2018[1]. Before that Nim was doing just fine. So the answer to your question is: nothing is going to happen to Nim if Status disappears.
Nim just looks like a dream language to me. It's a fusion of Python and Modula-3 with incredibly expressive macro support (almost as capable as Lisp!) and nifty features like UFCS.
I just wish I had the opportunity to use it. Every time I start working on a personal project, I always default to Python just because I know it well and I know the ecosystem has every library I could want. I need an excuse to write something in Nim.
How about a personal project to port a small library from Python to Nim? I've thought about this a bit. What package might you shoot for? I've recently tried using MoviePy, and I love the interface, but it's slooow to render (4 minute videos can take 30 minutes to render). I might just be using it wrong (I know it uses lower-level libraries like ffmpeg under the hood), but I am curious if Nim would be a more natural fit.
https://github.com/yglukhov/nimpy gives very, very solid access to the Python ecosystem from Nim - I've copied code from Python docs and have had it work with hardly any changes. Hopefully that's a good enough excuse to try Nim out for a personal project!
I think Nim compiles to native code, is orders of magnitude faster than Python without NumPy, and has no GIL unlike Python with NumPy. I'd check out Nim for a project that doesn't require real-time processing without GC (and for real-time audio processing, Nim may be an option but I haven't explored it yet: https://forum.nim-lang.org/t/8613).
It's funny you linked to my random post. I should probably follow up on that as it'd be a nice way to ensure you're not allocating on hot-paths. It'd be for audio processing and such!
Overall I'm finding Nim performs well at real-time style processing with ARC – even when allocating memory. Its memory allocator is taken from research for embedded real time allocation. Still the best pattern is to pass memory as mutable variables on hot processing paths:
Next couple of weeks I'll using Nim on an MCU taking real-time ADC readings at ~64khz. That'll be fun as it'll require interfacing pre-allocated DMA buffers and with multithreaded ARC managed buffers. And they say it's all web programming nowadays. ;)
At a glance, the writing is very friendly, fun and sincere. Indeed, there is a lot of competition in computer languages, and you need some strong supporters (such as games or corporate sponsorship) to survive.
At the very least, the book looks like a good introduction to computer programming in general (not just Nim).
My introduction long ago was the 'commodore 64 programmer reference guide'. The mix of hardware, graphics, sid sound, BASIC and assembly language was great for the curious, learning by taking things/programs apart (and sometimes put them back together) while small enough to fully grasp.
Then moved from basic to assembly, pascal, c, python, c++ (and cuda). Wouldn't mind trying Nim or Rust next. Reading such nice book makes it inviting.
I really need to thoroughly read this. I have scanned sections like the one on References and Pointers and found them useful, but only scratched the surface.
Late last year I switched my work site from Go to Nim. Then this year, with the help of the community and library nimterop, I was able to wrap the duckdb C api and use it in my web app for really fast analytic queries. I really like Nim syntax and the routes in jester:
routes:
get "/":
resp "Wow, nice"
The false-positive virus issue affected my workstation as well, but after consulting with our security team we were able to resolve it.
I would love Nim to have more funding and support.
I like the batteries included approach, but certainly there are some libraries that do things like json better.
The first supported back-end is Nim, which I use in my own projects. Python and other back-end languages will be easy enough to add. The initial front-end is Flutter.
Nim is a great language, very easy to learn and write in. I was a bit skeptical of using a non-OO language for large projects, but it's been fine, and I actually prefer it now.
I have mixed feeling about Nim. I've tried to learn it few years ago. It was "sold" like a Python replacement, it looks like a Python a bit, but when you write code it feels nothing like python at all.
Few things made me confused a bit
* With objects, when I need to use ref and when not.
nim> type
.... Node = ref object
.... le, ri: Node
.... data: int
....
....
nim> var n = Node(data: 9)
nim> n.data
9 == type int
nim> type
.... NodeO = object
.... lw, ri: ref Node
.... data: int
....
....
nim> var no = NodeO(data: 9)
nim> no.data
9 == type int
nim>
* Two ways to import modules, specifically the C style import. I understand the need for it - applying macros and templates, but that makes Nim very different from big family of "no magic" languages. Ability to change syntax is very powerful and probably a big selling point of the language, but in the same time makes it hard to use Nim as casual language.
That time development/coding wasn't my full time job, Python was the "to go" option of automating some tasks, sometimes Java. In both cases there was no magic in the code - `module.something` easy to track to the origin.
Nim's orientation to standard library is nice. I've started checking Nim when I need a faster alternative for parsing big json and csv (compressed and flat) files. I both cases to was easy to archive, easier than Java (with Java I need to match version and bring dependencies) and the speed was fantastic.
Probably the main reason I haven't continued with Nim, was the company's antivirus at some point started to blocks nimble.exe execution on Windows. Another reason is switching to work into data engineering aria and there is no real need for fast compiled program. IDE support wasn't great too, VScode suggested a lot of irrelevant things, but I think it is kind of broken for any language now (out of box).
The best way I can describe Nim is that it marries Python syntax with Modula-3 semantics. It's not just "static-typed, compiled Python", it's the modern inheritor of the entire Algol-Wirth superfamily of languages.
The syntactic differences between Modula-3 and Nim don't mean much in the long run. It's just the fourth phase of this particular superfamily's syntax. It's a bit of an oversimplification, but the preceding syntactic phases can be clumped into "Algol", "Pascal", and "Modula". All of them have significant syntactic differences between them but ultimately come from the same heritage, and I see "Nim" as just the next phase of that.
(to elaborate a bit: when Wirth evolved Algol 60 into Algol W, he only made small tweaks to the fundamental syntax. He then siginificantly overhauled it when he evolved Algol W into Pascal and then Pascal into Modula(-2). Borland/Embarcadero's evolutions of Pascal are of the same category as Algol W in that they made small tweaks while keeping the core syntax the same. Wirth's further languages Oberon and Oberon-2 all kept the same fundamental structure as Modula-2, despite various small syntactic tweaks, as did Modula-3 which wasn't by Wirth but had his blessing.)
I think most confusions come from how divisive significant white space can be and Python being the most popular among that class of surface syntaxes. I am aware (and maybe you are, too) that there is a long list besides Nim: https://en.wikipedia.org/wiki/Off-side_rule, but this does not seem to be very common knowledge.
I think this is a big part of the aesthetic similarity. Without curly, or ordinary, brackets delimiting code blocks you get that nice clean look. Having used Python a lot for a period (and having made one toy app in Nim) I now find especially curly brackets visually noisy.
I’m always hesitant to start projects in less popular languages without knowing if they will stick around, etc. I don’t know much about Nim, but I have tons of respect for people who create excellent content like this that helps a language become more popular and mainstream by making it more accessible.
1. strong financial backing, with open governance and broad contributors, and
2. cool
... has only a thin sliver of overlap.
At some point, either you're motivated to tinker and explore, or you aren't. I can't say what the future holds for Nim, but I would wager that it's an order of magnitude more likely to be around in 20 years than any personal side project app that one of us writes.
A lot of previous contributors to Nim are currently working on an experimental fork due to disagreements with the development of the official compiler: https://github.com/nim-works/nimskull
> For now it's closer to an alternative with most deviations appearing in the standard library, mostly in the form of deleting much of it.
Yikes. I've found that languages with a small standard library have deep dependency trees for imported packages. I hope this is a stepping stone to a different standard library, rather than an end goal in-and-of itself.
Actually the phrasing in the readme is not correct - I will change it later, but now I want to say that the objective is not deleting "much" of it, but rather cleaning up old and deprecated modules, or providing alternative solutions (for things like os/json that historically were a point of friction).
I think better phrasing would indeed be something like "several former core developers" - of course we can't really measure up to the size of the original community, and don't yet have any paid developers (like Araq and narimiran [1] in the mainline - although since the end of September there were not a lot of activity on their part as well - [2] ~30 commits (~23 that are marked `[backport]`) and even less [3] for narimiran)
In some other programming languages like Python or Ruby we can define class methods or static methods which are bound to a class or type and can be called as MyType.myProc. In Nim we can do something similar by use of the typedesc proc parameter type:
But the boil-the-ocean first chapter, e.g. "what is an algorithm", should fall to the editor's pen. No good book is "for everyone." The first chapter misleads new programmers into the idea that the book is for them while they are beginners.
The book has a GitHub repo, but the author unfortunately hasn't decided on licensing yet and doesn't accept contributions. At least there's a place to suggest corrections and possibly have a discussion with the author.
This is really fantastic. Nim is a beautiful language for getting very performance code easily.
Also, there's some really nice projects that use Nim out there - I believe nitter.com and teddit.com use Nim, which are much better than using the original websites if you're not super keen on huge scripts dependencies and everything you do being tracked.
Pretty cool. Would love to use Nim for scientific computing, but I am not sure how mature are, e.g., Neo (https://github.com/andreaferretti/neo) and alike. Any positive feedback?
It's definitely not at the level of numpy/scipy, probably not even Julia, but there's an active community developing Nim for scientific applications at https://github.com/scinim
With the last update to repos in the org being 4 hours ago most no more than 5 contributors, that's about an order of magnitude less developers and development activity than just one Julia org (SciML) out of hundreds of orgs. For comparison, see https://github.com/SciML/ which saw 15 repos with changes by more than 15 developers in that time span. So by numbers, definitely not even close to the activity of just one part of Julia.
As one of the main contributors to SciNim, let me tell you that we're painfully aware of the size of our community.
But when evaluating these things keep the following in mind:
- we're very active on matrix / discord [0][1] and more than willing to provide significant help to anyone who wishes to use Nim for scientific computing
- all of us that do use Nim for scientific computing wouldn't do it, if it wasn't feasible. While we're small, we do have all functionality that any of us need & in the cases where specific things are lacking, we have the ability to call Python [2], Julia [3] and R code [4].
And just keep in mind, every community starts small. :)
Thanks for the answer! What I would find very useful is an API that allows one to call directly BLAS/LAPACK routines. Is that possible in SciNim? If not, how difficult would it be to write the necessary wrappers? I had a quick look at the repo, but could not find the answer myself :p
Yeah that's a typo. 4 days ago. It's just so insane for me to see no changes to any repo in an org for 4 days that I guess my hands auto-completed the sentence to hours haha, sorry.
For folks that are more experienced and learn by doing, the two resources I would recommend are https://nim-by-example.github.io/ and https://xmonader.github.io/nimdays/. The first is a solid overview of the basic language, while the second is a bunch of example projects. Other good resources if anyone is interested:
Nim in Action (book)
https://narimiran.github.io/nim-basics/
https://scripter.co/notes/nim
The official Nim tutorial: https://nim-lang.org/docs/tut1.html
Nim also had a devroom at FOSDEM this year! You can find it at https://fosdem.org/2022/schedule/track/nim_programming_langu....
My favorite talks were on Polymorph (a really fast compile time ECS), Pararules (a super cool implementation of a rules engine) and Nim Metaprogramming in the real world (very useful lesser known patterns for using Nim's capabilities in a variety of projects).