Live data from Hacker News

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

news.ycombinator.com

131–139 of 139 posts

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

#131
post #124

Earlier quoted context omitted.

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?

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

#132
post #128
post #113

Earlier quoted context omitted.

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…

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: htt…

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

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

#133
post #131

Earlier quoted context omitted.

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?

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.

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

#134
post #131

Earlier quoted context omitted.

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.

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

#135
post #132
post #128

Earlier quoted context omitted.

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: htt…

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, clig…

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.

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

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

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

#137

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

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

#138
post #137

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…

Pretty cool; didn't know that.

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

#139
post #106

Earlier quoted context omitted.

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

Post reply on HN