Ask HN: Why did Nim not catch on like Rust did?

Nim only went 1.0 at the end of 2019, almost 5 years after Rust went 1.0, and my impression is that Nim has a pretty dedicated and healthy user-base as far as newer languages go. I wouldn't write it off yet.

Probably also Rust having a novel memory management model and being backed by a large organisation (Mozilla) had a lot to do with its early success.

Rust had Mozilla's backing, and later other behemoths like Amazon and Microsoft jumped onto the bandwagon.

Corporate support is absolutely essential for a new language to be taken seriously in the industry. If Go weren't associated with Google, people would have laughed that language out of the room long ago. Likewise, it's difficult to imagine TypeScript ever catching on if it didn't have Microsoft's might behind it (even though TypeScript is actually an excellent language).

Without the power of money, you are nothing.

Rust had a fresh take with borrowing and had backing for years.

Rust also stroke a programmers thirst for learning new concepts (or ego).

It’s basically good vs interesting.

Because language is one thing and community is another thing. I have the same feeling about Crystal.

For me, the pythonic syntax was what made me not want to try it. Of course it's personal preference, but I can't stand anything that uses the indentation level to structure code. I love my curly braces and formatting tools. I imagine I'm not alone in this, so there goes a chunk of people.

  for x in a_list:
    if cond():
      do()
    else:
      other()
    something()

Personally, I don't like "style insensitivity". And it's easy to find others complaining about this feature.

Rust has the elevator pitch down: C but memory safe.

"very exciting features such as macro support, pythonic syntax, transpiles to C/C++/JavaScript, no VM, systems programming language, suitable for hard real-time systems etc" is not a good elevator pitch. Its a little bit of everything with no clear focus point.

So I'd say rust had better marketing.

I think Nim is a bit younger, and took a while to find it's core features. It also now has better support for multithreading with arc/orc. It has a chance at slow and steady growth. It's maybe not the best at anything though it is well rounded, but mainlyfor me brings back a joy in programming.

Nim has excellent C++ FFI. It's not perfect, but capable of wrapping C++ templates, calling constructors, and virtual methods. Though it can be a pain dealing with inner template types and consts. Here's a larger example of C++ interfacing with Unreal Engine: https://github.com/jmgomez/NimForUE

I started using Nim because i wanted to port some of machine learning models written in python with the idea of making them more portable. It was a lot of work as community is relatively small and a new user would end up writing a lot of code.

But Nim has a pretty solid standard library with clearly written code and an awesome community to help with problems. I generally read a lot of standard library code to expand my knowledge of language and discover common patterns which repeat themselves in a lot of real world problems.

C inter-op is really first class, and as far as i know it has one of best C++ inter-op as well, you can take a look at: https://github.com/jmgomez/NimForUE for a real world example.

I use Nim for my work in both professional and personal capacity and also have written about some of it at https://ramanlabs.in/static/blog/index.html

Who is Nim striving to replace? Rust was very clear - an order of magnitude improvement over C++.

It's the same with Julia, yes it was clear who it was trying to replace, but it wasn't 10x better.

The IDE story isn't good yet. That's the main reason, IMO. The VSCode extension is usable but I wouldn't call it great or want to depend on it for a large project.

Also, concurrency is very confusing in Nim. Channels require copying, so you start to look elsewhere. Regular stuff like thread pools and async fit together in confusing ways and it's easy to create multithreaded code that compiles but does not work. It's common to look into a nim "web framework" and have no idea how concurrency works in the framework from the docs or the code. There is one nim HTTP library that does, but I don't think it's very popular.

The main reason IMO:

Nim isn't really known for anything other than being a good general-purpose language. In that sense, it's sorta like Haxe lang.

Other popular languages are T- or M-shaped generalists -- i.e. good enough as a general purpose language but also excelling at 1-3 specialties. You can use these languages for anything but in practice you use them in specific contexts.

* If you're working on a game in Unity3D, you're almost certainly using C#.

* If you're working on ML stuff using Jupyter notebooks, you likely use Python w Pandas etc.

* If you're doing big data processing with Hadoop then it's likely Scala w Spark.

* If you want a very high concurrency messaging backend, then Elixir or Erlang on OTP/BEAM is a good choice.

* If you're making a native iOS app, you don't have to use Swift but you probably will. Same with Kotlin for native Android. If you decide on Flutter instead of native mobile, then you'll use Dart.

However, my boss is never going to make me use Nim, because there aren't any particular use-cases where Nim is known as The Language To Use For That Situation. AFAIK Nim isn't known for any particular libs/frameworks/tools like Django, Rails, numpy/scipy/pandas, PyTorch, Hadoop, OTP, etc.

(full disclosure: I had a hard time finding a good language to replace my Bash scripts and settled on Nimscript, https://news.ycombinator.com/item?id=35756090)

Also *Timing*

Nim came out right after a number of other well-known languages caught on. There are too many other decent and popular languages to choose from. I like Nim, but not a single one of my programmer friends or acquaintances uses it. Whenever I mention it, the reaction is like: "Better to stick with a proven language I know (usually Go/Python/Ruby/Java)" / "Is that like Zig?" / "I'd rather learn Haskell, Rust, or a dependently typed language."

And finally...

I think Mojo is going to hurt Nim adoption.

I couldn't get past the case insensitivity.

Rust has a specific enemy/friend. The borrow checker. People wanna check out what is that legendary beast. Nim is just a reasonable and "bag of assorted stuff" language, like Python.

Indentation sensitivity is ugly.

With a bracket, i can easily read the scopes, block of codes. With indentation, it's harder.

You need a killer feature to gain ground on those traditional, well-established languages in the industry. Only marginally better is not enough for people to invest so much as to introduce a new language in a serious company. This killer feature needs to provide really clear advantage so that a risk-benefit analysis can show that even introduce this new language is a significant undertaking, it is still worth it. For Rust, this killer feature is memory safety comparing to other bare metal high performance languages like C and C++. For comparison, D is a decent improvement to C++, but it is still not enough for people to switch in large scale in the industry, because it does not have that killer feature to stand out.

If someone asked me to describe what Nim is and what it's good at without looking at their promotional materials I couldn't tell you.

Even though I have never used Rust in any significant capacity (tried to do Advent of Code with it, gave up on the first task) I can still tell you what Rust is good at.

I can do the same for C, C++, Java/Typescript, Go, C#, Java etc.

When Rust was able to get rid of a class of memory bugs, undefined behavior, concurrency bugs without a garbage collector, it achieved a breakthrough. You can now write JS or Java VM in a language that doesn't have buffer overflows, dangling pointers and all kinds of other nasty security vulnerabilities.

Nim doesn't GUARANTEE memory safety, so it's basically... better Pascal? It's an iterative improvement that nobody is getting super excited about. Why is it better than D, V, Delphi?

I think instances where transpiled languages becoming more popular than their targets would be the exception not the rule. At the end of the day, you generally are advised to be proficient in the target language to use the transpiled language skillfully or to be able to effectively debug it, and if you're already proficient in the target language, you likely can just write the target language directly and have cleaner/faster/optimal output.

Typescript would be the notable "exception", and even that had huge backing, and I'd still have a hard time believing even typescript has really surpassed javascript in usage.

In my opinion, Nim is too broad. I did some code in Nim to extend/make Python ML (Huggingface) faster and Nimpy was very good. Then I tried to learn how to use Nim for systems programming and barely any guide exist except for open-source libraries.

In my opinion, Nim's ability to be compiled to C, C++, and JS make materials for new users too defragmented (this also almost occur with Clojure, IMO, though JVM/JS/and now Dart targeting make sense with their various niches). And all the tricky parts like Orc/Arc/no GC.

But I really love the Python + Pascal syntax, to be honest. Maybe even more than Lisps.

I really wish I could buy the new Nim book but it's kinda hard as a 3rd worlder to import dead-tree books. Unfortunate.

In answering this, I'd look beyond just the language features and look at the background of how it caught on. What apps were built first. When did the "Rewrite it in rust" mantra take hold. What impact did <system tool> but with colors / nice cli / sensible defaults have on things (e.g. fd / exa / lsd / bat / ...)? What libraries being available made it easy (clap / argh)?

Then look at how the community was built (e.g. Mozilla / conferences / forums etc.)

I've only recently started writing rust (after years of C#, Java, JavaScript, Ruby, Python, and a variety of other languages), and once I got past the basics of understanding borrow checker issues I love it as a language. Personally (for reasons unknown) I prefer brackets over indentation based languages, so Nim is a pretty hard sell there.

    Usage:
      fun [optional-params] [args: string...]
    An API call doc comment
    Options:
      -h, --help                    print this cligen-erated help
      --help-syntax                 advanced: prepend,plurals,..
      -f=, --foo=    int     1      set foo
      -b=, --bar=    float   2.0    set bar
      --baz=         string  "x"    set baz
      -v, --verb     bool    false  set verb

    $ demo --help
    A simple to use, efficient, and full-featured Command Line Argument Parser

    Usage: demo[EXE] [OPTIONS] --name <NAME>

    Options:
      -n, --name <NAME>    Name of the person to greet
      -c, --count <COUNT>  Number of times to greet [default: 1]
      -h, --help           Print help
      -V, --version        Print version

    $ demo --name Me
    Hello Me!

Nim is too timid. Most languages are too timid.

My context: I'm a maintainer of iNim, creator of the Rust channel, No Boilerplate, and a professional python web developer for 15 years.

The features you are excited about in Nim are compromised for the sake of simplicity:

- Macros can't change syntax,

- There's a limit to how real-time the standard language is,

- Compiling to javascript is a nice trick, but if it didn't rely on GC it could compile to webassembly, which is better,

- Ask any advanced python developer: Indentation for syntax is a bad idea at scale. Hell, have you ever used YAML?

What Rust does is a revolution because they solved the problem of memory safety without garbage collection with the Borrow Checker. The knock-on effects are GARGANTUAN.

This was a hard problem to solve, and it makes the language more complex to learn, but it unlocks all the language's superpowers. If you 'cheat' with a GC, you get nothing. Nim started its life, just as most languages did with a GC, and the efforts to keep the syntax the same while offering alternatives are greatly compromised. It's far easier to add GC/RC to a low-level language than it is to remove it from a high-level one, where the whole ecosystem relies upon this behvaviour.

Of COURSE I know about Nim's plugabble GC options. That doesn't impress me at all (though Araq's effort is to be commended). In Nim they are compiler options, in Rust they're libraries. The difference is vital. For example, at a per-variable level, I can choose to reference count with https://doc.rust-lang.org/std/sync/struct.Arc.html if I so wish (I rarely need to because the borrow checker is magic).

If you want python, you can have it inside a Rust macro, sort of like this https://crates.io/crates/inline-python because rust macros CAN change syntax. With Macros and no GC, you can rebuild ANY FEATURE inside Rust, the floor of the abstraction is the metal, and the ceiling is the sky.

This is what Rust is all about: full power to the developer, no compromises. My video on this topic for those interested is: https://www.youtube.com/watch?v=PuMXWc0xrK0

I love both languages, but I can only see one language being the standard next 40 years, and demonstrably so can Linux, Microsoft, Cloudflare, Discord, and many others.

The answer probably lies in non-technical things, like marketing, community building and governance.

The language not having one clear thing it excels at, surely makes marketing it more difficult, so Nim would have needed more effort than normal to properly explain its philosophy to the market.

Community building and governance is also critical. Nim has a fork called Nimskull that was created because of disagreements in the core team. I don't have any insight on what happened there, but regardless having part of your core team splinter off into a separate hard fork is not good for the growth of the project. This is a HN thread from that time: https://news.ycombinator.com/item?id=32021299

Lastly, it's also a matter of luck. Sometimes you just happen to be working on something that becomes more relevant all of a sudden in a way that you couldn't predict, and some other times this doesn't happen. Zig for example became more relevant once M1 Macs came out because now all of a sudden arm64 is not a "theoretical" target anymore. Now the laptop that you want to use is arm, and so cross-compilation suddenly becomes a real thing to worry about.

IMO, if Nim's goal had been a compiled Python, with restrictions where necessary to ensure this was possible (can't add class members at runtime for example), it would be much more popular. I don't mean you could take Python code and compile it, but where design decisions needed to be made, they could have been more compatible with Python instead of choosing the "Nim's not Python so let's use a unique syntax or incompatible semantics" path.

They also need a new BDFL with some tact.