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
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.
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.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
C is meant for embedded stuff. #changemymind
I have used both C and Rust for embedded. Rust is significantly more enjoyable. https://embassy.dev/
C is good for nothing.
@excitingburp @NocturnalMorning “C is good for nothing because I don’t enjoy it” yea that’s some big brain logic right there
Even for small 4/8 bit soc systems?
I had the idea that C was the go-to language for that.
It probably won’t do anything less than 32bit, so that’s at least one thing C is good for.
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
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.
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.
Because RAM is so cheap, right?
System programming
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.
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.
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.
Sounds like you just need a bigger graphics card to me. 😂
What kind of pointer operations?
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.
😂
Exactly for that a memory safe language would avoid so many security vulnerabilities.