3 ms·

> C debuggers and tooling are vastly more powerful than Rust's static type system As someone who's worked on C debuggers and tooling... I really have no idea w

> C debuggers and tooling are vastly more powerful than Rust's static type system As someone who's worked on C debuggers and tooling... I really have no idea what you're talking about. C's core semantics are just so weak that it's not really possible to express a lot of the things you can express in the type system, and that's before we get to the necessary lossiness that debuggers and tooling have to work with (e.g., you can't just ascribe types to memory in C because C--in practice--is way too loose with types for that to be meaningful). For an example from something I've worked on, Linux manages to have two different arrays for the GPRs for a thread register context, one that's used for ptrace and one that's used for signal contexts. Helpfully, the header files give you macros to map register names to numbers so that you can say regs[RAX] instead of regs[0]. But the offsets are different, so you have to remember that you need to use regs[REG_RAX] instead of regs[RAX], and there is absolutely no tooling in the world that can tell you when you get it wrong because there is no expressible difference between the two scenarios in C. Meanwhile, in Rust, I can wrap the accessors in newtypes so that I can only use the correct set of constants to index into the array, which makes the error state literally impossible to construct. That's the real value of a static type system--you can use it to make errors literally impossible to specify in an API.

mjburgess 2y ago
I don't see the difference between having a typed access API (V inline reg_at(enum K k) {} ) and overloading the indexer. If your point is that historical C APIs have overused an untyped operation, that's part of my point about a new std lib. Rust APIs can still provide an untyped indexer, it's just bad API design. What I'm imagining a new std lib would be doing is having debug allocators, metadata against types, etc. Ie., a std library designed for the debugger along with a release version.
- jcranmer 2y ago
  Using different enums doesn't help, because C will happily let you cast enum A to enum B implicity. In Rust, I can express an API which can't be used incorrectly. In C, I can't. Sometimes, in C, you can sometimes get to the point where you use conventions that means maybe static or dynamic analysis tools might be able to flag the misuse of the API, but very often, such tools have extremely poor tradeoffs between precision and accuracy, far worse than exists in Rust with just the vanilla compiler.
  - mjburgess 2y ago
    -Wconversion , no? My point isn't that you exhaust all the features of Rust with a better stdlib and "debugger-oriented programming" -- my point is that you can get 95% of the way there with trivial complexity costs. Rust imposes significant program design costs which can be very detrimental to otherwise trivial performant memory management, to faster iteration of software design, and so on. These aren't free lang. features.

mjburgess 2y ago

I don't see the difference between having a typed access API (V inline reg_at(enum K k) {} ) and overloading the indexer. If your point is that historical C APIs have overused an untyped operation, that's part of my point about a new std lib. Rust APIs can still provide an untyped indexer, it's just bad API design. What I'm imagining a new std lib would be doing is having debug allocators, metadata against types, etc. Ie., a std library designed for the debugger along with a release version.

jcranmer 2y ago
Using different enums doesn't help, because C will happily let you cast enum A to enum B implicity. In Rust, I can express an API which can't be used incorrectly. In C, I can't. Sometimes, in C, you can sometimes get to the point where you use conventions that means maybe static or dynamic analysis tools might be able to flag the misuse of the API, but very often, such tools have extremely poor tradeoffs between precision and accuracy, far worse than exists in Rust with just the vanilla compiler.
- mjburgess 2y ago
  -Wconversion , no? My point isn't that you exhaust all the features of Rust with a better stdlib and "debugger-oriented programming" -- my point is that you can get 95% of the way there with trivial complexity costs. Rust imposes significant program design costs which can be very detrimental to otherwise trivial performant memory management, to faster iteration of software design, and so on. These aren't free lang. features.