Ease of access to the underlying hardware in your programming language is only ever needed for embedded programming in the current year. Change my mind.
There are actual use cases where direct memory access and pointer magic can be very efficient or almost necessary.
We work a lot with large images and basically always the first steps are some pointer operations.
When you’re writing code involving global state and interrupts, and any access to an integer larger than a u8 needs to be surrounded by cli() and sei() just for guaranteed atomicity, then you will truly come to value rust’s statically enforced thread / memory safety.
Are those still in use? With how cheap modern MCUs got, it kinda seems like it often makes more sense to get smth a bit more powerful and get the benefits of overall easier and faster development. May be wrong here, tho – it’s not like I compared numbers or something
Addit: I mean, 8 bit may easily still be a bit cheaper, yet corps will likely spend more than the difference in price paying devs
For years I wrote embedded C for 8 bit microcontrollers used in industrial controls.
Never again.
Rust is by far a better language for embedded. The only times I would consider it reasonable to write embedded code in C is if you’re doing it for fun, or you depend on an existing and well tested / audited codebase or library and your application logic is less complicated than rust to C FFI.
Even then, you won’t find me contributing to that effort.
Or micropython. That might sound nuts, but consider that Python was released two years after the 486 and two years before the Pentium. The RP2040 microcontroller has a far higher clock rate than those, has dual cores, and costs a dollar. It may lack RAM compared to some of those desktops at the time, though.
C is meant for embedded stuff. #changemymind
System programming
That article is incomplete. Nowhere do I see JavaScript listed.
😂
It seems the cancer has metastasized. First to the backend, now to the entire operating system.
Ease of access to the underlying hardware in your programming language is only ever needed for embedded programming in the current year. Change my mind.
There are actual use cases where direct memory access and pointer magic can be very efficient or almost necessary. We work a lot with large images and basically always the first steps are some pointer operations.
What kind of pointer operations?
Sounds like you just need a bigger graphics card to me. 😂
It’s required for drivers too.
That’s basically embedded programming, or pretty similar.
Every operating system running on bare metal needs access to the hardware. And if not on bare metal, it needs access to the virtual hardware.
Exactly for that a memory safe language would avoid so many security vulnerabilities.
Because RAM is so cheap, right?
I have used both C and Rust for embedded. Rust is significantly more enjoyable. https://embassy.dev/
C is good for nothing.
Even for small 4/8 bit soc systems?
I had the idea that C was the go-to language for that.
Yes: https://github.com/avr-rust
When you’re writing code involving global state and interrupts, and any access to an integer larger than a u8 needs to be surrounded by cli() and sei() just for guaranteed atomicity, then you will truly come to value rust’s statically enforced thread / memory safety.
There’s Assembly for those
Are those still in use? With how cheap modern MCUs got, it kinda seems like it often makes more sense to get smth a bit more powerful and get the benefits of overall easier and faster development. May be wrong here, tho – it’s not like I compared numbers or something
Addit: I mean, 8 bit may easily still be a bit cheaper, yet corps will likely spend more than the difference in price paying devs
It probably won’t do anything less than 32bit, so that’s at least one thing C is good for.
@excitingburp @NocturnalMorning “C is good for nothing because I don’t enjoy it” yea that’s some big brain logic right there
For years I wrote embedded C for 8 bit microcontrollers used in industrial controls.
Never again.
Rust is by far a better language for embedded. The only times I would consider it reasonable to write embedded code in C is if you’re doing it for fun, or you depend on an existing and well tested / audited codebase or library and your application logic is less complicated than rust to C FFI.
Even then, you won’t find me contributing to that effort.
Rust is making inroads.
Or micropython. That might sound nuts, but consider that Python was released two years after the 486 and two years before the Pentium. The RP2040 microcontroller has a far higher clock rate than those, has dual cores, and costs a dollar. It may lack RAM compared to some of those desktops at the time, though.