One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain.
It's not just case insensitive, it's underscore insensitive.
So MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_, and any other variation you can think of are all the same name!
Most search tools have the option of case sensitive or insensitive search, but a search that does that and ignores underscores? Not too many of those outside the Nim world.
An interesting contrast is Nim's policy on tabs and spaces for indentation.
Spaces are fine. You can use as many as you want. Two, four, three, whatever. Nim doesn't care.
But Tabs? They are forbidden!
Unless you use this magic line at the top of each source file:
VB.net is case-insensitive, and probably more popular than you think[1].
I think that case insensitivity actually does make sense when working with symbolic identifiers. I've seen justifications for "Foo" and "foo" being distinct symbols; personally, I find that playing with casing like that reduces my ability to read code quickly.
Case insensitivity does have its downsides, but usually it's not as noticeable in VB.net because most development is done in VS, which automatically re-cases symbols to match the original definition.
[1] Number 6 based on search engine popularity according to https://www.tiobe.com/tiobe-index/ Also, anecdotally, it's used quite a bit in industrial automation.
It's shocking how people whine about case insensitivity without bothering to try using Nim for a while.
Case insensitivity is a feature and it's meant to allow easy interfacing with C.
And it also encourages clean code.
With other languages you can have variables called "startdate", "start_date" and "startDate" in the same scope leading to bugs - especially when using completion in an editor - and poor readability.
In Nim the compiler tells you that you are redefining the same variable in 3 different places and you can go and give them more meaningful names.
As an admittedly amateur programmer, I think the reasoning is solid. Its difficult to read and understand code that does things like myvalue = myValue. I think they made the right tradeoff, in that value != Value (the case of the first letter is used), so if you really need to have to values with the same name, you can still do it.
As an aside, is there some reason that using the same identifier with different cases is desirable?
Nim is written in Nim and no one has run into this style insensitivity confusion despite many people contributing. If your project is smaller or fewer people and you still think this is a big issue, good luck. And if it is larger, this is the least of your concerns.
Think in reverse, is it a useful language feature to have MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_ be different? When did you need this flexibility recently? Are we really so limited at naming things appropriately?
It's fine to make a big deal about something in theory but if it really was such a dumb idea it would have died over the decade Nim has been around. It was debated again prior to 1.0 and persisted, several good reasons are also mentioned in this thread. And it isn't even an original idea as brought up by several others.
If this is the reason someone doesn't try Nim then it's only unfortunate for them. Add this to the tabs vs. spaces, curlies vs. whitespace indentation or other so called concerns which make no difference in the grand scheme of things.
Main reason for this feature is that Nim is big as a glue language. Many C/C++ libraries don't have consistent naming conventions between them. I don't want my code to look like a patch work of `__APICALL__(system_call.inspectSomething())` I just want it to look like Nim code: `apiCall(systemCall.inspectSomething())`. This is just a consistent standard on how to turn names in one style into another style backed into a language.
This. I like many of the things that Nim is doing, but I refuse to take it seriously if it's going to make basic things like tag search and grepping difficult.
inb4 a Nim linter is written to force a consistent naming style throughout a codebase.
Disallowing these case/underscore variants from referring to differing values could be quite ok -- even a plus-- if (but only if) an additional rule is added to disallow any variations of the declaration-time casing for a variable within the same scope to prevent the need for bespoke grepping tools and discourage arbitrary variations. If that restriction was added one could argue that this improves code readability (& "listenability") by have fewer variable names available in the same scope which would sound the same but aren't.
IIRC a study on beginners learning Python found that case sensitivity was the biggest source of errors/confusion. So I'm all for new languages being case-insensitive.
I've been using Linux since the late 90s and case sensitivity has never been an issue for me with Nim since I started using it in 2016. This is FUD and fake news.
> The C-family of languages has quirky syntax, grossly unsafe semantics and slow compilers but is overall quite flexible to use. This is mostly thanks to its meta-programming features like the preprocessor and, in C++'s case, to templates.
> The Pascal family of languages has an unpleasant, overly verbose syntax but fast compilers. It also has stronger type systems and extensive runtime checks make it far safer to use. However, it lacks most of the metaprogramming capabilities that I wanted to see in a language.
While Nim somehow is not appealing to me, this absolutely nails it.
I am confused if you this is an honest opinion or if you are saying with a touch of sarcasm. If it is the latter, a winking smiley or "</sarcasm>" or "/s" would have been nice to avoid triggering Poe's Law.
In my honest opinion, discussion on syntax is a distraction. One of the reasons I like Lisp/Clojure is that there is very little syntax. I can just focus on my problem and writing good code.
I've been considering getting into Nim for a while now as something more lightweight/terse to write thin CLI utilities in. I'm glad to hear that it's performing well for this usecase. It's a very attractive alternative to Rust for it's simplicity and terseness.
I still haven't gotten around to picking it up though, these days I just use QuickJS for anything that needs to be reasonably portable and thin.
I would highly recommend it. Setup is incredibly easy (VSCode has great plugins for it), the language is simple to read/write and compiled Nim is very fast with small binaries. I also really like nimfmt to keep my code tidy so I don't need to worry about it. Nim compiles VERY quickly and errors seem to be easy to comprehend. It's definitely one of my go-to languages for most of my projects.
Nim is great for knocking out commandline apps, I recommend "cligen" for quick and clean options, or "docopt" for friendlier cli options. They feel "scripty" when you can begin with a couple lines and grow it up from there.
I found it the easiest to learn. And difficulties getting my other favorite, D, on embedded and Haiku and OS/2 (which also have poor javascript support) was my prompt to give it a try. I found cross-compiling easy. But just as easy was having Nim installed on all my platforms.
Is there anyone using Nim either in side projects or in production that can comment on how they like it?
I keep hearing about Nim and it sounds interesting, but I'm not sure I have the mental capacity right now to do a deep dive into the language and build something with it. I'd like to at some point soon though.
I use Nim in production. I been using it for more than 1 year in production.
I like it. For me, it started out as a faster python that prevents typos. But it has really grown on me. I really like that I can share libs on server (compiling to c) and client side (compiling to plain javascript).
Basically any C library is also a Nim library with a tiny wrapper. That's a huge ecosystem! I also like how Nim can integrate with complex C++ libs that do virtual table call backs. It can also call objective-C functions .. you know the ones with [foo a:1 b:1] crazy syntax? Python was a glue language for me, but Nim can just glue more things.
JS too! In Nim you can just compile to plain JS, that other JS can call as well. Pass plain JS objects around. I basically replaced my JS code file by file - there was no need for a huge rewrite.
I know docker and kubernetes is "the thing" right now, but I just like that I can just scp the binary over. It just feels less complex. I feel like docker solved the distribution problem for python and node... I just don't have a problem to solve any more. It's just gone.
I've been using Nim in side projects for the past year or so. I really love the language, to the point where its replaced Python/Node as my language for utilities. Some of the qualities I like:
1) Its really easy to get started with. The default runtime has a GC for memory management, and the typing system is pretty similar to other popular languages. You can pick up the syntax in a day, the basic semantics in a weekend, and the more advanced semantics in a month.
2) Its fast and reliable. If the code compiles, it probably works, and it's probably a tier faster than a scripting language. Maybe not as bulletproof as Rust, but the ease of use is worth it for me. It can even reach C speeds, but that does require some advanced knowledge. Again, the default runtime is probably fast enough.
3) Powerful language features. I know there are a lot of people out there happy using C. I'm glad that works for them, but features like case objects, generics, and closures are part of the abstraction tools that I use to get stuff done. Nim also boosts what might be the best macro system for a static typed language, which is very helpful for framework developers.
I'm using Nim in production since .18 with zero issues. I spent many years in Qt/C++ and was reasonably quick, but not as quick as I was with D. But then, in an evening, from a cold start, using nothing more than the two Nim Tutorial pages that I happened to have cached in my browser (I was away from a network connection) I was able to redesign and reimplement the bulk of my application in Nim that had taken me one week in D and two in C++. Qt/C++ was great to go from desktop to server to android/iphone. Qt is a bit of a burden on embedded, and D didn't cross-compile easily as Nim. I like banging out standalone executables starting from a two line "script" and evolving up to a complex server.
I like Python, but find datatype or whitespace issues that crop up only in runtime intolerable. Compiled Nim won't allow that in the first place - and is very helpful with error messages. I'm also infuriated by getting a "cross-platform" Python script that won't run on my machine because I haven't configured and installed all the dependencies that were on the original developer's machine!
Anyway, I'd say pick a small app and have a go. After that, you won't want to waste the mental capacity to use anything else.
For knocking out commandline apps, I recommend "cligen" for quick and clean options, or "docopt" for friendlier cli options.
I've used Nim a bit for side projects (on and off, even back when it was called Nimrod). I found it really really powerful once I got past the initial bump.
It's a fairly small learning curve to be honest, especially if you're familiar with reading Python.
I've used Nim for most of my personal projects for the past ~2 years, and it's generally enjoyable. There are a lot of useful language features. C interop, generics, tagged unions (I always miss these in languages without them), traits (powerful duck typing), channels, generators. Metaprogramming via templates/macros if you want to get crazy. Lots of rope to hang yourself, so to speak.
I wouldn't choose to use it in production, mostly because of the developer experience. The documentation and tooling are both pretty bad, and the compiler errors can be arcane (especially when using generics, or when the error only surfaces during C compilation).
I'm using Nim in production (combined with NodeJS) and I really like it. Cross-compiling is so easy. Testing is easy. Syntax is easy to read. I like it.
I ported a smallish script I use at work (~300 lines or so) from Python to nim fairly easily since the syntax is similar. Being able to compile a small binary across several platforms is nice, though the particular library I used wouldn't compile on Windows using nim 1.0, despite supposedly working in earlier versions (the bugs appear to be in Nim's Windows support, not the library).
The biggest downsides right now as compared to Python are the overall lack of libraries, and lack of documentation (the core language is reasonably well documented, 3rd party libraries much less so).
I used Nim for my implementation of Make A Lisp[1]. I use Python every day and the jump was pretty straightforward. Almost copy and paste from some things. I don't have to think about static types much, but it was a welcome change. I loved having macros to play with, too. I spent a lot of time with docs which aren't bad.
As for the "mental capacity" I felt the same about finally getting into Rust. Spending some time with Nim actually helped me bridge the gap from Python to Rust.
i used it a about three years back for a few sideprojects. i ran into two or three bugs, but i saw those get fixed in the months after my work. im hopefull that biw at 1.0 things are pretty stable. it was mostly a joy to use. meta programming did generate hard to diagnose errors at the time.
Author of the article here, feel free to ask me anything if you're wanting to understand something about the article, or about Nim. I am not the author of Nim.
I also want to point out that Nim does have an IRC channel (#nim) on freenode, which was helpful for understanding some of these things.
How do data scientists feel about Nim? It feels very pythony, but way faster - could be a really cool language for them, similar to what Julia is trying to be.
Curious if anyone in a DS role has tried it out. I'm certainly tempted to try it out, I'm sure I'm losing lots of performance in parts of my analytics pipeline due to Python being garbage slow.
Is Nim stable? I have vague memories that some parts of its runtime had some deep issues that weren't yet resolved, like maybe around concurrency? I see the language is at 1.0 now, does it have a stable, solid, dependable implementation and runtime?
Looks cool already but is it easy to cross-compile? I can copy a Python script from my Linux machine and run it on both Mac and Windows PCs. Can Nim build executables for other platforms nearly as easy?
Does nim have any way to write a one-liner that includes nested scopes? Something like `nim --run="if(...) { while(...) { foo; bar;} }"`? Not knowing nim, I just made that syntax up... :-)
[+] [-] nphard85|6 years ago|reply
[0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
[+] [-] Stratoscope|6 years ago|reply
So MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_, and any other variation you can think of are all the same name!
Most search tools have the option of case sensitive or insensitive search, but a search that does that and ignores underscores? Not too many of those outside the Nim world.
An interesting contrast is Nim's policy on tabs and spaces for indentation.
Spaces are fine. You can use as many as you want. Two, four, three, whatever. Nim doesn't care.
But Tabs? They are forbidden!
Unless you use this magic line at the top of each source file:
Now you get to use tabs![+] [-] lazulicurio|6 years ago|reply
I think that case insensitivity actually does make sense when working with symbolic identifiers. I've seen justifications for "Foo" and "foo" being distinct symbols; personally, I find that playing with casing like that reduces my ability to read code quickly.
Case insensitivity does have its downsides, but usually it's not as noticeable in VB.net because most development is done in VS, which automatically re-cases symbols to match the original definition.
[1] Number 6 based on search engine popularity according to https://www.tiobe.com/tiobe-index/ Also, anecdotally, it's used quite a bit in industrial automation.
[+] [-] nimmer|6 years ago|reply
Case insensitivity is a feature and it's meant to allow easy interfacing with C.
And it also encourages clean code.
With other languages you can have variables called "startdate", "start_date" and "startDate" in the same scope leading to bugs - especially when using completion in an editor - and poor readability.
In Nim the compiler tells you that you are redefining the same variable in 3 different places and you can go and give them more meaningful names.
[+] [-] ac29|6 years ago|reply
As an aside, is there some reason that using the same identifier with different cases is desirable?
[+] [-] gtrs|6 years ago|reply
Think in reverse, is it a useful language feature to have MyNimName, mynimname, MY_NIM_NAME, My_Nim_Name, __MYNIM___name_ be different? When did you need this flexibility recently? Are we really so limited at naming things appropriately?
It's fine to make a big deal about something in theory but if it really was such a dumb idea it would have died over the decade Nim has been around. It was debated again prior to 1.0 and persisted, several good reasons are also mentioned in this thread. And it isn't even an original idea as brought up by several others.
If this is the reason someone doesn't try Nim then it's only unfortunate for them. Add this to the tabs vs. spaces, curlies vs. whitespace indentation or other so called concerns which make no difference in the grand scheme of things.
[+] [-] treeform|6 years ago|reply
[+] [-] coldtea|6 years ago|reply
[+] [-] Riverheart|6 years ago|reply
[+] [-] creatornator|6 years ago|reply
[0] https://nim-lang.org/docs/nimgrep.html
[+] [-] swalladge|6 years ago|reply
inb4 a Nim linter is written to force a consistent naming style throughout a codebase.
[+] [-] ken|6 years ago|reply
[+] [-] 0xfffafaCrash|6 years ago|reply
[+] [-] lmm|6 years ago|reply
[+] [-] emmanueloga_|6 years ago|reply
https://stackoverflow.com/questions/7375537/why-is-common-li...
[+] [-] honewatson|6 years ago|reply
[+] [-] Jefro118|6 years ago|reply
Might be an interesting read for people who are thinking about using Nim and wondering how it compares to the C family, Python, Go, etc.
[+] [-] jstimpfle|6 years ago|reply
> The Pascal family of languages has an unpleasant, overly verbose syntax but fast compilers. It also has stronger type systems and extensive runtime checks make it far safer to use. However, it lacks most of the metaprogramming capabilities that I wanted to see in a language.
While Nim somehow is not appealing to me, this absolutely nails it.
[+] [-] SamReidHughes|6 years ago|reply
[+] [-] jxy|6 years ago|reply
To generate more talking points, somebody ought to write an inverse of dumpLisp: https://nim-lang.org/docs/macros.html#dumpLisp.m%2Cuntyped
[+] [-] jimws|6 years ago|reply
In my honest opinion, discussion on syntax is a distraction. One of the reasons I like Lisp/Clojure is that there is very little syntax. I can just focus on my problem and writing good code.
[+] [-] whateveracct|6 years ago|reply
[+] [-] errantspark|6 years ago|reply
I still haven't gotten around to picking it up though, these days I just use QuickJS for anything that needs to be reasonably portable and thin.
Maybe next side project...
[+] [-] Phillips126|6 years ago|reply
[+] [-] refaqtor|6 years ago|reply
[+] [-] dglass|6 years ago|reply
I keep hearing about Nim and it sounds interesting, but I'm not sure I have the mental capacity right now to do a deep dive into the language and build something with it. I'd like to at some point soon though.
[+] [-] treeform|6 years ago|reply
I like it. For me, it started out as a faster python that prevents typos. But it has really grown on me. I really like that I can share libs on server (compiling to c) and client side (compiling to plain javascript).
Basically any C library is also a Nim library with a tiny wrapper. That's a huge ecosystem! I also like how Nim can integrate with complex C++ libs that do virtual table call backs. It can also call objective-C functions .. you know the ones with [foo a:1 b:1] crazy syntax? Python was a glue language for me, but Nim can just glue more things.
JS too! In Nim you can just compile to plain JS, that other JS can call as well. Pass plain JS objects around. I basically replaced my JS code file by file - there was no need for a huge rewrite.
I know docker and kubernetes is "the thing" right now, but I just like that I can just scp the binary over. It just feels less complex. I feel like docker solved the distribution problem for python and node... I just don't have a problem to solve any more. It's just gone.
[+] [-] nepeckman|6 years ago|reply
1) Its really easy to get started with. The default runtime has a GC for memory management, and the typing system is pretty similar to other popular languages. You can pick up the syntax in a day, the basic semantics in a weekend, and the more advanced semantics in a month.
2) Its fast and reliable. If the code compiles, it probably works, and it's probably a tier faster than a scripting language. Maybe not as bulletproof as Rust, but the ease of use is worth it for me. It can even reach C speeds, but that does require some advanced knowledge. Again, the default runtime is probably fast enough.
3) Powerful language features. I know there are a lot of people out there happy using C. I'm glad that works for them, but features like case objects, generics, and closures are part of the abstraction tools that I use to get stuff done. Nim also boosts what might be the best macro system for a static typed language, which is very helpful for framework developers.
[+] [-] refaqtor|6 years ago|reply
[+] [-] keyle|6 years ago|reply
It's a fairly small learning curve to be honest, especially if you're familiar with reading Python.
What I love about it is the small binaries.
[+] [-] hackeridiot|6 years ago|reply
I wouldn't choose to use it in production, mostly because of the developer experience. The documentation and tooling are both pretty bad, and the compiler errors can be arcane (especially when using generics, or when the error only surfaces during C compilation).
[+] [-] iffycan|6 years ago|reply
Edit: Email me if you'd like more info.
[+] [-] ac29|6 years ago|reply
The biggest downsides right now as compared to Python are the overall lack of libraries, and lack of documentation (the core language is reasonably well documented, 3rd party libraries much less so).
[+] [-] nnadams|6 years ago|reply
As for the "mental capacity" I felt the same about finally getting into Rust. Spending some time with Nim actually helped me bridge the gap from Python to Rust.
[1] https://github.com/kanaka/mal
[+] [-] rwbt|6 years ago|reply
[+] [-] gameswithgo|6 years ago|reply
[+] [-] iikoolpp|6 years ago|reply
[+] [-] yumaikas|6 years ago|reply
I also want to point out that Nim does have an IRC channel (#nim) on freenode, which was helpful for understanding some of these things.
[+] [-] lone_haxx0r|6 years ago|reply
It's not bad, objectively speaking, but its design opinions are the polar opposite of mine.
[+] [-] andybak|6 years ago|reply
However the flexible identifier rules bother me no end. But as soon as my editor of choice handles it transparently then I guess I might come round.
[+] [-] staticassertion|6 years ago|reply
Curious if anyone in a DS role has tried it out. I'm certainly tempted to try it out, I'm sure I'm losing lots of performance in parts of my analytics pipeline due to Python being garbage slow.
[+] [-] haberman|6 years ago|reply
[+] [-] refaqtor|6 years ago|reply
[+] [-] qwerty456127|6 years ago|reply
[+] [-] gonzus|6 years ago|reply
[+] [-] edflsafoiewq|6 years ago|reply
[+] [-] yumaikas|6 years ago|reply
It feels faster than Go, but I think part of that is down to Nim's compile output being verbose by default.