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.
> clap
Isn't clap kind of notoriously bad about executable bloat and compile times?
But that's still relatively small compared to Go, or even Python if you consider needing to bundle the interpreter for "fully statically linked".
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?
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.
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.
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.
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.
Check their online demos.
But I don't see why that precludes Rust from being a good choice in other applications, CLI in particular.
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.
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).
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.
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.
(Rust can also do in-line assembly…)
https://github.com/Genivia/ugrep/blob/a3acf863803a755ff8da8c...
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.
However, by the same token, we might as well count any assembly in the kernel that gets executed due to some syscall from grep.
In any case, I'd still like to see a grep whose inner loop is written in Assembly. :-)
That won't be considered 'inner loop'
I use Go a lot more than Rust. It's like the Java of that world.
I am disappointed when zig calls itself a general purpose language, and 10 years ago Go called itself a system language.
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 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.
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.
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?