5 ms·

For teaching purposes in a university I don't know if rust would be better or not. Keep in mind that the goal isn't necessarily to learn C the language; it's to

by sreque 9y ago

For teaching purposes in a university I don't know if rust would be better or not. Keep in mind that the goal isn't necessarily to learn C the language; it's to learn enough of the core language to explore things like: * How the code is executed on modern hardware and operating systems. * How various language features might be compiled to assembly * Memory layouts for things like stack frames, how a simple heap allocator might work, array layouts, layouts for other structures like linked lists, etc. * The relative cost of various operations and how to write code that is cache friendly. * How debuggers generally work and how to debug code. Could these things be taught equally well or better in an undergraduate seeing using rust? Honestly I don't know; I know very little about Rust. I can say that I think C++ is a worse language for this purpose because of the language's complexity and because of features that aren't well suited for the above purposes. I have heard, for instance, that's it's actually very difficult in rust to write a linked list without dropping to unsafe code. I would consider this a bad thing for the above purposes.

kqr 9y ago
> * How the code is executed on modern hardware and operating systems. Does anyone know this at this point? With pipelining, out of order execution, vectorisation, register renaming, speculative execution, buffered micro-op fusing and what have you, it's very hard to say general things about how the code executes on the actual hardware.
- yjftsjthsd-h 9y ago
  Perhaps, "Understand the model of how code pretends to be executed"? Pipelining, etc. are meant to produce the same results as the older/simpler systems. You need to understand that that's not quite reality anymore, but as a basic model it's fine.
  - kqr 9y ago
    Sure, but at that point you are content with learning "the x86 virtual machine" -- and is that fundamentally different from being content with learning "the Java virtual machine"? I'm arguing that it's a matter of degree, not of kind. People make it seem like it's the latter.
    - barrkel 9y ago
      It's different in kind. The JVM completely abstracts away things like class loading from the perspective of bytecode - that stuff seems to happen like magic. Ditto exception handling, stack frame linkage, memory allocation, etc. Viewing all of code and data living together in a big array is important, I think. You don't understand e.g. dynamically generated thunks and shims without seeing the duality of code and data at the execution level.
- vvanders 9y ago
  Short answer: because cache misses are 10x more common and dominate the time saved from pretty much all of those features. Get your cache misses in order(which is easy to understand in the C model) and you're ahead of 95% of the curve(plus you get a 10-50x performance bump as a reward).
- InclinedPlane 9y ago
  Of course not. With the meltdown/spectre vulnerabilities and mitigations we see that how a processor/OS/program stack executes code can change from year to year or month to month, with significant performance differences. Maybe that's an exceptional blip, maybe it's a portent for the future.
catnaroek 9y ago
> I have heard, for instance, that's it's actually very difficult in rust to write a linked list without dropping to unsafe code. It is also hard in C to write a linked list without dropping to unsafe code. In fact, it is hard in C to add frigging signed integers without dropping to unsafe code.

by sreque 9y ago

kqr 9y ago

> * How the code is executed on modern hardware and operating systems. Does anyone know this at this point? With pipelining, out of order execution, vectorisation, register renaming, speculative execution, buffered micro-op fusing and what have you, it's very hard to say general things about how the code executes on the actual hardware.

yjftsjthsd-h 9y ago
Perhaps, "Understand the model of how code pretends to be executed"? Pipelining, etc. are meant to produce the same results as the older/simpler systems. You need to understand that that's not quite reality anymore, but as a basic model it's fine.
- kqr 9y ago
  Sure, but at that point you are content with learning "the x86 virtual machine" -- and is that fundamentally different from being content with learning "the Java virtual machine"? I'm arguing that it's a matter of degree, not of kind. People make it seem like it's the latter.
  - barrkel 9y ago
    It's different in kind. The JVM completely abstracts away things like class loading from the perspective of bytecode - that stuff seems to happen like magic. Ditto exception handling, stack frame linkage, memory allocation, etc. Viewing all of code and data living together in a big array is important, I think. You don't understand e.g. dynamically generated thunks and shims without seeing the duality of code and data at the execution level.
vvanders 9y ago
Short answer: because cache misses are 10x more common and dominate the time saved from pretty much all of those features. Get your cache misses in order(which is easy to understand in the C model) and you're ahead of 95% of the curve(plus you get a 10-50x performance bump as a reward).
InclinedPlane 9y ago
Of course not. With the meltdown/spectre vulnerabilities and mitigations we see that how a processor/OS/program stack executes code can change from year to year or month to month, with significant performance differences. Maybe that's an exceptional blip, maybe it's a portent for the future.

catnaroek 9y ago

> I have heard, for instance, that's it's actually very difficult in rust to write a linked list without dropping to unsafe code. It is also hard in C to write a linked list without dropping to unsafe code. In fact, it is hard in C to add frigging signed integers without dropping to unsafe code.