9 ms·

Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a perfo

Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. You're talking about the forrest - while we're talking about how making trees from scratch is difficult and messed up no matter how you go about it. At some point, you have to talk to the computer directly (aka "unsafely"). Things like bounds checking, garbage collection, and other runtime utilities sound like great ideas until they translate to significant monetary costs each month. Not everything is as trivial as writing GUI glue code in a nice comfy language with a magical framework. Although, most of it is.

andrewjl 11y ago
I'd really like to see a good write up on a project that's trying to tackle this problem on the levels below C. (Assembly or even hardware level.)
- cbd1984 11y ago
  The x86 ISA already has bounds-checking opcodes which can be used to ensure array accesses don't go off the deep end.
steveklabnik 11y ago
> it can't be safe at that low level without a performance penalty. Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block. That said, I do think that building a libc in Rust would take a significant investment and I'm not sure who's going to even attempt it, if anyone.
- acconsta 11y ago
  >Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. But not bounds checks, which are unfortunately what you need with respect to buffer overflows.
  - steveklabnik 11y ago
    Yes, absolutely.
    - erickt 11y ago
      But only if you use the `slice.unchecked_get`[1] method, otherwise you still get bounds checking in an unsafe block. [1]: http://doc.rust-lang.org/std/primitive.slice.html#method.get_unchecked http://doc.rust-lang.org/std/primitive.slice.html#method.get...
pcwalton 11y ago
> Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. I do a lot of low-level Rust programming and a lot of low-level C programming. I don't know what the performance penalty you're claiming exists comes from. Can you elaborate as to the specific Rust features that you claim are slow? (Incidentally, the project I'm working on right now in Rust beats all of the existing C competitors in performance by a lot.) :)
- autoreleasepool 11y ago
  A little defensive, maybe? I never claimed Rust was slower than C or that it had a performance penalty (because you should use unsafe). Actually, I pretty much said the opposite. I said they were the same. I was trying to highlight the fact that unsafe Rust and C are not that different when you're doing bitwise operations on bare metal. I was wanted to drive the point that additional abstractions are undesirable at that low level unless they can be enforced at compile time. I'm concerned by some of the magical thinking being espoused in this thread about what's actually reasonable in terms of the trade offs you can make. In other words I was talking about safety, not speed. I'm glad to hear Rust is out performing C though. I just wish I had a better IDE than atom... Didn't you once mention Xcode support for Rust?
  - nightpool 11y ago
    pcwalton is talking about safe rust. Unsafe rust is not really any faster in a lot of cases, and even when it is the goal is to compartmentalize the unsafe code into very small, distinct, easily testable segments.
    - autoreleasepool 11y ago
      Again, I'm not talking about performance. I'm talking about low level safety and the difficulties in achieving that in any meaningful way. I wasn't talking about just Rust when I said abstractions cost you speed. It was a (perhaps unclear) general statement about programming. As an aside, unsafe rust is faster than safe rust for a lot of cases. I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticized Rust. So far IME, the rust community is extremely defensive and antagonistic to anyone they perceive to have made the slightest criticism. It's immature and irritating. It's the only thing that really turns me off from fully embracing it. I can't participate in a community that's fundamentally hostile to skepticism.
nothrabannosir 11y ago
> ...it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. A bit higher up: It was clear when Hoare stated on his speech in 1980: "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." - https://news.ycombinator.com/item?id=11110456 https://news.ycombinator.com/item?id=11110456 ... which directly contradicts the "no one" part.
- autoreleasepool 11y ago
  A sample size of one makes for a worse rule of thumb then a trend based on hard reality. Speed is all that matters, I actually learned that from Graydon's blog: http://graydon2.dreamwidth.org/233585.html#cutid1 http://graydon2.dreamwidth.org/233585.html#cutid1 Rust sacrificed the majority of its runtime and adopted C's memory model late in development so people wouldn't have to pay a performance cost or depend on confusing heap allocation semantics. That's why it has a really good chance at disrupting the embedded space.
  - twic 11y ago
    The enterprise software world didn't leap off C++ and onto Java because it was faster. They did it because it didn't segfault all the time. They then leapt to Perl and Python and Ruby because they didn't segfault all the time and seemed a lot faster to develop in. To the vast majority of people and organisations writing software, performance of the software, to within an order of magnitude, just isn't a big deal.
    - autoreleasepool 11y ago
      We aren't talking about enterprise software. It hasn't been mentioned once. You can't change the subject and then say I'm wrong. Obviously, higher level applications can and often should be implemented using garbage collected languages.
ossreality 11y ago
>Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. Wow, what a succinct way to let us know you don't know what you're talking about!

andrewjl 11y ago

I'd really like to see a good write up on a project that's trying to tackle this problem on the levels below C. (Assembly or even hardware level.)

cbd1984 11y ago
The x86 ISA already has bounds-checking opcodes which can be used to ensure array accesses don't go off the deep end.

steveklabnik 11y ago

> it can't be safe at that low level without a performance penalty. Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. Yes, sometimes you still need unsafe, but even then, it's a superset, not a subset: a lot of safety checks still happen inside an unsafe block. That said, I do think that building a libc in Rust would take a significant investment and I'm not sure who's going to even attempt it, if anyone.

acconsta 11y ago
>Many of Rust's safety guarantees come from compile-time checks that then do not have any runtime penalty. But not bounds checks, which are unfortunately what you need with respect to buffer overflows.
- steveklabnik 11y ago
  Yes, absolutely.
  - erickt 11y ago
    But only if you use the `slice.unchecked_get`[1] method, otherwise you still get bounds checking in an unsafe block. [1]: http://doc.rust-lang.org/std/primitive.slice.html#method.get_unchecked http://doc.rust-lang.org/std/primitive.slice.html#method.get...

pcwalton 11y ago

> Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. I do a lot of low-level Rust programming and a lot of low-level C programming. I don't know what the performance penalty you're claiming exists comes from. Can you elaborate as to the specific Rust features that you claim are slow? (Incidentally, the project I'm working on right now in Rust beats all of the existing C competitors in performance by a lot.) :)

autoreleasepool 11y ago
A little defensive, maybe? I never claimed Rust was slower than C or that it had a performance penalty (because you should use unsafe). Actually, I pretty much said the opposite. I said they were the same. I was trying to highlight the fact that unsafe Rust and C are not that different when you're doing bitwise operations on bare metal. I was wanted to drive the point that additional abstractions are undesirable at that low level unless they can be enforced at compile time. I'm concerned by some of the magical thinking being espoused in this thread about what's actually reasonable in terms of the trade offs you can make. In other words I was talking about safety, not speed. I'm glad to hear Rust is out performing C though. I just wish I had a better IDE than atom... Didn't you once mention Xcode support for Rust?
- nightpool 11y ago
  pcwalton is talking about safe rust. Unsafe rust is not really any faster in a lot of cases, and even when it is the goal is to compartmentalize the unsafe code into very small, distinct, easily testable segments.
  - autoreleasepool 11y ago
    Again, I'm not talking about performance. I'm talking about low level safety and the difficulties in achieving that in any meaningful way. I wasn't talking about just Rust when I said abstractions cost you speed. It was a (perhaps unclear) general statement about programming. As an aside, unsafe rust is faster than safe rust for a lot of cases. I re-read what I wrote and I fail to see where I attacked or even (God forbid) criticized Rust. So far IME, the rust community is extremely defensive and antagonistic to anyone they perceive to have made the slightest criticism. It's immature and irritating. It's the only thing that really turns me off from fully embracing it. I can't participate in a community that's fundamentally hostile to skepticism.

nothrabannosir 11y ago

> ...it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. A bit higher up: It was clear when Hoare stated on his speech in 1980: "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." - https://news.ycombinator.com/item?id=11110456 https://news.ycombinator.com/item?id=11110456 ... which directly contradicts the "no one" part.

autoreleasepool 11y ago
A sample size of one makes for a worse rule of thumb then a trend based on hard reality. Speed is all that matters, I actually learned that from Graydon's blog: http://graydon2.dreamwidth.org/233585.html#cutid1 http://graydon2.dreamwidth.org/233585.html#cutid1 Rust sacrificed the majority of its runtime and adopted C's memory model late in development so people wouldn't have to pay a performance cost or depend on confusing heap allocation semantics. That's why it has a really good chance at disrupting the embedded space.
- twic 11y ago
  The enterprise software world didn't leap off C++ and onto Java because it was faster. They did it because it didn't segfault all the time. They then leapt to Perl and Python and Ruby because they didn't segfault all the time and seemed a lot faster to develop in. To the vast majority of people and organisations writing software, performance of the software, to within an order of magnitude, just isn't a big deal.
  - autoreleasepool 11y ago
    We aren't talking about enterprise software. It hasn't been mentioned once. You can't change the subject and then say I'm wrong. Obviously, higher level applications can and often should be implemented using garbage collected languages.

ossreality 11y ago