Hacker News Reader

Comment by npalli | Hacker News Reader

The primary use case for Rust being CLI is somewhat strange and speaks to non-technical considerations. Does anyone really think there is an advantage Rust brings here over everything else -- Golang, Python etc. Rust community seems to go after "hot" areas in hopes of getting traction, fully understandable. Writing web services is another area Rust people jumped into looking at the popularity of Golang. Most recent "hot" area being crypto. The reality is none of these areas is a sweet spot for Rust and will remain niche (in comparison to other languages). The sweet spot is low level systems programming and displacing C++ (of which there is a real and desperate need). If the community can focus on interoperability with C++ (at the gnarly level), would be make a big difference to adoption.

View on HN

> Does anyone really think there is an advantage Rust brings here over everything else -- Golang, Python etc.

Yes! IMO building CLI tools is one of Rust's sweet spots for a few reasons:

- Rust is great at building small, fast, statically linked executables. Python and a lot of other languages are not.

- Rust has excellent cross-platform support. The stdlib and crate ecosystem do a remarkable job of building abstractions that work across *nix OSs and That Other OS. Go's Windows support is relatively mediocre IMO.

- The `clap` arg parser is great

Ultimately I think the proof is the large number of very high-quality CLI tools written in Rust (things like bat, ripgrep, fd, watchexec). They were kind of a gateway drug for me; I first got into Rust because so many of my favourite CLI tools were written in it, and I wanted to compile/tweak them.

> small ... executables.

> clap

Isn't clap kind of notoriously bad about executable bloat and compile times?

Depends on your definition of "small". Clap will add significantly to the compile time, but your binary won't be too much larger. Rust binaries tend to fall in the range of 2–30MB, depending on lots of things.

But that's still relatively small compared to Go, or even Python if you consider needing to bundle the interpreter for "fully statically linked".

clap adds about 300kb with my usual release mode profile (lto = true, opt-level = 'z', panic = 'abort', strip = true). Bigger than I would like but for most projects I'm OK taking the binary size hit for nicer ergonomics and more features than argh.

The areas you mentioned (CLI, web services, low level systems programming) are not mutually exclusive. Doing a good job on one doesn't mean something else is affected.

CLI - The folks who worked on the most popular command line argument parser (https://docs.rs/clap/latest/clap/#example) made a positive contribution that didn't detract from any other use case.

Web Services - Similarly, the folks working on improving Rust for web services will also make it better for systems programming. In a blog post published today (https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...), they discuss keyword generics, a feature that will be equally helpful for `async` code (helpful for web services) and `const` functions evaluated at compile time (helpful for low level performance).

Low level programming - There is already some interoperability with C++ (http://cxx.rs) and ongoing research into automating this interoperability (https://github.com/google/autocxx, https://github.com/google/crubit).

Feels like there's enough effort in all areas.

I don't understand a request that says "drop everything else, focus on what I think is important". That's not how open source efforts work. People work on what they think is most impactful, what they enjoy working on. As long as they're not hurting any other use case, why stop them?

actually creating a cli with rust is really one of the best ways to use it. it is extremly fast and has a low footprint and if your cli does only one thing well it's probably easy to write opinionated rust.

and clap is probably the best args parser available on the planet. no other language has an args parser that is so easy to use and still extremly fast with a low overhead than rust.

in what world is the arg parser performance critical?

It is not beyond some base-line which golang cobra, python argparse, rust clap all hit. But it's so nice to use I thought there would have to be a trade-off and there wasn't.

When the cli app is called from another process which passes the arguments, and needs the results back fast?

well depending on the language an argsparser can trash quite a lot of memory and become slower than necessary when there is a big argument list. as others said if this cli is also used as a component than it might be important that it is fast. and since claps is so easy to use and has basically no downsides it's stupid to even not at least try it. as said compared to other tools it's really really simple

re CLI, the author of esbuild had an interesting comment about writing it in both Go and Rust and the Go version being faster out of the box https://news.ycombinator.com/item?id=22336284

GC gives you a nice cushion, because it makes allocations fast. However, with a little bit of thought put into memory allocation (such as using arenas with bump allocation), you'd easily beat Go with Rust. The author of SWC did exactly that https://swc.rs/docs/benchmarks

The time to start up a Python interpreter and do meaningful imports is quite painful for a CLI app. If you have Python code and want add a CLI you can live with it, but you wouldn't pick it ahead of time .

This is exactly why. It's also not just the interpreter, it's also one-time costs involved in unpacking PAR files, but deploys are frequent enough that you might hit those delays many times per day.

If I can have a XAML/WinForms like UI dev experience with Rust on Linux, I am sold. Even just a usable rich UI framework on Linux. Cross-platform is a bonus, but since I believe Linux is the future I can live without other platform targets.

We all hate the resource hogging desktop apps that are just browsers (which in turn are just OS'es). That is a niche as wide and as open as the ocean. Cryptography and web frameworks are nice, but not where the action needs to be.

If UI is too complex for Rust, give up altogether on Rust. As C/C++ keeps the win since the nineties and we know the competition will not be held anymore.

You cannot even get it with Rust/WinRT straight out of Redmond, let alone having hopes to get it on Linux.

C++/WinRT tooling is a shadow of C++/CX capabilities (which feels like Microsoft's C++ Builder), and while the same folks are having fun with Rust/WinRT, its tooling is even worse.

I doubt that in five years it will be any close to what C++/CX was already doing in 2015.

Specially since they outsource any graphic tooling responsabilities to the DevDiv folks.

That's sad. I would love to tinker with UI programming on Linux, but it seems like to get anything decent you will have to use QT, which brings C++ as a requirement.

You can have a look at its issues,

https://github.com/microsoft/windows-rs

Note the lack of of safe wrappers for Windows APIs, and still no good way to create the Windows Runtime objects necessary to interoperate with XAML.

Also the basic examples with very little UI code on what is supposed to be a projection for a Windows UI framework.

Thanks. I did not mean XAML literally though, something like that would be super nice for Linux. The project you linked brings Windows RT as a requirement. But just something with the richness of QT + Rust on Linux would be welcome. I am hearing the rust bindings for QT are just a pain and incomplete. I was hoping for Rust to really offer an alternative for C++ here.

Well, there is Slint in that case, from former Qt devs, but it is still pretty much early days.

https://slint-ui.com/

Check their online demos.

Thank you, still early indeed but the project looks promising. I am really hoping for the Return of the Desktop in which episode Rust defeats C++ and we all have a sane, safe, free and memory abiding computing experience.

UI is a poor fit for Rust, IMO, because the natural way to model UI widget hierarchies is rather painful with ownership tracking in the picture.

But I don't see why that precludes Rust from being a good choice in other applications, CLI in particular.

Well, isn´t that a bit damning though? I am not an expert on Rust, so please enlighten me. If it is meant to replace C++, I would expect it to dethrone on the areas where it is king. I am looking at a crap ton of programs with an UI. Your IDE, your text editor, your spreadsheet program, your graphics editor, etc. Most of the modern programs just give up and ship as a full blown bloated memory eating web browser.

There is a gap between the nineties and now, and it is still void.

If you have to constrain it to CLI apps the average developer here on HN needs to write, I don´t see a reason to use such a complex beast as Rust. If you mean operating systems, I can see a spot for Rust. Also database systems or a web server implementation. But that is fairly niche.

For userland cli-apps I am not sure if the added complexity pays of in terms of sufficient performance gains in practice. If you want to write a new implementation of grep, sure. But how niche is that?

So in those cases where you need both type strictness (which I agree should be the default requirement) and cannot have an automatic garbage collector, I can see the value of Rust.

But for what audience is an automatic GC really a problem? Personally I would use Haskell, Java, F# for CLI-apps, but I know there are tons of other options there.

For CLI apps, performance may be important, and Rust offers a performance profile similar to C++. This is exactly the niche where relying on an automatic GC may be undesirable.

But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC. It kinda makes sense if you only focus on management of memory as a resource, but it ignores the whole race condition angle (which very much still exists in GC'd languages like Go or Java).

«But also, I feel that it's generally incorrect to position Rust's safety model as the opposite of automatic GC.»

Agree, that is not what I meant. Rust provides type safety and allows you to without a GC, all while offering top speed. Being able to do without a GC is somewhat of a niche requirement I think. In those cases it is an requirement, Rust would be a top choice.

My point is: there are tons of GUI applications written in C++. And to this day there are still new projects that pick C++ because it needs a GUI. I consider that a bad thing for Rust. Thinking Rust should be at the CLI-apps competition is just a way to avoid C++. It is the wrong contest, and I am not sure if Rust is even able to win that contest because what Rust has to offer (no GC) isn´t of interest for most CLI apps. I think cli apps like kubectl would not be hurt by being GC'ed.

I think that the Rust leadership should identify that GUI is the first city they need to liberate from C++ if they ever dream to replace C++. I just learned some original work has started by various projects, so I keep my fingers crossed.

The question, rather, is why one would want to use C++ rather than something higher-level (e.g. C#, Java, Swift) for a GUI app in 2022. We're long past the point where performance benefits were worth writing the whole thing that way. Most apps can get away without anything C-like at all, and for the few that need that perf boost, it's easier to implement the corresponding part as a C++ library called from higher-level GUI code. In such an architecture, Rust can transparently replace C++.

I see your point, but that also means data marshalling between the higher level language and the rust components. Also, I think GUI is a place where speed plays a significant role. It is no wonder that most GUI's are written in C/C++.

Unless you mean that the lower level GUI code should be rewritten in Rust, so that other languages can provide a higher level interface on top of that. That might indeed sort of work. But the vast amount of work is going to be in Rust. And you still pay some penalty, depending on the mismatch of the higher level language and rust. You will need to have a frictionless integration as between C# and WinForms.

The hard work is on that lower level. A simple text input control takes a lot of engineering. You will still end up with something like QT in Rust.

grep inner loops are coded straight in Assembly. So Rust would be a poor fit.

Yet ripgrep is extremely fast, often faster than grep. Practice beats theory.

(Rust can also do in-line assembly…)

Can you link to the source of any widely deployed grep whose "inner loop" is coded in Assembly?

ugrep has full SSE/AVX support

https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8c...

So does ripgrep... Which is written in Rust. So how exactly is Rust a poor fit?

And that isn't Assembly.

So I guess what you said earlier, "grep inner loops are coded straight in Assembly," was a misrepresentation. And that "Rust was a poor fit" is just empirically wrong.

If I would have to guess it would be codecs.

What do codecs have to do with grep?

grep respects LC_CTYPE, so it has to handle text encoding (or rely on something else that does, like libc or iconv).

However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.

Those are locales. I've never heard them referred to as "codecs."

In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)

"en_US.UTF-8" is a locale. The "UTF-8" part is the encoding of that locale. Codec would be whatever piece of code parses the encoding.

>in the kernel that gets executed due to some syscall from grep

That won't be considered 'inner loop'

CLIs are also a great way to let people experiment with and learn a new language with low risk.

Rust cli libraries very nice to use. Golang cobra decent too, but imposes a lot of TIOWTDI-ish.

I use Go a lot more than Rust. It's like the Java of that world.

Chasing popularity seems to be a necessary evil these days.

I am disappointed when zig calls itself a general purpose language, and 10 years ago Go called itself a system language.

Back in my days, systems programming evolved writing compilers, linkers, os drivers and kernels.

Given that the whole Go toolchain is bootstraped, it fulfills that role quite alright.

Maybe we need drivers and such to strenght the argument, well given the role of gVisor and Android GPU debugger, that seems a case for systems programming.

Maybe still not good enough, then I refer to the F-Secure TamaGo unkernel being shipped as firmware for the USB Armory security keys, or the TinyGo runtime which even ARM refers to on their IoT page.

I’ve seen comments from you several times that echo this point. But it always seems to end conversations, which I find disheartening, because I’d really like to see others at least discuss your point, even if they never adopt a similar view. Your premise seems to be that most devs are overlooking the applicability of ‘managed’ languages in the area of ‘systems programming.’ I think your listing of systems programming topics above is a fairly representative sample and I never see much push back, or any concrete examples, for why a managed language is not capable of being used in the general case.

I agree that examples of drivers, and possibly kernels (outside of Oberon), that utilize managed languages may be needed to really start the conversation, but there really should be a conversation. So, off hand, can you think of any books, technical reports, papers, videos, whatever on this general topic that can point me deeper? At my core as a developer, I am concerned first and foremost with performance (along many metrics, not just wall-clock speed), but outside of hard or soft real-time systems (and soft may have more leeway than is commonly claimed) I really think there are some big wins possible in multiple areas by switching the default definition of ‘systems programming language’.

PS. Sorry for going super OT and for dragging up an almost day old comment.

It is hard to have such conversations, because they tend to be more ideologic than technical.

Most of the systems that we had in such directions, like Xerox PARC and ETHZ endevours, Inferno, Microsoft research, usually failed not because of technical issues (which they had), but because management decided to spend money elsewhere.

As proven by stuff like Android, JavaScript JIT and similar projects, it isn't a MVP product, rather something that you really need to be willing to spend years putting money into to prove a point, and the large majority isn't into it.

Regarding information, the now abandoned Android Things replaced the original Brillo project, whereas Brillo was Android without Java everything C++, Android Things became a subset of Android, where for security reasons drivers would have to be written in Java.

https://developer.android.com/reference/com/google/android/t...

Since Project Treble, Android allows for writing Treble drivers in Java,

https://source.android.com/devices/architecture/hidl

Apple's continuous push for Swift (they even made the point at WWDC 2022 that Objective-C is done and thank him for all the fish) is another example, so anything coming from them. Yes, Swift does count as managed language, as RC is a GC algorithm.

I indeed agree that Go can be used for many systems and adjacent purposes, and is used for many DB engines and network stack stuff pretty well.

But it's relatively more abstract and gives less control than C++/zig/rust. I was just comparing and contrasting the marketing.

Go was once marketed as systems language even if the authors intended it more for systems adjacent stuff. Now everyone advertises their language can write web services it seems. I mean why is it out of fashion to just admit a language is mainly intended for low level stuff?

Reply on news.ycombinator.com