4 ms·

Some days ago I decided to look at Zig a bit more in detail. So I skipped the usual marketing and I checked why it could be an alternative to C or Rust. Could i

by mk89 11mo ago

Some days ago I decided to look at Zig a bit more in detail. So I skipped the usual marketing and I checked why it could be an alternative to C or Rust. Could it be? It seems that (debug) allocators are a nice idea, however, it seems that they exist "somehow" already for C, so I wonder: why would you pick this language for your next low level program? They provide runtime checks, so you need thorough testing before you can spot use-after-free or so. It's very similar to the existing situation with c/c++ and the sanitizers, although they work a bit differently. So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators like hardened_malloc[0] instead of starting a new programming language? It would probably be less expensive in terms of time and would help fix existing software. [0]: https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc

astrobe_ 11mo ago
> So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators A partial answer is that part of low-level programmers avoid memory allocation and threads like plague. In some cases they are not even an option (small embedded programming, it's nearly as low-level as you can get before going hardcore for real with assembly programming), but when they can the keywords are efficiency, reliability, predictability, and simplicity : statically allocating in advance is a thing you can do because the product is typically with max specs written on the box (e.g. max number of entries in a phone book, to take a generic dumb example), and you have to meet these requirements even if the customer uses all of the capabilities to the max; no memory overbooking allowed, which is basically what dynamic allocation is, in a sense. > instead of starting a new programming language If I were to start a new low-low level programming language, I would basically just fix C's weak typing problem, fix the UB problems that only come from issues with long-gone processors (like C++11 finally did with sign encoding), "backport" some C++ features (templates? constexpr?), add a pinch of syntactic sugar and fix union types to have proper sum types. But probably I've just described D and apparently a significant chunk of C23.
- uecker 11mo ago
  Indeed, and if someone wants to help work on C, this is very much possible both on the compiler side or on the standards side.
bvrmn 11mo ago
Slices and UB-explicitness are quite nice comparing to C. Makes head free to think about really important things.
brabel 11mo ago
People are also doing that, see FillC. It's just different people doing different things because, well, they have freedom to do what they want.

by mk89 11mo ago

astrobe_ 11mo ago

> So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators A partial answer is that part of low-level programmers avoid memory allocation and threads like plague. In some cases they are not even an option (small embedded programming, it's nearly as low-level as you can get before going hardcore for real with assembly programming), but when they can the keywords are efficiency, reliability, predictability, and simplicity : statically allocating in advance is a thing you can do because the product is typically with max specs written on the box (e.g. max number of entries in a phone book, to take a generic dumb example), and you have to meet these requirements even if the customer uses all of the capabilities to the max; no memory overbooking allowed, which is basically what dynamic allocation is, in a sense. > instead of starting a new programming language If I were to start a new low-low level programming language, I would basically just fix C's weak typing problem, fix the UB problems that only come from issues with long-gone processors (like C++11 finally did with sign encoding), "backport" some C++ features (templates? constexpr?), add a pinch of syntactic sugar and fix union types to have proper sum types. But probably I've just described D and apparently a significant chunk of C23.

uecker 11mo ago
Indeed, and if someone wants to help work on C, this is very much possible both on the compiler side or on the standards side.

bvrmn 11mo ago

Slices and UB-explicitness are quite nice comparing to C. Makes head free to think about really important things.

brabel 11mo ago

People are also doing that, see FillC. It's just different people doing different things because, well, they have freedom to do what they want.