3 ms·
That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the mos
by goku12 10mo ago
That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases.
I'm not trying to hype up Rust or disparage C. I learned C first and then Rust, even before Rust 1.0 was released. And I have an idea why Rust finds acceptance, which is also what some of these companies have officially mentioned.
C is a nice little language that's easy to learn and understand. But the price you pay for it is in large applications where you have to handle resources like heap allocations. C doesn't offer any help there when you make such mistakes, though some linters might catch them. The reason for this, I think, is that C was developed in an era when they didn't have so much computing power to do such complicated analysis in the compiler.
People have been writing C for ages, but let me tell you - writing correct C is a whole different skill that's hard and takes ages to learn. If you think I'm saying this because I'm a bad programmer, then you would be wrong. I'm not a programmer at all (by qualification), but rather a hardware engineer who is more comfortable with assembly, registers, Bus, DRAM, DMA, etc. I still used to get widespread memory errors, because all it takes is a lapse in attention while coding. That strain is what Rust alleviates.
- Surac 10mo agoSo you try to say c is for good programmers only and rust let also the idiots Programm? I think that’s the wrong way to argue for rust. Rust catches one kind of common problem but but does not magically make logic errors away.
- torginus 10mo agoI'm curious why your perspective on Rust as a HW engineer. Hardware does a ton of things - DMA, interrupts, etc. that are not really compatible with Rust's memory model - after all Rust's immutable borrows should guarantee the values you are reading are not aliased by writers and should be staying constant as long as the borrow exists. This is obviously not true when the CPU can either yank away the execution to a different part of the program, or some foreign entity can overwrite your memory. Additionally, in low-level embedded systems, the existence of malloc is not a given, yet Rust seems to assume you can dynamically allocate memory with a stateless allocator.
- QuiEgo 10mo agoI’d like to take a swipe at this Rust has no_std to handle not having an allocator. Tons of things end up being marked “unsafe” in systems/embedded Rust. The idea is you sandbox the unsafeness. Libraries like zero copy are a good example of “containing” unsafe memory accesses in a way that still gets you as much memory safety as possible given the realities of embedded. Tl;dr you don’t get as much safety as higher level code but you still get more than C. Or maybe put a different way you are forced to think about the points that are inherently unsafe and call them out explicitly (which is great when you think about how to test the thing)
- torginus 10mo agoDunno. I used to do embedded. A ton of (highly capable) systems have tiny amounts of RAM (like 32kb-128kb). Usually these controllers run a program in an infinite event loop (with perhaps a sleep in the end of the iteration), communication with peripherals is triggered via interrupts. There's no malloc, memory is pre-mapped. This means: - All lifetimes are either 'stack' or 'forever' - Thread safety in the main loop is ensured by disabling interrupts in the critical section - Rust doesn't understand this paradigm (it can be taught to, I'm sure) - Thread safety in ISRs should also be taught to Rust - Peripherals read and write to memory via DMA, unbekownst to the CPU etc. So all in all, I don't see Rust being that much more beneficial (except for stuff like array bounds checking). I'm sure you can describe all these behaviors to Rust so that it can check your program, but threading issues are limited, and there's no allocation, and no standard lib (or much else from cargo). Rust may be a marginally better language than C due to some convenience features, but I feel like there's too much extra work very little benefit.
- QuiEgo 10mo agoNot trying to make a value judgement on Rust either, just brainstorming why Rust changeover might go slow per the question. FWIW I work in firmware with the heap turned off. I’ve worked on projects in both C and Rust, and agree Rust still adds useful checks (at the cost of compile times and binary sizes). It seems worth the trade off for most projects.
- goku12 10mo agoOkay. That sounds like a reasonable explanation. Thanks!