Nim is an odd language insofar that every time it's pitted against other languages, it performs brilliantly on nearly every level. Yet almost nobody uses it. Really weird juxtaposition.
The solution is to make the ecosystem bigger by contributing to it. Good news! The ecosystem is small, so there's a lot of low-hanging fruit.
I'm a "random guy" writing Nim in my spare time, and I develop & maintain a handful of Nimble packages. Someone might actually be using them, too. None of my packages require regular maintenance because Nim's tooling is dead simple and the language is really easy to work with. It's a great opportunity for an enthusiastic hobbyist to be a big fish in a small pond.
You can directly call C code, yes. You can even work with macros! It's a lot nicer when you can import a package that provides an abstraction layer over the C code, though (for example, my `ruby' package)
> call C functions without having to worry about different naming conventions
Yes. In fact, if you hand-write your C bindings instead of using something like c2nim, you can completely change the name of the function. This is a snippet from my aforementioned `ruby' package:
proc evalString*(code: cstring): RawValue {.importc: "rb_eval_string".}That being said, honestly the thing that stops me from trying/using Nim that the compiler enforces a style and that style is just wrong (it enforces spaces). Same goes for Go which enforces the opening brace on same line style. The people writing those languages can have whatever style they like for their code, but forcing me to use it is very off-putting to say the least. I get that this is probably a minor issue for most people but I can't deal with change that well and things like this are super annoying, especially since there is not one single reason for forcing a certain style on everyone.
I'm aware that `#? replace(sub = "\t", by = " ")` works, but it's a hack and I'd have to inject it everywhere, not a good solution. But at least it's better than Go in this regard.
I agree that the spaces thing is weird. Personally, I don't care what style anyone uses in any language. Nim doesn't care either (besides tabs, for some reason). All I ask is that your style is readable and consistent.
It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code.
I'm a firmware engineer by day, and it seems like every embedded C codebase on earth uses a different style. For me, it's refreshing to be able to write code that's styled consistently, regardless of the styles used by dependencies.
> It seems like every developer has hot takes about code style. With Nim, no matter what hot takes you have about code style, I can import your module without you forcing your style into my code.
I assume you're talking about the partial case insensitivity of Nim? I find that a bit weird tbh but I can see the appeal, you no longer would have things like a dependency doing weird things like all caps function names and forcing you to have that in your code.
> I assume you're talking about the partial case insensitivity of Nim?
That's one part of it, yes. I include UFCS in that as well.
Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.
> That's one part of it, yes. I include UFCS in that as well.
Oh yeah, UFCS is pretty nice. Though I don't like the extra step Nim takes of dropping parentheses for 0 argument functions, I'd very much like to see if I'm calling a function or not. Sure for things like the size of an array it doesn't really matter but the call could be expensive. This is mostly for reading code though, obviously in my own code I'd never drop them.
> Case-insensitivity isn't as weird once you start using the language. Everything in the stdlib (and every Nimble package I've used) is in camelCase anyway, so I often forget that feature even exists. If anything, I'm grateful the language punishes people for trying to name one function `doHttpThing' and another function `doHTTPThing'.
I'd argue that it's still weird because the first letter is still case sensitive and I"m coming from a case sensitive language but being able to use foreign code in your own style is very appealing. I can't think of any good reason why anyone would deliberately have two different functions with the same name in different cases anyway, the closest example I can think of would be T and t for temperature and time but you can also just type those words out, more expressive anyway.
That isn't true, you need parentheses for procs with no arguments, else it's interpreted as a proc pointer. Try `echo` vs `echo()`.
> I can't think of any good reason why anyone would deliberately have two different functions with the same name in different cases anyway
It's used for declaring variables of an object. `type Foo = object` and `var foo: Foo`.
I like Nim's rules for identifiers, it prevents you for mistakenly declaring two different variables/procedures with similar names.
Other examples where, how you would write something doesn't matter, is Windows filesystems and gmail, reserving every possible derivative with a dot like your.name@gmail.com and y.ourname@gmail.com.
So it's not uncommon or weird. Just programming languages are overly restrictive.
My bad, I meant 0 argument member functions (or rather 0 additional argument functions, apart from the this pointer). So `foo: Foo` and then `i = foo.len()` directly shows me that I'm calling a function, `i = foo.len` looks like I just access a member variable. len is obviously not the best example but I still don't think hiding the fact that a function is being called is a good idea at all.
> It's used for declaring variables of an object. `type Foo = object` and `var foo: Foo`.
Good point, I didn't consider that. So far never came up in my code but I can see that it sometimes can be useful to do something like that.
> So it's not uncommon or weird. Just programming languages are overly restrictive.
Natural languages have been case sensitive long before programming languages existed. Again, I'm not saying it's a bad feature - on the contrary, definitely appealing in some case - it's just not what we're used to and hence a bit "weird".
> I decided to make Nim "space only" after having read an interview with Guido van Rossum who said that it is what he would do for Python if he were to decide it again. Also, and more importantly, back then I had never seen "tabs for indentation, spaces for alignment" applied correctly once. In fact, "compress 8 spaces into a tab" was quite common. (This is not the same as "tabs for indentation"!)
In other words, it seems Nim simply attempts to learn from Python's mistakes (even PEP8 discourages the use of tabs for new projects), mixing tabs with spaces brings several potential technical issues for a whitespace-sensitive language, so why not just sidestep that problem entirely?
The only argument that ever comes from spaces people is "alignment" and while I personally think that most if not all of the things people try to align don't get any benefit from that alignment whatsoever nobody advoces for tabs only, you can still always use spaces if you really really really need to align something. Some people messing that up is really not a reason to straightup ban the superior way, you could just train those people better. If you want to align stuff, go ahead. The thing that matters is that if I don't care about your alignment while you do and we both have different tab width preferences then with tabs we both get what we want while with spaces only you would.
Also while this was mostly about tabs vs spaces, those are not the only aspects of a style and the main point was that an enforced style will always upset some people. People simply work differently and intentionally preventing them from using whatever they like is pretty close to malicious if you ask me and in the best case still disrespectful. Some people work better in light mode, some prefer a complete rainbow IDE, some prefer to use raw vi, etc. Or for a better analogy, maybe someone codes much better while listening to loud death metal or whatever. Obviously in an office that would annoy other people but the solution is not to ban developers from listening to music completely but rather to make them use headphones in such cases so that other people are not affected. For code style I might work better with a certain one and you with a different style and that's okay, we just come up with some compromise style that the code is converted to before committing. Languages that enforce a certain style simply don't have this freedom.
Now in whitespace sensitive languages like Python if (and only if) you want to align stuff then yeah things can go boom. But it also is not an unsolvable problem, if the code is all spaces then it just works, if the code is all tabs with no "alignment" then it just works, and if you use tabs with some spaces because you want aligned stuff that can pretty much be checked by the parser. Error if a space is found before a tab, error if a line has more than one tab more than the previous one, etc. I don't think sidestepping this problem is worth alienating people.
[1] https://legacy.python.org/search/hypermail/python-1994q2/020...
I can't even count the number times, over the years, I've had the silliest discussions with people about Pascal syntax. Untold numbers of people used to C-like syntax could not get over begin...end, instead of {...}. Then, even in Pascal circles (and other languages), there was the space versus tab or K&R versus Allman style preferences.
It might seem trivial on the surface, but don't think it is. If a person has spent years working with things a certain way, that's what they are comfortable with. Depending on the person, it can take a lot or there has to be very strong incentives to pull them out of their comfort zone. People might look at Nim (or other languages), on just that aspect alone, and not be interested.
I'm particularly excited about their region isolation [0]. A lot of new languages are exploring it, and it has a lot of potential to change the way we program over the next decade.
So because of the quirkiness I would understand why it is not a universally adopted language.
Do you have pointers to the comparison with other languages?
There’s a few awkward-ish parts of the syntax, but in practice those items aren’t big issues (compared to say Rust async syntax issue). For example multi-line lambdas can be done with ‘do’ blocks or just wrapping parens. Identifier equality has actually saved me from a few bugs by accidentally creating a new similarly named variable, say an ‘isDone’ when I already had an ‘is_done’ following the style from C FFI. Though the compiler warns by default when mix naming styles, and can be set as an error if desired.
Iterators usage can be a bit annoying though. I also really enjoy UFCS: https://en.m.wikipedia.org/wiki/Uniform_Function_Call_Syntax
Python comparison example: https://narimiran.github.io//2018/05/10/python-numpy-nim.htm...
Swift and Obj-C's ARC system relies on atomics and their associated issues (explained well here: https://news.ycombinator.com/item?id=15046481).
Nim's ARC system relies on ownership rules that require a single thread to "own" any ARC-managed memory which removes the need for locks or atomics in the reference counts. That eliminates the non-determinism of locks & atomics when doing the RC accounting, overall improving latency and performance. Move semantics increase performance and enables "giving" ownership of ARC-managed memory to another thread.
import sequtils
let x = [1,2,3,4,5]
echo x.map(
proc (num: int): int =
num*2
)Nim is in progress to fix them, see here: https://github.com/nim-lang/Nim/pull/11992
I don't see why people can't admit to shortcomings in languages? I like Nim a lot, doesn't mean I'm blind to where it falls short or needs improvement...
This is a very surface-level complaint, and it is no surprise that almost everyone who complains about this hasn't actually used the language. I will admit it is indeed a peculiar feature, I wouldn't be able to name another language that did this before, but as it turns out, it has yet to be a problem in practice.
Do you fear some crazy person might mix identifier styles? They could do that in any language, Nim has nothing to do with that. The pro of this feature is that you can write your library in whichever style you prefer, and people can use your library and still use their preferred style, I always hated how in python you often end up having to use libraries written in camelCase for your snake_case project (or vice versa).
Once again, it is a rather peculiar feature, like who asked for this? I don't know, but then again, why not? it did make me raise an eyebrow at first, but in practice, Nim gets it just right. The one valid scenario where it could get in the way is when searching your source files for an identifier, but even then Nim has solutions for that (there's nimgrep, and mainstream editors/IDEs are already nim-aware anyways).
The way I see it, the GC is just nice to have for productivity, and for those cases where you really need to optimize your program, there is nothing stopping you from managing your memory yourself, you can write your own types with their own constructors/destructors (Nim has "scope-based" memory management akin to RAII in C++), of course, you must be aware that using pointers will lead to potentially unsafe code, Nim can't hold your hand there.
C++, for better or worse continues to be a safe choice. A reasonably large user base, and it will be around for a long time. My co-worker joked that if you want your software to be able to run in the future, pick Windows and C++ as your platform. Then you’ll be good for a few decades.