[DamonHD]

For simple things I also like shell scripts. But for bigger more complex systems, especially with long life-times, many users and many developers, the sharp edges get too dangerous. In those case I move to Java or at least something with stronger typing, and less chance of memory management errors.

My last big project was 100kloc C/C++ in a radiator valve though. Not many languages with a run-time would have fit in the 32kB code space for that project.

[silentpuck]

I think that's the beauty of C — it lets you fit logic into 32kB without screaming.

For me it's not about "modern safety" — it's about knowing that every byte is mine. But yeah, I get the tradeoff when you’ve got teams, timelines and a JVM.

[PaulHoule]

I still use C to write little programs for Ardunio but it drives me nuts thinking about all the useless stuff C is doing with the stack and calling convention when I could just use global variables for everything and sometimes even use nothing but registers for inner loop variables.

I stick with C because (1) I'd have to figure out the tooling for 100% assembly development on AVR-8, and (2) C is portable to other platforms so if I want to migrate to an ARM or ESP-32 board it would be easy. (The upward migration path for AVR-8 is to go to a soft core on an FPGA but talk about frying pan to the fire)

[tuatoru]

I've been trending towards "C with namespaces" for Arduino on AVR-8.

With namespaces you can have globals and few collisions. At the expense of more typing, of course.

You do know about the "register" storage class/keyword, I am sure. Sometimes it works.

Edit - the tooling for AVR assembler seems to be avr-gcc and make. Check out Nerd Ralph's "ArduinoShrink" library for an example of blended C and assembler:

https://github.com/nerdralph/ArduinoShrink/tree/master

[DamonHD]

The 100kloc thing had no malloc/free, ie most significant persistent data objects were static, and the inlining with LTO (and some help) was pretty intense, so the stack was used, but not as much as it seemed on the surface. We did (re)invent some carefully managed buffers shared through several levels of call, since we were doing, for example, AES-GCM: https://github.com/opentrv/OTAESGCM

[silentpuck]

Yeah, the stack can be such a headache. I remember how much pain I went through just trying to wrap my head around it — even gave up a few times.

But then I’d cool down… and come back to it. Some languages just never “clicked” for me, but somehow I keep coming back to C.

[DamonHD]

BTW you can get very close to the metal in Java too if you are so inclined - I was part of a team doing high-speed trading with microseconds timing and minimal GC in Java. A very few 'unsafe' lines made that possible (but also the possibility to crash the JVM far far faster than it could exit otherwise!)...

[silentpuck]

That’s fascinating. I never thought Java could get that close without tripping on GC. Must’ve taken a lot of careful design and deep understanding.

I’d honestly love to read more about setups like that — maybe in my quiet hours. Feels like something worth studying, even if I keep walking the C path for now.