3 ms·

Not really, with Go it’s braindead simple. Why would you want to jump through hoops to match performance of Go? For the sake of using Java (lol)?

pjmlp 2y ago
I rather use tools not stuck in jurassic time of programming language design, again, Go's performance is behind most Java implementations. That wouldn't be true for gccgo implementation, but then again, it is now abandoned in pre-generics Go, stuck at version 1.17, no one seems to care to update it.
- wiseowise 2y ago
  Then you use Rust. shrug
  - pjmlp 2y ago
    Rust is for kernels and low level systems programming where a GC isn't allowed to play ball.
- 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.

pjmlp 2y ago

I rather use tools not stuck in jurassic time of programming language design, again, Go's performance is behind most Java implementations. That wouldn't be true for gccgo implementation, but then again, it is now abandoned in pre-generics Go, stuck at version 1.17, no one seems to care to update it.

wiseowise 2y ago
Then you use Rust. shrug
- pjmlp 2y ago
  Rust is for kernels and low level systems programming where a GC isn't allowed to play ball.
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.