4 ms·

In both cases I think the problem is that you and the author are slinging around judgements without any actual references to specific code. It's easy to make b

In both cases I think the problem is that you and the author are slinging around judgements without any actual references to specific code. It's easy to make broad statements. In your case, you tend to imply that these are due to Rust itself. But is it just due to manpower? C APIs have had so many man hours behind them I can't imagine Rust even being within orders of magnitude. Without diving into the details these broad statements are just pointless.

fuzzygroup 4y ago
Noted. And you are right about not giving examples. That was a mistake and bear in mind I wrote a rant which I didn't expect to get exposure. A buddy thought it was good enough to submit and that's how I'm here. No is more surprised than I that this showed up here. In terms of specific examples, I'm now running: * Starship.rs -- prompt management for my terminal. This is something I've always had issues with and Starship does a great job, better than I've ever had before. * NuShell which I run experimentally on my alternate box and I think I'm finally ready to use in production. * Warp.dev which I'm currently shutting down iTerm2 windows to shift over. * Zed -- which I just got late today and I'm going *try* and use this week. I have less time with this but looks quite good.
the__alchemist 4y ago
I don't think the poor quality code is due to Rust itself. I think manpower is a big part of it. Rust doesn't inherently lead to good quality code, which the article implies. Re code examples - Here's the Rust Awesome Embedded List - a collection of tools (especially hardware support drivesr) - https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust Most of them aren't suitable for use in practical projects; they're missing important features like non-blocking operation, low-power modes, DMA etc - these are all things that will come up in embedded projects, but aren't needed for the "hello world" examples they include. Part of this is from attempting to conform to embedded-HAL traits, which support only the broadest feature sets.
theobeers 4y ago
I’ve been dealing with an example of just what you described: Unicode normalization and collation. There’s a good normalization library in Rust—in terms of the quality of the code, standards conformance, how comfortable I am depending on it, etc.—but it’s a full order of magnitude slower than icu4c.[0] Which shouldn’t come as a surprise! Some of these things take decades. [0]: https://github.com/unicode-org/icu4x/issues/93#issuecomment-631102136 https://github.com/unicode-org/icu4x/issues/93#issuecomment-...
- benibela 4y ago
  Recently, I looked at some string functions in the Rust stdlib and noticed it is full of unsafe code. With comments like "this writes ascii only, so we do not utf-8 validation" hat validation is slowing down everything
- fuzzygroup 4y ago
  Don't things just take forever. I watched how long Ruby took to deal with Unicode. Sigh. But at least its happening.
- zbraniecki 4y ago
  Hi, just for context - this was a comparison of `unicode-normalizer` crate to ICU4C. Since then @hsivonen from Mozilla wrote a new normalizer that recently got merged into ICU4X - https://github.com/unicode-org/icu4x/tree/main/components/normalizer https://github.com/unicode-org/icu4x/tree/main/components/no... I don't have perf numbers yet but I suspect it to be perf comparable to ICU4C at least.

fuzzygroup 4y ago

Noted. And you are right about not giving examples. That was a mistake and bear in mind I wrote a rant which I didn't expect to get exposure. A buddy thought it was good enough to submit and that's how I'm here. No is more surprised than I that this showed up here. In terms of specific examples, I'm now running: * Starship.rs -- prompt management for my terminal. This is something I've always had issues with and Starship does a great job, better than I've ever had before. * NuShell which I run experimentally on my alternate box and I think I'm finally ready to use in production. * Warp.dev which I'm currently shutting down iTerm2 windows to shift over. * Zed -- which I just got late today and I'm going *try* and use this week. I have less time with this but looks quite good.

the__alchemist 4y ago

I don't think the poor quality code is due to Rust itself. I think manpower is a big part of it. Rust doesn't inherently lead to good quality code, which the article implies. Re code examples - Here's the Rust Awesome Embedded List - a collection of tools (especially hardware support drivesr) - https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust Most of them aren't suitable for use in practical projects; they're missing important features like non-blocking operation, low-power modes, DMA etc - these are all things that will come up in embedded projects, but aren't needed for the "hello world" examples they include. Part of this is from attempting to conform to embedded-HAL traits, which support only the broadest feature sets.

theobeers 4y ago

I’ve been dealing with an example of just what you described: Unicode normalization and collation. There’s a good normalization library in Rust—in terms of the quality of the code, standards conformance, how comfortable I am depending on it, etc.—but it’s a full order of magnitude slower than icu4c.[0] Which shouldn’t come as a surprise! Some of these things take decades. [0]: https://github.com/unicode-org/icu4x/issues/93#issuecomment-631102136 https://github.com/unicode-org/icu4x/issues/93#issuecomment-...

benibela 4y ago
Recently, I looked at some string functions in the Rust stdlib and noticed it is full of unsafe code. With comments like "this writes ascii only, so we do not utf-8 validation" hat validation is slowing down everything
fuzzygroup 4y ago
Don't things just take forever. I watched how long Ruby took to deal with Unicode. Sigh. But at least its happening.
zbraniecki 4y ago
Hi, just for context - this was a comparison of `unicode-normalizer` crate to ICU4C. Since then @hsivonen from Mozilla wrote a new normalizer that recently got merged into ICU4X - https://github.com/unicode-org/icu4x/tree/main/components/normalizer https://github.com/unicode-org/icu4x/tree/main/components/no... I don't have perf numbers yet but I suspect it to be perf comparable to ICU4C at least.