Hacker News new | ask | show | jobs
by tiffanyh 1924 days ago
NIM seems like this unicorn of a language of having great performance, amazing balance between being both high-level and low-level, extremely approachable due to syntax ... yet very few have actual discovered and use NIM.

I wonder why.

8 comments

I tried out Nim. My first reaction was that I absolutely loved it. Second reaction was when I needed to look up how to do something and I realised that the docs aren't amazing. Third reaction was when I first ran into a problem I couldn't find anything on Google, and had to post on the Nim forums. The forums were great but there's an inevitable time lag between posting and getting a response.

Then I started looking at Rust. For my purposes, first reaction to Rust was that I hated it. Borrow checker, lifetimes, all the stuff everyone complains about. But once I got over the initial bump it ticked all of the above boxes that Nim didn't, and I ended up appreciating the guardrails it provides around safety that Nim doesn't (or didn't, a lot has happened with garbage collection etc. since I last looked).

If I had more free time in life I'd absolutely be making side projects in Nim.

> I ended up appreciating the guardrails it provides around safety that Nim doesn't...

fwiw this is plain wrong, a garbage collected language in general is memory safe, just with a different scheme (a garbage collector) than rust's memory model. Both are better options from one that is unmanaged.

I hate to attract negative attention from rust fanboys. But none likes Rust's borrow checker and hopefully language developers can come up with a better design.

What exactly is wrong with Nim's docs, in your opinion? They seem fine after perusing the ones at the following link a bit just now:

https://nim-lang.org/documentation.html

IMO, while the descriptive department is passable, the docs seriously lack on the prescriptive side. What I found extremely helpful when dabbling with Rust, is that every module in STD docs has a pretty comprehensive general description and usage suggestions, often accompanied by some examples. It really works great lifting the curse of knowledge for the uninitiated and it doesn't get in the way when the reader already knows what he's after as thse introductions are easily skippable.
> The forums were great but there's an inevitable time lag between posting and getting a response.

FWIW the core devs and many others are present on the #nim channel on Freenode with bridges to Discord, Gitter, and (non-Gitter) Matrix.

Many people find just searching the big index [1] to be enough. Besides the Forum and the IRC (often more immediate), there is also a Wiki [2] where you can maybe contribute documentation for "what you would have liked to have seen" and numerous other documentation things off of [3].

It's true the "just web search it" approach may be weaker than other programming languages. That's a late stage network effect (as is lower latency of Forum/IRC responses).

[1] https://nim-lang.org/docs/theindex.html

[2] https://github.com/nim-lang/Nim/wiki

[3] https://nim-lang.org/documentation.html

Easy: no killer app nor big corps support.

According to Wikipedia it started in 2008 and is still very alive. It's a good sign.

I think network effects have a lot to do with it. If a language has a small ecosystem, it's less attractive for new developers, so the ecosystem stays small. That said, I think the Nim ecosystem might be able to achieve a critical mass of useful libraries soon and break out of that cycle. There's been a lot of good work done in the UI and web domains in the past year, which is such a large market that even capturing a small portion would bring a lot of developers into the ecosystem.
In my case, I actually prefer my languages to be more opinionated. Nim implements just about every paradigm it can think of, and if there are multiple ways to implement a paradigm, it implements them all. It feels like a sophomore college student who keeps switching majors.

Some people prefer "There is Only One Way to Do It" languages.

Some people prefer "There is More Than One Way to Do It" languages.

Nim is more like a "There Are Seven Ways to Do It and the Eighth Way is Planned" language.

Nim seems pretty opinionated to me: use imperative style, minimal or none OOP (preference for macro built DSLs over OOP), functional allowed for those who like it.

Also looking code around I think style and usage is pretty consistent and Nim idiomatic code is certainly a thing. Overall I think it is a definitely consistent language. It is definitely evolving but you can go a long (loong way) with 1.0 features.

I also believe “there is only on way to do it” is more of a slogan/goal than a real thing.

Nim is a very flexible language where things that would, in almost any other language (besides Lisp/Racket/etc) require direct compiler support (like async/coloring) can be done as libraries.

Consequently, people disagreeing the way they do in their opinions, even if there were not seven ways to do something in the core language/stdlib, libraries would add those ways. So, the ecosystem would still have them all and more (eventually).

Personal opinion, but I would say Nim is remarkable in being able to support & manage all this diversity. One does not see Nim style guides like C++ style guides where you are only supposed to use the 5..10% or whatever of the specified language that everyone on a team understands, for example. { Yet! Famous last words... :-) }

> Nim implements just about every paradigm it can think of, and if there are multiple ways to implement a paradigm, it implements them all.

any examples?

The first one most people run into: Nim is roughly as performant as Rust, but it's easier to learn because it's garbage collected. But it's also not garbage collected, if you prefer (with caveats). Want a different flavor of garbage collected? We have three (with caveats)!
thats not a different way of doing same thing, its doing different thing. this not even an argument, if language can provide multiple memory management strategies, in what world is that a bad thing?

and if you somehow confused about choice (of gc), you should stick to default.

also, there is no such thing as "There is Only One Way to Do It" languages. your entire argument is just a circlejerk point.

Is Nim garbage collected? There is no simple answer to that.

When it is garbage collected, how is it garbage collected? There is no simple answer to that.

As stated in my original comment, I prefer languages which are more opinionated than that. Nim is a Swiss Army knife; some people like that, but I prefer choosing a fixed-blade knife to suit my current purpose.

Is C garbage collected? There is no simple answer to that. Link with Boehm (or something similar) and it is. These things are often (with almost any language) aspects of the implementation & deployment, and most mature languages have multiple answers as well. Is Python "compiled"? Well, with Pypy or Cython or etc. it is. (Or maybe it's always at least "compiled" to byte codes run by a slow byte code interpreter.) Etc., etc. I think your standards for "simplicity" or univalence may be, as @SolitudeSF alluded to, unsatisfied by even prog.lang's you like (which you gave no concrete examples of).
> Is Nim garbage collected? There is no simple answer to that.

Yes, Nim v1 is a garbage collected language. It also shipped with custom destructors support https://nim-lang.github.io/Nim/destructors.html.

Nim v2, which is hopefully two releases away, will ship with a memory management scheme called "orc" https://nim-lang.org/blog/2020/12/08/introducing-orc.html

However right now, it is recommended that all new code is written with the `--gc:orc` switch.

I'm jumping in as soon as a robust 3D game engine uses it as a first class language.
...because nowadays the world of software is marketing driven. People often ask me what big company is behind Nim even before asking about its design and features.
It's written "Nim"
One of my knocks against it is using white space for scoping/blocks a la Python.

While it may be great for beginners or for short scripts, over time it becomes a real pain when refactoring. Editors mess up indentation all the time when copying and pasting. You only have to inadvertently make a statement either incorrectly part of, or not part of an if a few times, before you become leery of that choice.

I've been coding for 14 years and I've never had a "whitespace" problem. This just seems like a nitpick from nitpickers.

Coded in C#, python, go, ruby, elixir, nim, rust, javascript, typescript. Not once felt this.

I run into this a lot with Python, where when I manually cut/paste some block, I have to go up and double check all the lines are in the right place, etc. because an autoformatter can't do it correctly and obviously like it can in C++, e.g.
Whitespace as syntax is a somewhat controversial choice. Others will talk about missing semi-colon bugs or other delimiter-not-matching-whitespace bugs. Their counter "You only have to mis-indent an if relative to semi-colons once to be leery of that choice."

Most of the time (more often than Python), you can use parentheses if you really want. Getting everyone else on your team to stick to that formatting convention..maybe not so easy because, well, not everyone shares your opinion/values. :-)

Personally, I'm skeptical of the "great for beginners" point. I've helped a few beginners in Python who had subtle, yet program-breaking bugs just because their return statement was indented to the wrong level. It would have been easier to just use a brace-delimited language and run the autoformatter to reveal any discrepancies.

(Or we could be using a lisp, but that's another problem :) )