5 ms·

> a nice low-level language The usability is not great, too opinionated. For example, they have decided their strings are guaranteed to contain valid UTF-8. Ma

> a nice low-level language The usability is not great, too opinionated. For example, they have decided their strings are guaranteed to contain valid UTF-8. Many external components (like Linux kernel) don’t have these guarantees, so the Rust has another OsString type for them. I think Rust is the only language which does that. The rest of them are fine keeping invalid UTF8 / UTF16 in their strings. > proper and easy to use iterators C++/11 introduced range-based for loops, they make iterators very easy to use. > nice tooling Packages are OK I guess, but I think other classes of tools are lacking. For example, I can’t imagine working on any performance critical low-level code without a good sampling profiler. > ANY, really? Yes. Even very simple data structures like std::vec::Vec require unsafe code, they call unsafe APIs like alloc::alloc for memory management. This can, and did, cause security bugs: https://shnatsel.medium.com/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 https://shnatsel.medium.com/how-rusts-standard-library-was-v... By comparison, modern C# is memory safe all the way down, possible to implement even very complicated data structures without a single line of unsafe code. The collection classes from the standard library don’t use unsafe code either.

pcwalton 2y ago
> I think Rust is the only language which does that. Python 3 strings are enforced valid Unicode (but not technically UTF-8, as they can contain unpaired surrogates). > Packages are OK I guess, but I think other classes of tools are lacking. For example, I can’t imagine working on any performance critical low-level code without a good sampling profiler. I've been using sampling profilers with Rust since before the language was publicly announced! > Yes. Even very simple data structures like std::vec::Vec require unsafe code, they call unsafe APIs like alloc::alloc for memory management. This can, and did, cause security bugs: This is yet another example of "Rust's liberal use of 'security bug' gives people the wrong impression". Although I wish they didn't, Rust users often use "security bug" to mean any memory safety problem in safe code. By this measure every C++ program in existence is a security bug. The question is whether any applications were exploitable because of this, and I don't know of any. > By comparison, modern C# is memory safe all the way down, possible to implement even very complicated data structures without a single line of unsafe code. Only because the runtime has hundreds of thousands of lines of unsafe code written in C++, including the garbage collector that makes it possible to write those collections.
kelnos 2y ago
> Even very simple data structures like std::vec::Vec require unsafe code, they call unsafe APIs like alloc::alloc for memory management. This can, and did, cause security bugs That's way better than everyone writing their own unsafe vec implementation in C or C++, and then having to deal with those same security bugs over and over and over. And I'm sure GNU's libstdc++, LLVM's libc++, and whatever Microsoft calls their C++ stdlib have had a laundry list of security bugs in their implementations of the fundamental data structures over time. Just they were found and fixed 20 years ago, in a time when the security issue du jour wasn't huge news like it is today. > By comparison, modern C# is memory safe all the way down, possible to implement even very complicated data structures without a single line of unsafe code You really can't compare a GC'd language to Rust (or C or C++), at least not without acknowledging the inherent tradeoffs being made. And obviously that C# runtime has a bunch of unsafe C/C++ underneath it that lets you do those things.
- celdon25 2y ago
  What tradeoffs are you referring to here, exactly? C# (in the right hands) is more flexible than what you seem to be implying here, and the GP is likely in the small minority of experts that knows how to leverage it. The limiting ”tradeoffs” with C# have much more to do with the JIT than anything related to a GC. That’s why you don’t see constant expressions (but in the future that may change). https://github.com/dotnet/csharplang/issues/6926#issuecomment-1426695771 https://github.com/dotnet/csharplang/issues/6926#issuecommen...
  - Ygg2 2y ago
    > What tradeoffs are you referring to here, exactly? C# (in the right hands) is more flexible than what you seem to be implying here, and the GP is likely in the small minority of experts that knows how to leverage it. It's flexible, but if you want to write something that is GC-less, you're on your own. Most libraries (if they exist) don't care about allocation. Or performance. I'm not talking HFT here, I'm talking about performance intensive games.
    - Const-me 2y ago
shakow 2y ago
> I can’t imagine working on any performance critical low-level code without a good sampling profiler. cargo-flamegraph: am I a joke to you? https://github.com/flamegraph-rs/flamegraph https://github.com/flamegraph-rs/flamegraph
orlp 2y ago
> For example, I can’t imagine working on any performance critical low-level code without a good sampling profiler. I'm pretty happy with https://github.com/mstange/samply https://github.com/mstange/samply. It worked out-of-the-box on Linx and MacOS, even on Windows after installing directly from the repo (recently added feature).
- neonsunset 2y ago
  Samply is awesome. It's my go-to profiler I can throw at any un-stripped binary on any OS that I use and then just drill down with a nice Firefox profiler UI (particularly the fact that it allows to navigate multi-threaded traces well). In fact, its predominant use for me so far was collecting "full" traces of C# code that shows the exact breakdown between time spent in user code and in write barriers and GC since .NET's AOT compilation target produces "classic" native binaries with regular object/symbol format for a given platform.
Ygg2 2y ago
> The usability is not great, too opinionated. For example, they have decided their strings are guaranteed to contain valid UTF-8. Wait, why is that a problem? Using UTF-8 only is the closest to programmer's ideal. Basically, you turn the UTF-8 validator for Rust's str into a no-op. > Yes. Even very simple data structures like std::vec::Vec require unsafe code I guess this is the sort of glass half-full vs glass half-empty. In C++ the std::vector::pop_back will forever cause undefined behavior. It's like putting razors on your screwdriver's handle, sure you can avoid them, but why not do the sane thing...
- josefx 2y ago
  > Wait, why is that a problem? Using UTF-8 only is the closest to programmer's ideal. I have a lot of archived data with various unknown encodings. APIs that blindly try to force an encoding when all I have is "bytes" tend to be a major pain and I usually end up bruteforcing my way around them with things like base64.
  - Ygg2 2y ago
    If that's the case the winning move is get the bytes, and convert them to UTF8 or just process it as bytes. &str is a wrapper around &[u8] with strict UTF8 guarantees. Modern systems should be able to convert various encodings at GiB/s into UTF8.
    - josefx 2y ago
      > If that's the case the winning move is get the bytes, and convert them to UTF8 That would require knowing the original encoding. > or just process it as bytes As long as the APIs you have to use take bytes and not u8 strings. > Modern systems should be able to convert various encodings at GiB/s into UTF8. They might even guess the correct source encoding a quarter of the time and it will break any legacy application that still has to interact with the data. I guess that would be a win-win situation for Rust.
      - dralley 2y ago

pcwalton 2y ago

> I think Rust is the only language which does that. Python 3 strings are enforced valid Unicode (but not technically UTF-8, as they can contain unpaired surrogates). > Packages are OK I guess, but I think other classes of tools are lacking. For example, I can’t imagine working on any performance critical low-level code without a good sampling profiler. I've been using sampling profilers with Rust since before the language was publicly announced! > Yes. Even very simple data structures like std::vec::Vec require unsafe code, they call unsafe APIs like alloc::alloc for memory management. This can, and did, cause security bugs: This is yet another example of "Rust's liberal use of 'security bug' gives people the wrong impression". Although I wish they didn't, Rust users often use "security bug" to mean any memory safety problem in safe code. By this measure every C++ program in existence is a security bug. The question is whether any applications were exploitable because of this, and I don't know of any. > By comparison, modern C# is memory safe all the way down, possible to implement even very complicated data structures without a single line of unsafe code. Only because the runtime has hundreds of thousands of lines of unsafe code written in C++, including the garbage collector that makes it possible to write those collections.

kelnos 2y ago

> Even very simple data structures like std::vec::Vec require unsafe code, they call unsafe APIs like alloc::alloc for memory management. This can, and did, cause security bugs That's way better than everyone writing their own unsafe vec implementation in C or C++, and then having to deal with those same security bugs over and over and over. And I'm sure GNU's libstdc++, LLVM's libc++, and whatever Microsoft calls their C++ stdlib have had a laundry list of security bugs in their implementations of the fundamental data structures over time. Just they were found and fixed 20 years ago, in a time when the security issue du jour wasn't huge news like it is today. > By comparison, modern C# is memory safe all the way down, possible to implement even very complicated data structures without a single line of unsafe code You really can't compare a GC'd language to Rust (or C or C++), at least not without acknowledging the inherent tradeoffs being made. And obviously that C# runtime has a bunch of unsafe C/C++ underneath it that lets you do those things.

celdon25 2y ago
What tradeoffs are you referring to here, exactly? C# (in the right hands) is more flexible than what you seem to be implying here, and the GP is likely in the small minority of experts that knows how to leverage it. The limiting ”tradeoffs” with C# have much more to do with the JIT than anything related to a GC. That’s why you don’t see constant expressions (but in the future that may change). https://github.com/dotnet/csharplang/issues/6926#issuecomment-1426695771 https://github.com/dotnet/csharplang/issues/6926#issuecommen...
- Ygg2 2y ago
  > What tradeoffs are you referring to here, exactly? C# (in the right hands) is more flexible than what you seem to be implying here, and the GP is likely in the small minority of experts that knows how to leverage it. It's flexible, but if you want to write something that is GC-less, you're on your own. Most libraries (if they exist) don't care about allocation. Or performance. I'm not talking HFT here, I'm talking about performance intensive games.
  - Const-me 2y ago

shakow 2y ago

> I can’t imagine working on any performance critical low-level code without a good sampling profiler. cargo-flamegraph: am I a joke to you? https://github.com/flamegraph-rs/flamegraph https://github.com/flamegraph-rs/flamegraph

orlp 2y ago

> For example, I can’t imagine working on any performance critical low-level code without a good sampling profiler. I'm pretty happy with https://github.com/mstange/samply https://github.com/mstange/samply. It worked out-of-the-box on Linx and MacOS, even on Windows after installing directly from the repo (recently added feature).

neonsunset 2y ago
Samply is awesome. It's my go-to profiler I can throw at any un-stripped binary on any OS that I use and then just drill down with a nice Firefox profiler UI (particularly the fact that it allows to navigate multi-threaded traces well). In fact, its predominant use for me so far was collecting "full" traces of C# code that shows the exact breakdown between time spent in user code and in write barriers and GC since .NET's AOT compilation target produces "classic" native binaries with regular object/symbol format for a given platform.

Ygg2 2y ago

> The usability is not great, too opinionated. For example, they have decided their strings are guaranteed to contain valid UTF-8. Wait, why is that a problem? Using UTF-8 only is the closest to programmer's ideal. Basically, you turn the UTF-8 validator for Rust's str into a no-op. > Yes. Even very simple data structures like std::vec::Vec require unsafe code I guess this is the sort of glass half-full vs glass half-empty. In C++ the std::vector::pop_back will forever cause undefined behavior. It's like putting razors on your screwdriver's handle, sure you can avoid them, but why not do the sane thing...

josefx 2y ago
> Wait, why is that a problem? Using UTF-8 only is the closest to programmer's ideal. I have a lot of archived data with various unknown encodings. APIs that blindly try to force an encoding when all I have is "bytes" tend to be a major pain and I usually end up bruteforcing my way around them with things like base64.
- Ygg2 2y ago
  If that's the case the winning move is get the bytes, and convert them to UTF8 or just process it as bytes. &str is a wrapper around &[u8] with strict UTF8 guarantees. Modern systems should be able to convert various encodings at GiB/s into UTF8.
  - josefx 2y ago
    > If that's the case the winning move is get the bytes, and convert them to UTF8 That would require knowing the original encoding. > or just process it as bytes As long as the APIs you have to use take bytes and not u8 strings. > Modern systems should be able to convert various encodings at GiB/s into UTF8. They might even guess the correct source encoding a quarter of the time and it will break any legacy application that still has to interact with the data. I guess that would be a win-win situation for Rust.
    - dralley 2y ago