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.

Considering that the Zig Software Foundation not only doesn't have any big corporate backing, but also made an explicit point of always being fully independent, and the fact that we're overall doing fine, I beg to disagree.

https://ziglang.org/zsf/

Big tech wants you to think that you're nothing without them, while in truth there are plenty of situations where small realities can absolutely out-compete them:

https://kristoff.it/blog/the-open-source-game/

If you want a proxy variable to observe wrt Zig's growth, look at the star history on GitHub: we are today more popular than Rust was at our age.

https://star-history.com/#ziglang/zig&rust-lang/rust&Timelin...

...and in fact some big tech companies are jumping on the bandwagon, like Uber, but that's an after-the-fact thing.

https://www.uber.com/en-US/blog/bootstrapping-ubers-infrastr...

> If Go weren't associated with Google, people would have laughed that language out of the room long ago.

Nah, Go gets right certain critical things, and that's why is popular. Being from Google doesn't guarantee anything, look at Dart for example.

https://kristoff.it/blog/why-go-and-not-rust/

> If you want a proxy variable to observe wrt Zig's growth, look at the star history on GitHub: we are today more popular than Rust was at our age.

Which does not say anything given Githubs growth and change in usage patterns from 2010 to today.

Rather, I would say Zig is lagging far behind Rust and it should have had multiples higher stars than Rust at the same time to be on "equal footing" given the multiples larger software community that exist today.

To be fair, Nim isn't dead either. It's steadily coming along, with new developers, features, and libraries all the time. Sure it hasn't had the meteoric growth of Rust, but it's still climbing.

"Considering that the Zig Software Foundation not only doesn't have any big corporate backing, but also made an explicit point of always being fully independent"

Zig has a VP of Community and it's important how the role promotes and evangelize the language for developers. Another example: Crystal appointment a new Community Manager recently, and now have developer "ambassadors" - to promotion the Crystal language. It's a shame that Nim has no equivalent role or initiave to grow the language community.

That also ties into governance. The VP of Community position exists because the creator of the Zig programming language decided to create a non-profit corporation for the language as soon as he went full time with it, and then made the VP of Community position be the first hire.

he probably exaggerated saying that without money you are nothing, but it's (imo) pretty undeniable that money can be a great springboard for a project of that magnitude

Dart is a no go especially because Google is not really backing it.

While I agree that corporate support plays a huge role with market share and acceptance, I disagree that Go would have been laughed out of the room. Very likely that a language made by Griesemer, Pike, and Thompson would have got lots of attention. Arguably enough to catch on anyway. These men are already famous, in programming circles. Case in point, look at Jai, with just the star power of Jonathan Blow and how well known that it is. In fact, would not bet against just Ken Thompson (by himself), creating a new language and whether or not it would catch on.

I don't think that Jai is a very good example. I doubt a single one of my coworkers will have heard of it but they've all heard of Go.

For another voice in the room, I know who Jonathan Blow is, relatively familiar with his work, I think he's making a game engine? And know he does coding streams, and don't think I've heard of Jai.

And I know plenty of software folks who wouldn't know who he is at all.

Jai is still in closed beta, it's not being promoted at all yet.

jai is not well known and it being a language and closed source makes it a total non-starter

I don't think it would be so well regarded when considering the motivation that Rob Pike and Ken Thompson had for making the language the way they did.

What was their motivation?

“The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.”

Creating a tool that the constant stream of fresh out of college guys can't screw up with.

I see. And this is why there is no Maybe type, and an “unset” value is silently set to 0? Because fresh grads would find this easy to work with?

In general, the language lacks both complex features and low level primitives that would be useful for building anything more substantial than network glue code. Go codebases are often noted for the egregious use of copy and paste. Not that I can say that there's never a time and place for that, but it's not the kind of thing you'd be excited to work with. Give me the language Ken Thompson would solve problems in, not the language he gives his goons to solve problems in.

I think the issue is that it's hard to trust the language to go over its current limitations without commercial backing.

This is especially true for a language like Go which had limited functionality and a complete lack of tooling (eg. no package manager, no generics) for a long time.

I didn't pick up Rust until a few killer projects were released. Before that async was a complete mess. For a long time we didn't have the ? operator.

> In fact, would not bet against just Ken Thompson (by himself), creating a new language and whether or not it would catch on.

You mean like Limbo?

The counterexamples are definitely older like Python, Ruby, PHP. JS is a special case.

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.

This post nails it.

> I think Mojo is going to hurt Nim adoption.

Mojo is interesting. Python is a genuinely terrible language with an unparalleled library ecosystem. I hope something saves me from the tyranny of Python. But I'm not optimistic.

Mojo is not a programming language, it's a waitlist you can signup for.

Nim has the advantage of provably existing and being fully open source.

I like Nim, still learning and rewrite some of my personal Java projects in it. Yes, I had same Pascal/Python exposure as well.

Well, agree with "other than being a good general purpose language", Nim doesn't have strong marketing point. Remember many years ago Rails attracted lots of developers to learn Ruby?

Hmm I wonder if Crystal will also share the same fate...

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

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?

There is more to software engineering than just memory safety.

The question is not whether Nim is better than Rust, the questions are:

Does a C++ developer have reasons to switch to Rust

and

Does a C++ developer have reasons to switch to Nim

Why switch? Is it that weird to know and use more than a language?

In case of adoption, both answers are yes, because Rust and Nim don't occupy the same niche. The reason why Nim has not caught like wildfire is that its niche is often shared with Python or Go, which have a much larger mind share.

Which is why asking this question from the memory safety point of view misses the mark.

It is not. I use 3 languages on a weekly basis for work, and 2 more for hobby stuff.

It's about use cases- frontend, jvm, systems/low-level, realtime/sockets, ML. There could be more overlap, but for reasons they don't.

Sure, but does nim have any breakthrough innovations in any of those other areas?

Do you need breakthrough innovations to adopt a language? Listen, I like Rust and it has its niche for some of my projects, but not all projects should be written in Rust. Least of all because it is an innovative language. That works well as a marketing slogan, not as a factor to decide which language is more apt for the project at hand.

Do I need memory safety? If yes, Rust is the best choice.

But other times I need quick iteration times (Python, or maybe Nim) or immutability, or painless concurrency (Elixir), or meta-programming (Lisp & derivatives). I don't spend any time to ask myself whether a language is innovative, when I got deadlines and results to deliver.

> Do you need breakthrough innovations to adopt a language?

No, but the question wasn't "why has literally nobody on earth adopted nim?" (Which would obviously be false). The question was "why isn't it as popular as rust". There are thousands of languages out there. To be at the top of the pack, nim would have to really stand out somehow. Nim hasn't, so its a little bit niche somewhat mid-popularity language. Which is totally fine, not everything has to rule the world. However that is the reason why it is not ruling the world.

> To be at the top of the pack, nim would have to really stand out somehow. Nim hasn't, so its a little bit niche somewhat mid-popularity language.

I'm not sure about this argument. If Mozilla had created and pushed Nim instead, would it be as popular as what they did for Rust? I'm sure the marketing department would have found some angles to push for Nim. Maybe it would have been memory management options or that its somewhat like a compiled version of Python. I'm sure corporate minds would have figured something out. So if we could see alternate dimensions, where Nim was under Mozilla, it might be nearly as popular.

As it is, some would argue that Rust is somewhat niche, reserved for cases where memory safety without a GC is both necessary and critical. Rust ranks 20th on the TIOBE index. While nothing to sneeze at, nobody knows if it will go higher on the charts or fall back down.

> If Mozilla had created and pushed Nim instead, would it be as popular as what they did for Rust?

In my opinion, definitely not. I knew people excited about and working in Rust back in ~2016 when very few people knew about Rust. They proselytized me, I converted others, et cetera. It's all grassroots spread and has nothing to do with Mozilla marketing.

And that grassroots marketing spread rapidly and easily because of Rust's killer unique features.

Yes, many actually.

Yes, so if we get away from the elevator pitch, Rust provided:

* Cargo for managing dependencies and a sensible module system

* Option/Result based error handling without using null

* Zero (runtime) cost abstractions like iterators and async

Nim does guarantee memory safety if you don't use unsafe features like raw pointers.

Does Nim make you explicitly enter an unsafe mode to access raw pointers?

What that even means? Just random words. unsafe block is just an illusion and doesn't prevent any bugs. Don't get me started on the cult that shames repos that use it.

Sure, but upon review it was found some of the code was using unsafe without reason, and people submitted pull requests which made the code better. It's better because you are sure it doesn't have a memory unsafety bug, even if the code "looked" right before.

Given how Actix was used for benchmarking, I'd imagine that there was a reason the original developer wanted to use unsafe a lot. Nginx was written in pure C, and that is an act of wizardry. I can't imagine wanting to do any work for a language with a 'community' full of people eager to flame or do worse things to developers who don't meet their pompous definition of safety.

No, what's the point of that? It's not hard to recognize unsafe code.

You can't grep for it, but you can grep `unsafe`

`ptr`, `addr` and `cast` are the only ways to introduce unsafety, as I understand it. You have to run three greps, but you can definitely grep.

`grep -w 'pointer|ptr|addr|cast'` would do it in one.. (One can surely do a shell alias called `find-unsafe`..).

Finding unsafe constructs in Nim code is not that hard, at least at the same level of accuracy as `grep unsafe *.rs` (e.g. inside comments & strings, etc.).

To evaluate the power of this general line of argument, consider -- if Nim shipped with a `find-unsafe` source-level search utility, how much would this change your mind?

The advantages of a language that uses words rather than random punctuation.

Rust doesn't guarantee memory safety.

I think anything that can generate a trivial hello world program that doesn't leak memory is better than V.

Besides the attempted slap on V coming from "out of left field", in regards to what the above commenter was talking about, V doesn't leak memory like that. V, since becoming beta (last year), uses an optional GC and does flexible memory management[1]. Giving users choices, somewhat like D and Nim do.

It provides 4 choices: default optional GC (that can be turned off), autofree (either alone or with GC), arena allocation (-prealloc), or manual memory management (-gc none). This flexibility has already been proven, like with their Vinix OS project[2].

Lastly, for developing languages going through alpha and beta phases, think that people should acknowledge how the process works and update their information. Rust or Nim, for example, aren't the same language they were 5 years ago or when still in beta.

[1]: https://github.com/vlang/v/blob/master/doc/docs.md#memory-ma... (4 ways to manage memory in V)

[2]: https://github.com/vlang/vinix

If you don't use `unsafe` then it guarantees it barring compiler mistakes. The compiler has had issues with memory safety before, they were found, and they were fixed. There might be some left lurking, but they are extremely unlikely since people are using it in production and haven't seen anything weird.

If you use `unsafe` you have to make sure of it yourself, but you can easily grep for this keyword and see where the monsters lurk.

The issue is that any Rust code is going to be targeted at performance processing (since otherwise you would write it in a higher level language). And for performance processing, you need to use unsafe (because at some point, the most efficient thing is getting or setting data at a certain memory address without anything extra). Look at any big Rust project, like Amazon Firecracker, and its littered with unsafes.

You really don't, I worked on a Rust project:

https://github.com/ujh/iomrascalai

it doesn't need unsafe code despite being performance-optimized

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 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.

Sorry to be a pedant but it's likely more like: "C++, but memory safe".

I feel like rust has been having a lot of success recently in areas that were previously dominated by c not c++, but i'm not that familar with the rust landscape so maybe i am mistaken.

No, you’re right. There’s just a crowd of people that go “Rust is more complex than C and C++ is more complex than C therefore Rust is more like C++ than C.”

Yet tons of people (like myself) who have preferred C to C++ still like Rust more. Categorization just isn’t that simple.

But without the C++ awkwardness

Pitch: Like Python, but faster and multicore.

At least it's the reason I tried it once.

It was not a bad experience.

That is definitely a decent pitch. I think if nim oriented itself around that pitch more it would do better.

However i do wonder how big the market is for "python, but faster and multicore". I suspect it is smaller than "c but safe".

The problem with that for me is "like Python" implies a HUGE collection of libraries I can use to connect to pretty much anything.

With Python I can just search "python <thing>" and find popular, well-maintained, libraries to do <thing>. I can't do that with Nim. Most of the stuff I find seems to be 5-9 years old and have no updates since.

Nim allows you to use libraries for C and C++, as well as Python with the NimPy library, so the situation is not that bad if you don't mind getting your hands dirty.

Except THAT library only supports Python 2.7.x

sorry what do you mean?

They're poking fun at how sometimes you'll find a Python library that does exactly what you want with an interface that feels incredibly intuitive, but you end up finding out it was never updated to work in Python 3.x, only 2.x.

Though I'm not really sure how often that happens these days unless you're trying to write code that's using an old protocol that's fallen out of favor, like IRC, FTP, or Gopher.

Python will probably also be "faster and multicore" with latest proposals, so it's not a very good pitch.

Python has been getting faster, but Nim I'm sure is still a few multiples above Python.

The problem is that CPython was never built with efficiency in mind and now it's hard to add it.

How about the motto: “Efficient, Expressive, Elegant”?

I don't think that is particularly good either. It is too vauge. Just subjective adjectives. Nothing concrete.

Not to mention, everyone aims for those traits. It is not unique enough.

Everyone? Python doesn't aim for efficient. C++ doesn't aim for expressive or elegant.

If you told me to guess what language that motto is from, I'd have no idea. It could be basically any of them. If you say "C, but memory safe" I know it's Rust.

Well, that's only because Rust is better known.

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.

This was a point about 10 years ago, then history settled the matter and people are using Python or not using it mostly because of what they have to do than because of syntax.

I do have a customer using Python. We had our share of bugs introduced by wrong cut and paste or manual git conflict resolutions after merges for code like

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

That latter something() was actually outside the loop but got inside and tests didn't caught the error. There is the variant where something() should be inside the loop but got moved outside.

Have to agree with that point. Significant numbers of people would not give it chance, based on that reason alone.

There is possibly another argument to be made, that Nim is not close enough to Python. Look at how people have gravitated towards Mojo and it being a superset. Therefore, Nim could be argued as kind of trapped in a no man's land, where not of the C family and not close enough to Python to be an easy enough switch over nor strong enough to gain mass appeal with its own identity.

Same here. Similarly, I stay away from macros. I think they have a detrimental effect on Rust’s development as well, where sometimes proposals of semantic features are rejected, because something can be done with macros on the syntax level. Maybe it can, but each time it’s inferior. So not only does a user need to deal with macros written by others, but some things aren’t going to get macro-less solutions and the user is forced to write macros from time to time as well (if there isn’t a crate with them ready). And don’t even get me started on the effect of proc macros on compilation times.

For me it's the exact opposite. Rust's use of unnecessary punctuation and less-than/greater-than signs as brackets is one of the things that makes me not like it.

I use Nim rarely exactly for this reason. I dream of a transpiler. I would totally be the clown who would transpile to Nim which may be transpiled to C.

That’s a very good observation.

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.

> 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.

Agree on both points! And I am starting to realize that governance is the key element. A better governance would enable better community building and with a big community and a decent governance someone good enough at marketing would be able to figure out a way to put in the additional effort. But hey guys, where can you find a tech community in which we are all pretty bad at marketing and very bad at evangelizing? I think it is a nice value proposition for those who like to build stuff… ;)

I think contributors should focus first on building compelling cases of using Nim in specific niches (like jmgomez is doing for unreal engine) and we should at some point try to meet and start working on the governance issues. It will take some time but I am still confident. The language is such a joy and the community - albeit small - is full of outstanding people.

Btw, you have done outstanding work on zig, congratulations to you, Andrew and the rest of the community, it is inspiring to see! I find very interesting how you decentralize community management empowering people to build their own communities. At least that is what I gather from following from far, I might be off. Would love to know more if that was an explicit goal or the result of some happy coincidences.

> Btw, you have done outstanding work on zig, congratulations to you, Andrew and the rest of the community, it is inspiring to see! I find very interesting how you decentralize community management empowering people to build their own communities. At least that is what I gather from following from far, I might be off. Would love to know more if that was an explicit goal or the result of some happy coincidences.

Thanks! Having the communities be decentralized was a deliberate decision from early on. Andrew wanted to go in that direction and to me made perfect sense so we never even stopped to talk about it much.

In practice there are two simple considerations that make it a no brainer for us:

- eventually your communities will be decentralized / independent whether you like it or not (eg today there are plenty of python sub-communities depending on whether you use python for webdev, data science, devops, etc)

- a central community hub means that you need to spend money and communication budget on a team of moderators. given how the ZSF financial strategy, we have to stay small if we want to succeed, so that means giving up things like having a moderation team.

Very clear and a smart decision that paid off!

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.

Basically a language needs something I can use to sell it to other people in the organisation.

I can't just cowboy stuff with $language because other people would need to maintain it.

C# is the de facto language for Unity-based software.

With Go I can cross-compile a single executable blob and distribute that easily to a heterogenous environment. It also does concurrency _really_ well.

Python is the one that the data analysts know how to use

Rust is for those cases where none of the above are fast enough or memory efficiency is a big thing.

What does Nim do?

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.

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 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.

Nim is not transpiled, and you don't need to know any C to effectively use Nim.

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

Then just ignore it. As long as you don't want to do something crazy, you don't even need to know that the feature exists.

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.

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.

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.

I don't know about all your other questions, and I realize your post was more about "why Rust?" rather than "why not Nim?", but that said the https://github.com/c-blake/cligen Nim CLI framework seems much lower effort / ceremony than even Rust's `argh` and is just about as old as `clap` (both cligen & clap started 8 years ago in 2015 - Rust argh is much newer).

There are over 50 CLI utilities in Nim at https://github.com/c-blake/bu, many of which do something novel rather than just "re-doing ls/find/cat with a twist". While they are really more "ls/ps construction toolkits" with some default configs to get people going, I think https://github.com/c-blake/lc and https://github.com/c-blake/procs are nicer than Rust alternatives. I mention these since you seem interested in such tools.

It's more that those tools were what come to mind when I specifically think of my exposure to the existence of rust. Its perhaps not that the tools were there, but that they were well known (and known for being written in rust).

Anecdatapoint - I've never heard of literally a single one of the utilities listed on the bu page.

Regarding cligen, right from the start clap wins on producing idiomatic output. Compare: https://github.com/c-blake/cligen#cligen-a-native-api-inferr...

    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

With: https://docs.rs/clap/4.3.8/clap/#example

    $ 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!

Aesthetics matter, and I know which one I prefer by a long shot. Things like that leak through into every "rewrite it in rust" cli. There's a lot of rust things that just seem to make good decisions like this easy.

There is a way to disable the type column and embellish parameter descriptions or even replace the entire generated string, all at gradual investment of time, though docs can always be better. I disagree that it's a bad default since types help users know `count` is not a float (e.g. count per minute). How many times has there been some "delay" parameter you weren't sure could take fractions of a second?

Anyway, cligen needs just 1..2 lines of code (`import cligen; dispatch fun`) to infer & generate all that from a pre-existing proc/func. Very low ceremony. `clap` & `argh` have more intricate specification/convention languages to learn, like most arg parsing / dispatching tookits.

CLI tools are a diverse lot. What help text similarity exists largely flows from toolkits or their defaults. E.g., Rust `argh` output differs (at least on their home page) from Rust `clap` in showing default values. So, your own 2 reference points already disagree on that default, at least in their examples (likely all 3 can say "whatever" with work).

This diversity is one reason why inflammatory rhetoric like "wins" or "good decisions" for ultimately context-specific (&tough!) judgement/aesthetic calls about defaults is unhelpful. There may be a little "back pressure" from users and from completion systems like Zsh's - but if you look into Zsh compctl you will see dizzying diversity of CL syntax & help formatting. The cligen defaults at least let you use _gnu_generic (as can both `clap` & Rust `argh`, I'd guess).

There are various reasons for all that diversity. Users after running -?/-h/--help/etc. do prioritize "the information" (for some value of that) over the formatting, as with most documentation. The diversity is also not going anywhere, as evidenced already by Rust `clap` & `argh` discrepancies. Devs just like different things. The docopt people like to start closer to free-form text (but do have a help parsability requirement).

I did not expect you to be aware of bu/ tools. I just thought you might be interested in CLI tools outside a standard repetitive bubble. Most people don't seem to like CLI tools like you & I do.

Using Rust in firefox was likely the most persuasive app for "can be used for real things", as has been mentioned (by almost everyone). I kinda doubt `clap` (inspired much of | saved much dev time for) `rg/ripgrep`, `exa`, `fd`, or whatever, for example (though it probably did help for greater uniformity).

A fun fact, ripgrep used docopt for arg parsing in its original release: https://github.com/BurntSushi/ripgrep/blob/b1c52b52d6eed5b24...

I switched to Clap pretty quickly after the initial release though. Like a couple months: https://github.com/BurntSushi/ripgrep/pull/233

I do currently have loose plans to move away from Clap to lexopt. But I don't know when or if that happens.

I think if nim supported rust as a backend, with usable support for crates, that would be a new killer feature.

I've only played with Nim a little, but I found it really compelling and honestly quite fun to write. It's quite elegant and economical and the performance is impressive for the lack of ceremony.

However, the language itself still seems to be a little in flux (v2.0 is nearly out, and my impression is that v3.0 might finally be a nice stable language) and the BDFL makes some language decisions (and holds some opinions) that I'm not fully on board with, and I think make the language a little less than it could be. Obviously that's subjective though.

I'll definitely keep an eye on it and check back in periodically, but I'm also not going to write any non-disposable code in it for now.

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.

Rust belongs to a small collection of languages that can run code with minimal latency, and on hardware directly, ie without an OS. (Others are C, C++, Zig, and ADA).

Rust can be argued to be a nice addition to the group. You can view it as "The nicest (in some qualities) in a niche". Nim doesn't have this sort of edge.

Niceness is subjective, but Nim is just as valid an addition to that group. Nim compiles to C and has had an --os=standalone mode for like 10 years from its git history, and as mentioned else-thread (https://news.ycombinator.com/item?id=36506087) can be used for Linux kernel modules. Multiple people have written "stub OSes" in it (https://github.com/dom96/nimkernel & further along https://github.com/khaledh/axiom).

While it can use clang as a backend, Nim does not rely upon LLVM support like Zig or Rust (pre-gcc-rust working). Use on embedded devices is fairly popular: https://forum.nim-lang.org/search?q=embedded (or web search).

Latency-wise, for a time, video game programming was a perceived "adoption niche" or maybe "hook" for Nim and games often have stringent frame rendering deadlines. If you are interested in video games, you might appreciate https://github.com/shish/rosettaboy which covers all but Ada in your list with Nim being fastest (on one CPU/version/compiler/etc). Note, however, that cross-PL comparisons are often done by those with much "porting energy" but limited familiarity with any but a few of the PLs. A better way to view it is that "Nim responds well to optimization effort" (like C/Ada/C++/Rust/Zig).

Pretty cool; didn't know that.

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.

Rust people talking about 'revolutions' love to ignore that memory safe languages without garbage collectors have been around for years. Ada+Spark, Cyclone, even D all made large steps forward in this area long before Rust was ever a thing.

Popularity counts. Find all those languages in this graph, then find rust. https://redmonk.com/sogrady/2023/05/16/language-rankings-1-2...

If popularity is what counts, then Rust is only a revolution in marketing and evangelizing.

Linus Tovalds is not an easy man to please. You're saying he's been fooled by marketing?

Sometimes tech is really good, dude, it's ok, don't die on a weird hill, not everything is shit.

I don't think Linus was pleased or fooled. I think that there hasn't been a bunch of eager beavers trying to write Linux drivers in other languages until Rust.

C++ was rejected as a driver language. All those other languages you mentioned also are also not suitable. Why could this be?

I don't know about Ada+Spark, Cyclone, D, but, since it can compile to C, you can write Linux kernel modules in Nim without Linus' permission / specific "help" from the Linux kernel team: https://forum.nim-lang.org/t/10303

(Yes, not stock Nim, but in that Araq expresses an interest in that thread in supporting said in stock Nim.)

This is one advantage to a C/C++ target in addition to trying to optimize the actual emitted assembly from gcc/clang/etc. It also helps when LLVM may not support your CPU, but you have a C compiler, such as in some embedded spaces. There are trade-offs, of course, as with everything.

Linus and many other people hate C++ for having strange compiler rules and a kitchen sink approach. Ada, for a long time, was linked to a proprietary government supplied compiler, and also did not have many volunteer developers available. Cyclone was garbage collected, and Linus prefers not to deal with garbage collecting. I don't think he's ever commented on D, it's an obscure language.

The problem with WebAssembly isn't that Nim couldn't compile to it (which it can), but that WebAssembly can't do anything without JavaScript.

WebAssembly is not just for the web. Please take a look at wasmtime[1], wasmer[2]. It's the future of computing.

You might want to read this iconic tweet[3]

[1]: https://wasmtime.dev [2]: https://wasmer.io [3]: https://twitter.com/solomonstre/status/1111004913222324225

We're not talking about hypotheticals. Rust wasm is used in production now. https://developers.cloudflare.com/workers/tutorials/hello-wo...

Emscripten and experimental backends hardly count as support for Nim. Python can run in webassembly by the same token, but no one would. The standard rust compiler compiles directly to webassembly, natively, with the stable toolchain.

In other languages, yes, the js bridge is a problem. However, not only will this be fixed in browsers at some point, but rust is so fast that TODAY yew.rs, a mature wasm framework, is faster than react.

My thoughts are better explained in this video https://youtu.be/P4LMfkFLRsI

Doesn't Rust with WebAssembly require any JavaScript to run?

If not, can you show me a webpage that uses WebAssembly and doesn't contain any JavaScript?

If yes, what is the advantage over just compiling to JavaScript?

> However, not only will this be fixed in browsers at some point,

This has been promised for several years, and is still nowhere to be seen.

> yew.rs, a mature wasm framework, is faster than react.

Being faster than React is not a high bar.

My apologies, it's faster than svelte, not just react: https://www.youtube.com/watch?v=4KtotxNAwME

I couldn't get past the case insensitivity.

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.

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

I have no idea what Crystal is either :D

Crystal is a compiled, statically typed version of Ruby.

I had the impression that Nim was a bit lower status amongst compiled languages because it wasn't a full compiler. It just outputted C code. Not sure if that's still the case.

it was not suitable for real-time systems few years ago, they undefaulted the gc few patches ago (in favor of orc), however even using the same rust's memory management, you're gonna have 100% of the heap objects to be traced; rust ownership model allows you to avoid tracing (such as arc) when they are not strictly necessary. that said i really don't like rust and all its approaches, i strictly recommend to have a look at nim;

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.

So... you don't indent your bracket blocks?

Algorithm to read scope:

- Step 1: Find open bracket

- Step 2: Find closed bracket

With indentation, the algorithm now becomes:

- Step 1: Find something which seems to open a scope.

- Step 2: Scan all indentation level until it's done.

The difference is huge here.

Algin your method to the top of your screen. Now scroll one more line down. According to your algorithm, it's now impossible to know which line belongs to which scope.

I have a different algorithm:

- Find first indented line

- Find next unindented line

If that does not work for you, your code is bad.

finding open and closed brackets is a massive chore in mis-copied code, so indeed having scope open by spaces makes things very clear and non-ambiguous. Using whitespace for readability and not using it for scope control is one of the many bugs in the design of programming languages like Java. In my very humble opinion.

Step 1: Find an indent increase.

Step 2: Find the first place where the indent becomes lower.

It's not hard, human vision is naturally designed for this. What is hard is finding a matching bracket when the code is not indented properly.

Poor name and no major backing