6 ms·

Rust seems to be targeting a development environment that's a bit more constrained than C and C++. C++ is general enough to work everywhere. Rust seems speciali

Rust seems to be targeting a development environment that's a bit more constrained than C and C++. C++ is general enough to work everywhere. Rust seems specialized to, well, the kinds of systems that run Firefox. Embedded into the shape of the language isn't only byte addressing, but also this idea that memory is practically unlimited and that allocation failure recovery isn't important. Rust may be perfectly fine in its domain, but my position is that these baked-in assumptions make its domain a subset of C++'s.

Ar-Curunir 7y ago
Nothing in the language assumes unfailing allocation. It's only the current standard library APIs that don't support failable allocation, but there is work underway to remedy this.
- quotemstr 7y ago
  The fundamental mistake in the Rust programming language is avoiding the use of exceptions for reporting errors. It's because the Rust designers eschewed exceptions that lots of standard library functions that need to allocate memory are also no-fail. If we reported allocation failure with Result, we'd have Result _everywhere_, which would have an ergonomic disaster, especially before the "?" operator appeared. If Rust had been designed to use exceptions from the start, this problem wouldn't exist, and it'd be a much nicer language besides. Some people seem to just have a philosophical or aesthetic aversion to exceptions, which is a shame, because exceptions work wonderfully in practice. Rust's development path is especially unfortunate because when you return Result everywhere and use the "?" operator consistently, what you end up writing looks just like exceptional code, but with weird warts and limitations from the language essentially implementing exceptions with return codes instead of first-class affordances built into the language itself. It's because Rust got error handling wrong that I still prefer C++ despite Rust's advantages in variable lifetime reificiation. Exceptions turn out to be so useful in general-purpose programming that Rust had to add them in a hacky way after the fact using macros and special operators. I understand that my position is controversial, but it's still my opinion and it's going to inform my language choice.
  - nixpulvis 7y ago
    I disagree. In fact, I'd go a step further the opposite direction and say that the inclusion of panics was a mistake in the language design, though we're stuck with it now. To be fair, they do allow much better diagnostics when things fail, so this is more of a matter of simplicity vs developer economics, unless I'm missing something.
    - quotemstr 7y ago
      I agree that supporting panics was a mistake as long as exceptions aren't really supported. Panics force everyone to pay for the possibility of unwinding without getting to use unwinding for exceptions. It's unfortunate. If you're going to have to consider the possibility unwinding, running destructors, and so on, just add exceptions! You don't need the panic mechanism to get good stack traces. You can get good stack traces in plain C with abort(): walking the stack does not require unwinding the stack! Confusing these two concepts is just another example of the unfixable confusion baked into the core of Rust that ruins an otherwise-interesting language.
      - steveklabnik 7y ago
        If you don’t want to pay for landing pads, you can compile your program with panic=abort, and you won’t get them. As you say, you can still get stack traces. The only reason that this is feasible is precisely because panics are not used for recoverable error handing in Rust; libraries don’t break if you turn this option on.
        nixpulvis 7y ago
        Well, panics should not be used for recoverable error handing in Rust. There's no guarantee turning off panics in favor of aborts wont break the assumptions of some library. That library should probably break tho, since as you said, panics aren't meant to emulate application logic exceptions. use std::panic::catch_unwind; fn main() { let err = catch_unwind(|| { panic!("B") }); println!("Look ma, recoverable error handing! {:?}", err); }
chubot 7y ago
Does Rust support 16-bit architectures? I think I read recently that D doesn't on purpose. But of course C and C++ do. Found this comment, which makes it seem like support is intended but maybe not ready to use: https://news.ycombinator.com/item?id=15270502 https://news.ycombinator.com/item?id=15270502 not sure if related: https://github.com/rust-osdev/bootloader/issues/24 https://github.com/rust-osdev/bootloader/issues/24
- steveklabnik 7y ago
  There’s been ongoing work to support AVR, which as I understand is a 16 (or was it 8?) bit architecture. It hasn’t landed in tree yet due to codegen bugs in LLVM, last I checked.
  - monocasa 7y ago
    It's basically a 16 bit arch. 8 bit registers, but they can be paired pretty easily and uniformly across the ISA MSP430 is probably the best supported 16 bit arch for Rust.
ohazi 7y ago
> the kinds of systems that run Firefox What gave you this idea? Rust today will run on 1 MHz microcontrollers with 4k sram.

Ar-Curunir 7y ago

Nothing in the language assumes unfailing allocation. It's only the current standard library APIs that don't support failable allocation, but there is work underway to remedy this.

quotemstr 7y ago
The fundamental mistake in the Rust programming language is avoiding the use of exceptions for reporting errors. It's because the Rust designers eschewed exceptions that lots of standard library functions that need to allocate memory are also no-fail. If we reported allocation failure with Result, we'd have Result _everywhere_, which would have an ergonomic disaster, especially before the "?" operator appeared. If Rust had been designed to use exceptions from the start, this problem wouldn't exist, and it'd be a much nicer language besides. Some people seem to just have a philosophical or aesthetic aversion to exceptions, which is a shame, because exceptions work wonderfully in practice. Rust's development path is especially unfortunate because when you return Result everywhere and use the "?" operator consistently, what you end up writing looks just like exceptional code, but with weird warts and limitations from the language essentially implementing exceptions with return codes instead of first-class affordances built into the language itself. It's because Rust got error handling wrong that I still prefer C++ despite Rust's advantages in variable lifetime reificiation. Exceptions turn out to be so useful in general-purpose programming that Rust had to add them in a hacky way after the fact using macros and special operators. I understand that my position is controversial, but it's still my opinion and it's going to inform my language choice.
- nixpulvis 7y ago
  I disagree. In fact, I'd go a step further the opposite direction and say that the inclusion of panics was a mistake in the language design, though we're stuck with it now. To be fair, they do allow much better diagnostics when things fail, so this is more of a matter of simplicity vs developer economics, unless I'm missing something.
  - quotemstr 7y ago
    I agree that supporting panics was a mistake as long as exceptions aren't really supported. Panics force everyone to pay for the possibility of unwinding without getting to use unwinding for exceptions. It's unfortunate. If you're going to have to consider the possibility unwinding, running destructors, and so on, just add exceptions! You don't need the panic mechanism to get good stack traces. You can get good stack traces in plain C with abort(): walking the stack does not require unwinding the stack! Confusing these two concepts is just another example of the unfixable confusion baked into the core of Rust that ruins an otherwise-interesting language.
    - steveklabnik 7y ago
      If you don’t want to pay for landing pads, you can compile your program with panic=abort, and you won’t get them. As you say, you can still get stack traces. The only reason that this is feasible is precisely because panics are not used for recoverable error handing in Rust; libraries don’t break if you turn this option on.
      - nixpulvis 7y ago
        Well, panics should not be used for recoverable error handing in Rust. There's no guarantee turning off panics in favor of aborts wont break the assumptions of some library. That library should probably break tho, since as you said, panics aren't meant to emulate application logic exceptions. use std::panic::catch_unwind; fn main() { let err = catch_unwind(|| { panic!("B") }); println!("Look ma, recoverable error handing! {:?}", err); }

chubot 7y ago

Does Rust support 16-bit architectures? I think I read recently that D doesn't on purpose. But of course C and C++ do. Found this comment, which makes it seem like support is intended but maybe not ready to use: https://news.ycombinator.com/item?id=15270502 https://news.ycombinator.com/item?id=15270502 not sure if related: https://github.com/rust-osdev/bootloader/issues/24 https://github.com/rust-osdev/bootloader/issues/24

steveklabnik 7y ago
There’s been ongoing work to support AVR, which as I understand is a 16 (or was it 8?) bit architecture. It hasn’t landed in tree yet due to codegen bugs in LLVM, last I checked.
- monocasa 7y ago
  It's basically a 16 bit arch. 8 bit registers, but they can be paired pretty easily and uniformly across the ISA MSP430 is probably the best supported 16 bit arch for Rust.

ohazi 7y ago

> the kinds of systems that run Firefox What gave you this idea? Rust today will run on 1 MHz microcontrollers with 4k sram.