Been happily crunching away at Nim in production. I'm working on what is mainly a data analysis and report generation tool, compiled as a CLI executable that gets called by server scripts.
Nim makes fast, small executables. It has an excellent heterogenous JSON data structure and a good dataframe library. It prefers the stack so strongly that dynamic data structures (sequences and tables, basically its lists and dictionaries) are pointers on the stack to heap data, where the lifetime is managed by the stack frame. I don't think I have any dynamic references anywhere in my program, and don't have to worry about GC at all. The type system is simple, sensible, and guides you to correctness with ease. Nim also defaults to referential transparency; everything is passed immutably by-value unless you opt out. Generics are powerful and work exactly as you expect, no surprises. Universal function call syntax is ridiculously powerful: You can write the equivalents to methods and interfaces on types just by making procedures and functions that take a first parameter of that type; not needing those abstractions greatly simplifies and flattens code structure. It's just procedures and objects (functions and structs) all the way down.
It's been a real joy to work with and reminds me of when I discovered D back in the day, only it's even better. If you imagine native-compiled type-annotated Python where nearly 100% of your code is business logic with no cruft, you're getting close to the Nim experience.
> “It prefers the stack so strongly that dynamic data structures (sequences and tables, basically its lists and dictionaries) are pointers on the stack to heap data, where the lifetime is managed by the stack frame.”
Isn’t that the same as a C++ vector or map on stack? They allocate internally as needed, and the whole container is destroyed when it goes out of scope.
After programming professionally for 25 years, IMO Nim really is the best of all worlds.
Easy to write like Python, strongly typed but with great inference, and defaults that make it fast and safe. Great for everything from embedded to HPC.
The language has an amazing way of making code simpler. Eg UFCS, generics, and concepts give the best of OOP without endless scaffolding to tie you up in brittle data relationships just to organise things. Unlike Python, though, ambiguity is a compile time error.
I find the same programs are much smaller and easier to read and understand than most other languages, yet there's not much behind the scenes magic to learn because the defaults just make sense.
Then the compile time metaprogramming is just on another level. It's straightforward to use, and a core part of the language's design, without resorting to separate dialects or substitution games. Eg, generating bespoke parsing code from files is easy - removing the toil and copypasta of boilerplate. At the same time, it compiles fast.
IMHO it's easier to write well than Python thanks to an excellent type system, but matches C/C++ for performance, and the output is trivial to distribute with small, self contained executables.
It's got native ABI to C, C++, ObjC, and JS, a fantasic FFI, and great Python interop to boot. That means you can use established ecosystems directly, without needing to rewrite them.
Imagine writing Python style pseudoocode for ESP32 and it being super efficient without trying, and with bare metal control when you want. Then writing a web app with backend and frontend in the same efficient language. Then writing a fast paced bullet hell and not even worrying about GC because everything's stack allocated unless you say otherwise. That's been my Nim experience. Easy, productive, efficient, with high control.
For business, there's a huge amount of value in hacking up a prototype like you might in Python, and it's already fast and lean enough for production. It could be a company's secret weapon.
So, ahem. If anyone wants to hire a very experienced Nim dev, hit me up!
Congratulations to everyone involved and the entire Nim community!
Nim has been my language of choice for the past decade and I'm really happy with the new features in Nim 2.0. Some of them are real gamechangers for my projects. For example, default values for objects theoretically allow me to make Norm[1] work with object types along with object instances. And the new overloadable enums is something Karkas [2] wouldn't be possible at all (it's still WIP though).
Of all the recent changes, default values is my favorite. Aside from generally useful and further reducing the need for initialisation boilerplate, I lets us guarantee valid state at compile time for things like enums - and, I assume, object variants?
Nim is really very nice language to write software in. Ship fast, enjoy the ride, produce very performant software. Unfortunately it still in my experience has some sharp edges: juggling C/C++ compilers and options, very poor error messages, very situational libraries that only work on some settings and systems. Given the small community, tho, I can't really fault them for it. The VS Code integration works very well in my experience, rarely crashing.
If someone at Manning Publications is reading this, it would be great to have a book on the newer Nim version, but please consider using a different typesetting with more readable fonts. I purchased the great book by Dominik Picheta, but am forced to use the .pdf because the dead tree version uses thin fonts that I find extremely hard to read even with the right pair of glasses. Font components (arms, lines, stems, etc) are just too thin. Not being a youngster anymore, I naturally thought it was my fault and took the original K&R 2nd ed as a comparison, but still can read it perfectly.
Nim has been my favorite language for a while now, and I'm very excited to see version 2.0 finally released. A lot of these features have been items I've been looking forward to for some time.
The only downside is some of the included modules being moved to 3rd party repositories, as mentioned at the very bottom. It's not a big deal, but it was nice having SQLite support built into the library. I suppose once you support some databases, you'll be pressured to support more and more. I am a bit surprised to see MD5 and SHA1 support moved out though.
I find Nim to be an absolutely fascinating language. I've been trying to find a reason to use it on my job (my work is mobile-adjacent so the idea of compiling to JS and to ObjC is fascinating) but haven't gone beyond playing around with it so far. I've been comparing it to Rust and it's just so much simpler to get started with.
Had a look a Nim few months ago - feature wise is a lot of I wish Python had (easy interop with C/C++, static typed, compiled, can be transcompiled and executed on android/iOS), but ecosystem is small even though the language is not new. There is not many high quality libraries such a numpy, scipy, pandas, opencv in python. They lack some big player adopting it - it's too bad Unreal Engine didn't try to adopt Nim instead of creating their own new scripting language Verse.
One thing I'm also lucking is out-of-the-box interop with C/C++ libraries without creating own adapters (so that you can just import header and be done with it).
Another thing is I wish it had similar easy interop with Rust - just to increase adoption and also because in Rust easier to find high quality cross-platform crates (including mobile) that work without hassle even on mobile devices.
I worry in few years either Python will catch up (because of faster python, non-GIL, nuitka, briefcase for mobile etc) or Mojo will eat Nim lunch.
To be fair to Nim, only Python has the huge ML ecosystem of numpy, scipy, pandas, opencv, pytorch, tensorflow, keres... Doing ML/AI style work in anything but python is really hard!
That said Nim does have the nimpy library that allows for pretty seamless interop with python. Which means you can just import PyTorch, or scipy, or opencv and use them in Nim.
Anyone have working experience with Nim and Zig? I'd love to hear how they are similar and contrast. I'd also would like to see some idiomatic web server benchmarks between the two (now with Nim v2).
So, Nim doesn’t seem to be under an umbrella of a non-profit. Isn’t this destined to be a problem at some point regarding either acquisition of rights or succession?
Edit: Ouch. Just found this thread. Very disappointing, and actually makes a greater case for institutional ownership: https://forum.nim-lang.org/t/10312
I also found that thread. It was very pleasing and it seems he has definitely thought about the issue. While his response seems to go from 0 to 100 in a second, he is still honest and gets to the point instead of waiting for all the "why not?"s to roll in.
It's not surprising he has his head screwed on straight. There is clear genius in Nim's design. I'm not a genius, and I don't know much about compilers, just scant knowledge of some data structures and algorithms, but what I do know is that being able to make something so powerful be used by mere mortals like me is very much genius (an idiot values complexity and all that jazz).
But I left it because of recursive imports. I had to basically put all my types into one file and use them from various others. For a relatively medium sized project (~10LOC), its a but of a hassle. Refactoring is an issue.
That being said, the language is fantastic. Can anybody with experience suggest me what HTTP library/framework do they prefer for servers?
Go had full time engineers designing the language, tooling, docs, etc. Nim has never had huge industry sponsorship, so comparing the languages on age alone is hardly fair.
When I looked at it a few years ago, the compiler didn't prevent you from accessing fields from the wrong variant, and didn't provide exhaustivity checks. So I think it still falls short of this (excellent) litmus test :/
I feel the same way as you! I've seen many language ideas come and go in my career and sum types are one I feel now should be a basic requirement. I miss them in any language without them.
An ABI for languages with a proper type system seems fantastic. Swift, Rust, Nim, D all share very similar type systems (and memory management systems) and it would be very cool to see what kinds of interop easy dynamic linking would allow.
> Now one can define constructors and virtual procs that map to C++ constructors and virtual methods, allowing one to further customize the interoperability.
I hope this will help with bindings for C++ libraries that have historically been tricky to wrap.
For example, I would like to use Qt from a compiled language that's a pleasure to use, and this project looks promising:
So "var i: int" is value, "var i: ref int" is a heap allocated reference that's deterministically managed like a borrow checked smart pointer, eliding reference counting if possible.
You can turn off GC or use a different GC, but some of the stdlib uses them, so you'd need to avoid those or write/use alternatives.
Let me say though, the GC is realtime capable and not stop the world. It's not like Java, it's not far off Rust without the hassle.
nim is a better python(syntax wise) that compiles to c(or c++,js,etc but c is the default) with GC turned on by default. I have always been wanting to use it outside of what my job needs(c/c++/python). I hope some big players adopt Nim to make it one of the mainstream language.
Reddit was hiring for Nim positions. So demand is growing. New languages have easier time being adopted at startups which grow into big players eventually.
Nim looks awesome. Does anyone know why it doesn't have first-class support for wasm? That's the only thing that would keep me from diving into it more.
I think the short answer is it's built on top of C tooling so it doesn't really need another way to do it because you can use emscripten. Search their forum for "web assembly".
I suspect it's simply a size-of-community thing. If you want it, you should take a crack at implementing it! Or least start a thread about on the official developer forum.
The last time I used the language, it was still using a garbage-collector and there were talks about transitioning towards a new way of doing things - I assume that ARC/ORC ended up being that destination.
Now that ARC/ORC is considered "complete," are there any remnants of the old GC still in the language, or has the entire ecosystem hopped over?
[+] [-] netbioserror|2 years ago|reply
Nim makes fast, small executables. It has an excellent heterogenous JSON data structure and a good dataframe library. It prefers the stack so strongly that dynamic data structures (sequences and tables, basically its lists and dictionaries) are pointers on the stack to heap data, where the lifetime is managed by the stack frame. I don't think I have any dynamic references anywhere in my program, and don't have to worry about GC at all. The type system is simple, sensible, and guides you to correctness with ease. Nim also defaults to referential transparency; everything is passed immutably by-value unless you opt out. Generics are powerful and work exactly as you expect, no surprises. Universal function call syntax is ridiculously powerful: You can write the equivalents to methods and interfaces on types just by making procedures and functions that take a first parameter of that type; not needing those abstractions greatly simplifies and flattens code structure. It's just procedures and objects (functions and structs) all the way down.
It's been a real joy to work with and reminds me of when I discovered D back in the day, only it's even better. If you imagine native-compiled type-annotated Python where nearly 100% of your code is business logic with no cruft, you're getting close to the Nim experience.
[+] [-] pavlov|2 years ago|reply
Isn’t that the same as a C++ vector or map on stack? They allocate internally as needed, and the whole container is destroyed when it goes out of scope.
[+] [-] Zamiel_Snawley|2 years ago|reply
[+] [-] 999900000999|2 years ago|reply
I hope it gets more popular, seems like a much much easier to use Rust
[+] [-] shmageggy|2 years ago|reply
[+] [-] arc619|2 years ago|reply
After programming professionally for 25 years, IMO Nim really is the best of all worlds.
Easy to write like Python, strongly typed but with great inference, and defaults that make it fast and safe. Great for everything from embedded to HPC.
The language has an amazing way of making code simpler. Eg UFCS, generics, and concepts give the best of OOP without endless scaffolding to tie you up in brittle data relationships just to organise things. Unlike Python, though, ambiguity is a compile time error.
I find the same programs are much smaller and easier to read and understand than most other languages, yet there's not much behind the scenes magic to learn because the defaults just make sense.
Then the compile time metaprogramming is just on another level. It's straightforward to use, and a core part of the language's design, without resorting to separate dialects or substitution games. Eg, generating bespoke parsing code from files is easy - removing the toil and copypasta of boilerplate. At the same time, it compiles fast.
IMHO it's easier to write well than Python thanks to an excellent type system, but matches C/C++ for performance, and the output is trivial to distribute with small, self contained executables.
It's got native ABI to C, C++, ObjC, and JS, a fantasic FFI, and great Python interop to boot. That means you can use established ecosystems directly, without needing to rewrite them.
Imagine writing Python style pseudoocode for ESP32 and it being super efficient without trying, and with bare metal control when you want. Then writing a web app with backend and frontend in the same efficient language. Then writing a fast paced bullet hell and not even worrying about GC because everything's stack allocated unless you say otherwise. That's been my Nim experience. Easy, productive, efficient, with high control.
For business, there's a huge amount of value in hacking up a prototype like you might in Python, and it's already fast and lean enough for production. It could be a company's secret weapon.
So, ahem. If anyone wants to hire a very experienced Nim dev, hit me up!
[+] [-] moigagoo|2 years ago|reply
Nim has been my language of choice for the past decade and I'm really happy with the new features in Nim 2.0. Some of them are real gamechangers for my projects. For example, default values for objects theoretically allow me to make Norm[1] work with object types along with object instances. And the new overloadable enums is something Karkas [2] wouldn't be possible at all (it's still WIP though).
[1] https://norm.nim.town
[2] https://karkas.nim.town
[+] [-] arc619|2 years ago|reply
[+] [-] 127|2 years ago|reply
[+] [-] foderking|2 years ago|reply
[+] [-] philkrylov|2 years ago|reply
[+] [-] squarefoot|2 years ago|reply
[+] [-] alwaysbeconsing|2 years ago|reply
[+] [-] uticus|2 years ago|reply
https://www.manning.com/contact
[+] [-] treeform|2 years ago|reply
More and more large companies and startups are adopting Nim.
Super excited for Nim 2.0 and huge thanks to all who contributed!
[+] [-] fuzztester|2 years ago|reply
Ineresting.
Are there any stats / data on this, or is it anecdotal?
Even if anecdotal, can you name some names?
[+] [-] aquova|2 years ago|reply
The only downside is some of the included modules being moved to 3rd party repositories, as mentioned at the very bottom. It's not a big deal, but it was nice having SQLite support built into the library. I suppose once you support some databases, you'll be pressured to support more and more. I am a bit surprised to see MD5 and SHA1 support moved out though.
[+] [-] otherme123|2 years ago|reply
While it's nice to have path or logging support in the batteries, some other things are better as third parties, to allow them to evolve.
[+] [-] afavour|2 years ago|reply
I find Nim to be an absolutely fascinating language. I've been trying to find a reason to use it on my job (my work is mobile-adjacent so the idea of compiling to JS and to ObjC is fascinating) but haven't gone beyond playing around with it so far. I've been comparing it to Rust and it's just so much simpler to get started with.
[+] [-] jasfi|2 years ago|reply
This is great for reusing Nim code in a web app, and possibly for performance critical code.
[+] [-] pzo|2 years ago|reply
One thing I'm also lucking is out-of-the-box interop with C/C++ libraries without creating own adapters (so that you can just import header and be done with it).
Another thing is I wish it had similar easy interop with Rust - just to increase adoption and also because in Rust easier to find high quality cross-platform crates (including mobile) that work without hassle even on mobile devices.
I worry in few years either Python will catch up (because of faster python, non-GIL, nuitka, briefcase for mobile etc) or Mojo will eat Nim lunch.
[+] [-] treeform|2 years ago|reply
That said Nim does have the nimpy library that allows for pretty seamless interop with python. Which means you can just import PyTorch, or scipy, or opencv and use them in Nim.
[+] [-] jadbox|2 years ago|reply
[+] [-] sedatk|2 years ago|reply
Edit: Ouch. Just found this thread. Very disappointing, and actually makes a greater case for institutional ownership: https://forum.nim-lang.org/t/10312
[+] [-] skitter|2 years ago|reply
[+] [-] djur|2 years ago|reply
[+] [-] koromak|2 years ago|reply
[+] [-] SuaveSteve|2 years ago|reply
It's not surprising he has his head screwed on straight. There is clear genius in Nim's design. I'm not a genius, and I don't know much about compilers, just scant knowledge of some data structures and algorithms, but what I do know is that being able to make something so powerful be used by mere mortals like me is very much genius (an idiot values complexity and all that jazz).
[+] [-] demizer|2 years ago|reply
[+] [-] foderking|2 years ago|reply
[+] [-] himujjal|2 years ago|reply
But I left it because of recursive imports. I had to basically put all my types into one file and use them from various others. For a relatively medium sized project (~10LOC), its a but of a hassle. Refactoring is an issue.
That being said, the language is fantastic. Can anybody with experience suggest me what HTTP library/framework do they prefer for servers?
[+] [-] elcritch|2 years ago|reply
Chronos is probably the most feature rich and uses async. Mummy is newer and uses a threading model. Both are used in production.
[+] [-] winrid|2 years ago|reply
[+] [-] _xivi|2 years ago|reply
Even though it's older than its peers like Rust and Go, it still quite the underdog.
Hope more people start paying attention to it.
[+] [-] 0cf8612b2e1e|2 years ago|reply
[+] [-] frou_dh|2 years ago|reply
https://nim-lang.org/docs/manual.html#types-object-variants
[+] [-] c-cube|2 years ago|reply
[+] [-] jackmott42|2 years ago|reply
[+] [-] fithisux|2 years ago|reply
now you got me really interested.
At some point dlang-betterc + zig + nim should have an interoperability article and share libraries.
[+] [-] j-james|2 years ago|reply
An ABI for languages with a proper type system seems fantastic. Swift, Rust, Nim, D all share very similar type systems (and memory management systems) and it would be very cool to see what kinds of interop easy dynamic linking would allow.
[+] [-] foresto|2 years ago|reply
I hope this will help with bindings for C++ libraries that have historically been tricky to wrap.
For example, I would like to use Qt from a compiled language that's a pleasure to use, and this project looks promising:
https://github.com/jerous86/nimqt
[+] [-] WhereIsTheTruth|2 years ago|reply
Questions:
- value/object semantic: i peeked at some code, and i can't tell what is a value, and what is a reference type, is everything heap allocated?
- tooling: what's the state of their language server? does it work with all of their language features?
- debugging: does gdb/lldb understand nim's types and slices?
And finally: is a no-gc mode available?
I'll play with it later today, it's always been in my todo list of languages to try, now is the perfect time
[+] [-] arc619|2 years ago|reply
So "var i: int" is value, "var i: ref int" is a heap allocated reference that's deterministically managed like a borrow checked smart pointer, eliding reference counting if possible.
You can turn off GC or use a different GC, but some of the stdlib uses them, so you'd need to avoid those or write/use alternatives.
Let me say though, the GC is realtime capable and not stop the world. It's not like Java, it's not far off Rust without the hassle.
[+] [-] synergy20|2 years ago|reply
[+] [-] treeform|2 years ago|reply
[+] [-] turnsout|2 years ago|reply
[+] [-] ilaksh|2 years ago|reply
I did ask him about it eight years ago: https://forum.nim-lang.org/t/1392#8675
But that was a little early on and there have been other priorities for the language.
[+] [-] hugs|2 years ago|reply
[+] [-] LexiMax|2 years ago|reply
Now that ARC/ORC is considered "complete," are there any remnants of the old GC still in the language, or has the entire ecosystem hopped over?
[+] [-] treeform|2 years ago|reply