6 ms·

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 brin

by npalli 4y ago

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.

chakkepolja 4y ago
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.
- pjmlp 4y ago
  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.
  - throwaway17_17 4y ago
    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.
    - pjmlp 4y ago
      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/things/userdriver/UserDriverManager 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 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.
  - chakkepolja 4y ago
    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?
merb 4y ago
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.
- sigmonsays 4y ago
  in what world is the arg parser performance critical?
  - renewiltord 4y ago
    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.
  - spfzero 4y ago
    When the cli app is called from another process which passes the arguments, and needs the results back fast?
  - merb 4y ago
    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
exceptione 4y ago
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.
- int_19h 4y ago
  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.
  - exceptione 4y ago
    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.
renewiltord 4y ago
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.
meitros 4y ago
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 https://news.ycombinator.com/item?id=22336284
- uaksom 4y ago
  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 https://swc.rs/docs/benchmarks
rich_sasha 4y ago
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 .
- adamsb6 4y ago
  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.
nindalf 4y ago
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 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-generics.html 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 http://cxx.rs) and ongoing research into automating this interoperability (https://github.com/google/autocxx https://github.com/google/autocxx, https://github.com/google/crubit 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?
ripley12 4y ago
> 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.
- dralley 4y ago
  > small ... executables. > clap Isn't clap kind of notoriously bad about executable bloat and compile times?
  - vlmutolo 4y ago
    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".
  - ripley12 4y ago
    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.
hrpnk 4y ago
CLIs are also a great way to let people experiment with and learn a new language with low risk.

by npalli 4y ago

chakkepolja 4y ago

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.

pjmlp 4y ago
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.
- throwaway17_17 4y ago
  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.
  - pjmlp 4y ago
    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/things/userdriver/UserDriverManager 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 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.
- chakkepolja 4y ago
  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?

merb 4y ago

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.

sigmonsays 4y ago
in what world is the arg parser performance critical?
- renewiltord 4y ago
  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.
- spfzero 4y ago
  When the cli app is called from another process which passes the arguments, and needs the results back fast?
- merb 4y ago
  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

exceptione 4y ago

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.

int_19h 4y ago
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.
- exceptione 4y ago
  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.

renewiltord 4y ago

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.

meitros 4y ago

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 https://news.ycombinator.com/item?id=22336284

uaksom 4y ago
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 https://swc.rs/docs/benchmarks

rich_sasha 4y ago

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 .

adamsb6 4y ago
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.

nindalf 4y ago

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 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-generics.html 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 http://cxx.rs) and ongoing research into automating this interoperability (https://github.com/google/autocxx https://github.com/google/autocxx, https://github.com/google/crubit 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?

ripley12 4y ago

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

dralley 4y ago
> small ... executables. > clap Isn't clap kind of notoriously bad about executable bloat and compile times?
- vlmutolo 4y ago
  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".
- ripley12 4y ago
  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.

hrpnk 4y ago

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