4 ms·

You can build a CLI in Rust with a better performance and runtime guarantees with far less skill and have a better time doing it. Java doesn't even have null s

by sn9 2y ago

You can build a CLI in Rust with a better performance and runtime guarantees with far less skill and have a better time doing it. Java doesn't even have null safety or ergonomic algebraic data types.

pjmlp 2y ago
Scala and Kotlin also exist, and Rust's place is for systems programming not CLI stuff. Besides people here sometimes have a hard time understanding English, given that I acknowledged Rust being faster.
- nindalf 2y ago
  Your assertion that Rust isn’t well suited for command line programs contradicts reality, where developer tools for multiple languages are being rewritten in Rust. The new bundlers, linters and formatters for JavaScript and Python (the most popular languages by far) preferring Rust and gaining massive adoption tells me that Rust is pretty well suited to CLI programs. And the success of ripgrep, mcfly/atuin, zoxide, hyperfine and starship, just reinforces the feeling that yeah, CLIs written in Rust can succeed. So yeah, strongly disagree with you about Rust’s place. But from your previous comments I also know you’re very knowledgeable about Rust so I’m surprised you came to this conclusion.
  - pjmlp 2y ago
    Don't mistake Rust Evangelism Strike Force, and joining the hype cycle, with the suitabitility for writing CLI developer tools there is nothing there that requires the use of borrow checker. Depending on how many years into the past of HN headlines we would search for, it would be Go, Scala, Haskell, Ruby,... Maybe all those Rust CLIs will be all being rewriting into Zig, as soon as version 1.0 gets out. Roc language is already one of the first.
    - nindalf 2y ago
      I've been on HN for a while, I saw the previous hype cycles. I have no doubt we'll see a Zig hype cycle as well. One of the reasons Rust succeeded, especially in CLI was 1. Low fixed memory overhead (compared to most popular VM based language - Python, Ruby, Java). 2. Startup time is nearly instantaneous, compared to the same languages. Don't have to wait 50-100ms or so just to start executing code. 3. Run time is faster as well, especially so for programs like ripgrep that use SIMD. 4. Single static binary with no dependencies. Didn't need a VM or toolchain to be installed on the user's computer. Having a great CLI library like clap.rs brought it all together. If you think this is simply a cycle and Zig will replace Rust, I'm slightly skeptical. Rust had an easier time competing with the status quo because of the 4 advantages it had. Zig however, will have to compete with Rust. Sure, you can start ziggrep, but it'll be about equal in all these 4 factors. So why would anyone adopt something that has fewer features than ripgrep and about the same performance, memory consumption and ease of use? Just hype? Some people will, but not enough to get the critical mass ripgrep has. That's why I'm bullish about Rust - the performance of existing codebases means that in many cases, it's hard to migrate away from it, or replace Rust programs with reimplementations. You'd have to be getting something really unique that Rust doesn't offer. You said Roc, and Roc is actually a great example of benefiting from something unique. Roc plans to reuse the Zig compiler's library that emits LLVM bitcode. There's no Rust equivalent. But I'd argue that that's pretty niche. How many other examples are there of Zig libraries that have no Rust equivalent? Something that would make Zig the no-brainer choice over Rust, even if you had to reimplement in Zig. Again, I'm sure people will try to rewrite things in Zig. But I'll confidently assert -> the most popular toolchain for Python in 5 years will be Rust based, not Zig or any other language. $10 on that.
      - whytevuhuni 2y ago
        I think a really important benefit is going to be binary size. That's what initially made me dislike Rust quite a lot. And for CLI tools, you need those to be tiny. You're going to many of them, and you'll want to build a whole distribution, which you'll want to be small (for small images, small containers, etc). Another benefit (that Zig won't offer) is good shared library support, which distribution maintainers will always prefer. I don't think there's a good language for that, but if one will appear, it will definitely be favored.

by sn9 2y ago

You can build a CLI in Rust with a better performance and runtime guarantees with far less skill and have a better time doing it. Java doesn't even have null safety or ergonomic algebraic data types.

pjmlp 2y ago

Scala and Kotlin also exist, and Rust's place is for systems programming not CLI stuff. Besides people here sometimes have a hard time understanding English, given that I acknowledged Rust being faster.

nindalf 2y ago
Your assertion that Rust isn’t well suited for command line programs contradicts reality, where developer tools for multiple languages are being rewritten in Rust. The new bundlers, linters and formatters for JavaScript and Python (the most popular languages by far) preferring Rust and gaining massive adoption tells me that Rust is pretty well suited to CLI programs. And the success of ripgrep, mcfly/atuin, zoxide, hyperfine and starship, just reinforces the feeling that yeah, CLIs written in Rust can succeed. So yeah, strongly disagree with you about Rust’s place. But from your previous comments I also know you’re very knowledgeable about Rust so I’m surprised you came to this conclusion.
- pjmlp 2y ago
  Don't mistake Rust Evangelism Strike Force, and joining the hype cycle, with the suitabitility for writing CLI developer tools there is nothing there that requires the use of borrow checker. Depending on how many years into the past of HN headlines we would search for, it would be Go, Scala, Haskell, Ruby,... Maybe all those Rust CLIs will be all being rewriting into Zig, as soon as version 1.0 gets out. Roc language is already one of the first.
  - nindalf 2y ago
    I've been on HN for a while, I saw the previous hype cycles. I have no doubt we'll see a Zig hype cycle as well. One of the reasons Rust succeeded, especially in CLI was 1. Low fixed memory overhead (compared to most popular VM based language - Python, Ruby, Java). 2. Startup time is nearly instantaneous, compared to the same languages. Don't have to wait 50-100ms or so just to start executing code. 3. Run time is faster as well, especially so for programs like ripgrep that use SIMD. 4. Single static binary with no dependencies. Didn't need a VM or toolchain to be installed on the user's computer. Having a great CLI library like clap.rs brought it all together. If you think this is simply a cycle and Zig will replace Rust, I'm slightly skeptical. Rust had an easier time competing with the status quo because of the 4 advantages it had. Zig however, will have to compete with Rust. Sure, you can start ziggrep, but it'll be about equal in all these 4 factors. So why would anyone adopt something that has fewer features than ripgrep and about the same performance, memory consumption and ease of use? Just hype? Some people will, but not enough to get the critical mass ripgrep has. That's why I'm bullish about Rust - the performance of existing codebases means that in many cases, it's hard to migrate away from it, or replace Rust programs with reimplementations. You'd have to be getting something really unique that Rust doesn't offer. You said Roc, and Roc is actually a great example of benefiting from something unique. Roc plans to reuse the Zig compiler's library that emits LLVM bitcode. There's no Rust equivalent. But I'd argue that that's pretty niche. How many other examples are there of Zig libraries that have no Rust equivalent? Something that would make Zig the no-brainer choice over Rust, even if you had to reimplement in Zig. Again, I'm sure people will try to rewrite things in Zig. But I'll confidently assert -> the most popular toolchain for Python in 5 years will be Rust based, not Zig or any other language. $10 on that.
    - whytevuhuni 2y ago
      I think a really important benefit is going to be binary size. That's what initially made me dislike Rust quite a lot. And for CLI tools, you need those to be tiny. You're going to many of them, and you'll want to build a whole distribution, which you'll want to be small (for small images, small containers, etc). Another benefit (that Zig won't offer) is good shared library support, which distribution maintainers will always prefer. I don't think there's a good language for that, but if one will appear, it will definitely be favored.