4 ms·

People who say "C is the new assembly" don't understand why people moved from assembly to C. Assembly is bad because it is typeless. Because it is typeless, th

People who say "C is the new assembly" don't understand why people moved from assembly to C. Assembly is bad because it is typeless. Because it is typeless, there is no way to check for program correctness. Rust is okay because it doesn't require garbage collection and types, but the best language would be C with a highly-elaborate strong type system and no closures or other unsuitable concepts for systems programming.

gnaritas 7y ago
That's not why people moved from assembly to C, C is portable, assembly is CPU specific, the move to C was about abstraction to a higher level language in the name of portability to multiple processors, not about verifying program correctness.
- ErotemeObelus 7y ago
  "C is portable" for some definition of portable I suppose
- pjmlp 7y ago
  At Bell Labs, on the outside people where already using plenty of Algol and PL/I variants.
damnyou 7y ago
Why are closures unsuitable for systems programming? Rust does them really well, not even allocating in the most common cases.
- jerf 7y ago
  Closure often have really weird lifetimes, so typically they've ended up implemented either with GC of some sort (possibly refcounting), or required such exceedingly careful handling that the cost/benefit analysis gets a big fat lump of "cost" that isn't a problem in most other environments because trying to track the transfer of ownerships across scopes, up and down stacks, and perhaps even between threads is just insane. Typically the entire purpose of the closure is precisely to inject some code's logic into a quite distant other bit of code, so the problem is not amenable to normal techniques around rearranging things to be on the stack and so on. The very nature of a closure-type abstraction in C is go to stomping right over the generally-fragile informal, unsupported organization of what code is responsible for what memory. I once was working with libpurple in a glib environment that made heavy use of segfaults in C. I mean closures. Closures in C that made it really easy to segfault when calling to a closure that had been freed, or really easy to leak if you didn't free them. I encountered situations where the common paths used by the "standard UI" for libpurple worked, but even when I was quite sure I was handling one of my closures correctly, the system would crash because it still free'd my closure, even though it should have been my responsibility to do so, and so on. Prior to Rust, I'd agree with the common wisdom that closures and systems programming had gone together poorly. It's a demonstration of the power of Rust's approach to the matter that closures become practical in system programming with it; that had not previously been the case.
  - damnyou 7y ago
    Right, there's definitely all sorts of issues with closures (esp async ones) if you don't have lifetime analysis. But Rust is the only systems programming language that I take seriously.
- pornel 7y ago
  (0..1000).map(|x| x*2).sum() compiles to mov eax, 999000 Rust takes full advantage of its ownership, mutability, lifetime tracking and generics to have closures with zero overhead.
pjmlp 7y ago
Interesting, because clang does support closures in C, thanks to Apple.

gnaritas 7y ago

That's not why people moved from assembly to C, C is portable, assembly is CPU specific, the move to C was about abstraction to a higher level language in the name of portability to multiple processors, not about verifying program correctness.

ErotemeObelus 7y ago
"C is portable" for some definition of portable I suppose
pjmlp 7y ago
At Bell Labs, on the outside people where already using plenty of Algol and PL/I variants.

damnyou 7y ago

Why are closures unsuitable for systems programming? Rust does them really well, not even allocating in the most common cases.

jerf 7y ago
Closure often have really weird lifetimes, so typically they've ended up implemented either with GC of some sort (possibly refcounting), or required such exceedingly careful handling that the cost/benefit analysis gets a big fat lump of "cost" that isn't a problem in most other environments because trying to track the transfer of ownerships across scopes, up and down stacks, and perhaps even between threads is just insane. Typically the entire purpose of the closure is precisely to inject some code's logic into a quite distant other bit of code, so the problem is not amenable to normal techniques around rearranging things to be on the stack and so on. The very nature of a closure-type abstraction in C is go to stomping right over the generally-fragile informal, unsupported organization of what code is responsible for what memory. I once was working with libpurple in a glib environment that made heavy use of segfaults in C. I mean closures. Closures in C that made it really easy to segfault when calling to a closure that had been freed, or really easy to leak if you didn't free them. I encountered situations where the common paths used by the "standard UI" for libpurple worked, but even when I was quite sure I was handling one of my closures correctly, the system would crash because it still free'd my closure, even though it should have been my responsibility to do so, and so on. Prior to Rust, I'd agree with the common wisdom that closures and systems programming had gone together poorly. It's a demonstration of the power of Rust's approach to the matter that closures become practical in system programming with it; that had not previously been the case.
- damnyou 7y ago
  Right, there's definitely all sorts of issues with closures (esp async ones) if you don't have lifetime analysis. But Rust is the only systems programming language that I take seriously.
pornel 7y ago
(0..1000).map(|x| x*2).sum() compiles to mov eax, 999000 Rust takes full advantage of its ownership, mutability, lifetime tracking and generics to have closures with zero overhead.

pjmlp 7y ago

Interesting, because clang does support closures in C, thanks to Apple.