6 ms·

Why not just use C++? Also why can we not get better syntax for C? Function pointer syntax is so bad that people actively avoid using them. #pragma once is a h

Why not just use C++? Also why can we not get better syntax for C? Function pointer syntax is so bad that people actively avoid using them. #pragma once is a hack. Every string library function is actively dangerous in addition to puts/gets. I know that nobody wants to be the one to mess with the core language and ruin it but this is awfully low-hanging fruit that hasn’t been fixed in 50 years.

mirekrusin 4y ago
It has been fixed. The fix has the codename "zig".
- shrimp_emoji 4y ago
  I heard it was "Rust".
  - chaosite 4y ago
    Rust is more comparable to C++ than C.
  - anfilt 4y ago
    Rust is not exactly a C replacement. Definitely the better choice these days over C++ in my opinion if you can use rust. It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C.
    - masklinn 4y ago
      > Rust is not exactly a C replacement. Rust is absolutely a C replacement. Whether C heads want to use it is a more complicated question. But some are very much into it (e.g. Brian Cantrill). > It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C. std assumes you have a heap and IO, which most C environments do. no_std removes all that (leaving only libcore as baseline), however you can re-add a dependency on "alloc" to get allocations and most of the standard collections back (all but hashset and hashmap, because no secure RNG). You can also / instead fill your needs with third-party crates more dedicated to restricted or freestanding environments, like heapless (https://crates.io/crates/heapless https://crates.io/crates/heapless).
      - tialaramex 4y ago
        You get a lot more in core (and thus no-std) than the free standing C language. For example C's qsort lives in the standard library, whereas in Rust although [].sort() needs alloc, the [].sort_unstable() is a core feature! str::split_once(['5', '7']) will split a string at the first digit 5 or 7... You need considerable work to do that in C, and doing it modifies the string. In Rust it's a core feature. Of course Rust is relying on the fact that none of the machine code is emitted unless you use these features, indeed split_once is fully generic, the types used only come into existence because you called the function. So presumably this was not practical as the fundamental language for writing Unix fifty years ago.
      - maxbond 4y ago
        I think you & GP are using different senses of replacement ("drop in replacement" vs. "replacement for greenfield projects"). You might consider Rust to be the latter (with qualifications, eg, excluding certain architectures & proprietary programming environments) but it's explicitly not the former (it's interoperable with C, but not compatible with C). I think we should avoid saying "replacement" in general because eliminating all lines of C isn't a goal worth pursuing, C doesn't need to die for Rust to succeed, and there's room enough in this world for a hundred safe systems languages fulfilling different niches. I think a lot of people feel attacked & invalidated by the idea of a "C replacement" that isn't C compatible, like we're telling them their skills are no longer necessary or valuable, which is untrue & leads to flamewars and misunderstandings.
        zozbot234 4y ago
        Rust is absolutely a "drop-in" replacement to C in most cases even for existing projects, it was absolutely built with that goal in mind. You can go as fine-grained as replacing a single function with a Rust-coded version (even using bindgen to ingest existing C headers) - though that generally involves unsafety because you're dealing with general pointers, extern calls and such. Even Checked C cannot prove these things 100% safe, it just catches common misuse. (Of course some C projects could abuse the preprocessor in ways that make it infeasible to even replace a C function with a Rust equivalent, but that's incredibly rare. And Rust has macro facilities of its own.)
    - jcranmer 4y ago
      > It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C. Rust's #![no_std] mode corresponds to what C calls freestanding mode, and Rust is relatively unusual in many modern languages in actually designing some sort of freestanding mode.
- seanw444 4y ago
  Looking forward to it becoming more mature. Really cool language.
- pjmlp 4y ago
  It isn't a fix when it still allows for use after free.
- gnramires 4y ago
  Check out nim as well, it compiles to c, and it's really an absolute joy to use!
constantcrying 4y ago
>Also why can we not get better syntax for C? Backwards compatability. >Function pointer syntax is so bad that people actively avoid using them. That is because C syntax mistakenly put the return value before the parameters. You use function pointers if you have to. >#pragma once is a hack. It is a hack to prevent the previous hack of #ifdef'ing the thing. >but this is awfully low-hanging fruit that hasn’t been fixed in 50 years. It is literally impossible to fix.
- elcritch 4y ago
  Ugh, the C syntax makes it so hard to parse, humans or machine. I recently submitted a PR for the `c2nim` import tool to handle double function pointers. I didn't actually understand the C code until I got the transpiler working despite cdecl.org: // posix signal void(*signal(int, void (*)(int)))(int); in Nim becomes: var signal*: proc (a1: cint; a2: proc (a1: cint)): proc (a1: cint) Well I'm 99.5% certain at least. Even now I'm uncertain of the C syntax. And I've not been bold enough to test 3rd order C function pointers. I figure that's probably C code you don't wanna touch if possible. https://github.com/nim-lang/c2nim/blob/11f2c5363dfe7e8c7c8ce78680aa9eefa762c2a3/testsuite/results/pointerdecls.nim https://github.com/nim-lang/c2nim/blob/11f2c5363dfe7e8c7c8ce... The other annoying one is that "signed" and "unsigned" are basically adjectives, but "long" can be both a type and a modifier. So it's difficult to parse unless you're the target C compiler. Technically you can, but you have to use backtracking.
  - secondcoming 4y ago
    That nim version isn’t much better IMO, but I am unfamiliar with the language.
    - kelnos 4y ago
      I'm completely unfamiliar with the language but was able to read it from left-to-right very easily: var signal*: proc (a1: cint; a2: proc (a1: cint)): proc (a1: cint) That reads to me as: Variable signal is a pointer to a function that that takes two arguments (an int, and a function that takes an int), and returns a function that takes one argument (an int). Of course, I'm assuming my interpretation is correct... perhaps it's not ;)
flohofwoe 4y ago
The stdlib needs a modernization much more than the language, unlike 'C the language', 'C the stdlib' is still stuck deep in the K&R era (together with POSIX). For a different language syntax it makes a lot more sense to consider using a different language in the first place though, because everybody has a different opinion what such a 'better C' syntax should look like (e.g. it sounds like you'd actually want Zig).
WalterBright 4y ago
D has had a BetterC subset of D for a while: https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html
deleted 4y ago
[deleted]
omeysalvi 4y ago
>Why not just use C++? Nothing good has come to anyone who started an argument with those words.
gavinray 4y ago
Am sort of curious what the difference is between this and templated constexpr functions with span<T, N> in C++

mirekrusin 4y ago

It has been fixed. The fix has the codename "zig".

shrimp_emoji 4y ago
I heard it was "Rust".
- chaosite 4y ago
  Rust is more comparable to C++ than C.
- anfilt 4y ago
  Rust is not exactly a C replacement. Definitely the better choice these days over C++ in my opinion if you can use rust. It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C.
  - masklinn 4y ago
    > Rust is not exactly a C replacement. Rust is absolutely a C replacement. Whether C heads want to use it is a more complicated question. But some are very much into it (e.g. Brian Cantrill). > It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C. std assumes you have a heap and IO, which most C environments do. no_std removes all that (leaving only libcore as baseline), however you can re-add a dependency on "alloc" to get allocations and most of the standard collections back (all but hashset and hashmap, because no secure RNG). You can also / instead fill your needs with third-party crates more dedicated to restricted or freestanding environments, like heapless (https://crates.io/crates/heapless https://crates.io/crates/heapless).
    - tialaramex 4y ago
      You get a lot more in core (and thus no-std) than the free standing C language. For example C's qsort lives in the standard library, whereas in Rust although [].sort() needs alloc, the [].sort_unstable() is a core feature! str::split_once(['5', '7']) will split a string at the first digit 5 or 7... You need considerable work to do that in C, and doing it modifies the string. In Rust it's a core feature. Of course Rust is relying on the fact that none of the machine code is emitted unless you use these features, indeed split_once is fully generic, the types used only come into existence because you called the function. So presumably this was not practical as the fundamental language for writing Unix fifty years ago.
    - maxbond 4y ago
      I think you & GP are using different senses of replacement ("drop in replacement" vs. "replacement for greenfield projects"). You might consider Rust to be the latter (with qualifications, eg, excluding certain architectures & proprietary programming environments) but it's explicitly not the former (it's interoperable with C, but not compatible with C). I think we should avoid saying "replacement" in general because eliminating all lines of C isn't a goal worth pursuing, C doesn't need to die for Rust to succeed, and there's room enough in this world for a hundred safe systems languages fulfilling different niches. I think a lot of people feel attacked & invalidated by the idea of a "C replacement" that isn't C compatible, like we're telling them their skills are no longer necessary or valuable, which is untrue & leads to flamewars and misunderstandings.
      - zozbot234 4y ago
        Rust is absolutely a "drop-in" replacement to C in most cases even for existing projects, it was absolutely built with that goal in mind. You can go as fine-grained as replacing a single function with a Rust-coded version (even using bindgen to ingest existing C headers) - though that generally involves unsafety because you're dealing with general pointers, extern calls and such. Even Checked C cannot prove these things 100% safe, it just catches common misuse. (Of course some C projects could abuse the preprocessor in ways that make it infeasible to even replace a C function with a Rust equivalent, but that's incredibly rare. And Rust has macro facilities of its own.)
  - jcranmer 4y ago
    > It can be made to function more like C with #![no_std]. However that is an even less than batteries included experience than C. Rust's #![no_std] mode corresponds to what C calls freestanding mode, and Rust is relatively unusual in many modern languages in actually designing some sort of freestanding mode.
seanw444 4y ago
Looking forward to it becoming more mature. Really cool language.
pjmlp 4y ago
It isn't a fix when it still allows for use after free.
gnramires 4y ago
Check out nim as well, it compiles to c, and it's really an absolute joy to use!

constantcrying 4y ago

>Also why can we not get better syntax for C? Backwards compatability. >Function pointer syntax is so bad that people actively avoid using them. That is because C syntax mistakenly put the return value before the parameters. You use function pointers if you have to. >#pragma once is a hack. It is a hack to prevent the previous hack of #ifdef'ing the thing. >but this is awfully low-hanging fruit that hasn’t been fixed in 50 years. It is literally impossible to fix.

elcritch 4y ago
Ugh, the C syntax makes it so hard to parse, humans or machine. I recently submitted a PR for the `c2nim` import tool to handle double function pointers. I didn't actually understand the C code until I got the transpiler working despite cdecl.org: // posix signal void(*signal(int, void (*)(int)))(int); in Nim becomes: var signal*: proc (a1: cint; a2: proc (a1: cint)): proc (a1: cint) Well I'm 99.5% certain at least. Even now I'm uncertain of the C syntax. And I've not been bold enough to test 3rd order C function pointers. I figure that's probably C code you don't wanna touch if possible. https://github.com/nim-lang/c2nim/blob/11f2c5363dfe7e8c7c8ce78680aa9eefa762c2a3/testsuite/results/pointerdecls.nim https://github.com/nim-lang/c2nim/blob/11f2c5363dfe7e8c7c8ce... The other annoying one is that "signed" and "unsigned" are basically adjectives, but "long" can be both a type and a modifier. So it's difficult to parse unless you're the target C compiler. Technically you can, but you have to use backtracking.
- secondcoming 4y ago
  That nim version isn’t much better IMO, but I am unfamiliar with the language.
  - kelnos 4y ago
    I'm completely unfamiliar with the language but was able to read it from left-to-right very easily: var signal*: proc (a1: cint; a2: proc (a1: cint)): proc (a1: cint) That reads to me as: Variable signal is a pointer to a function that that takes two arguments (an int, and a function that takes an int), and returns a function that takes one argument (an int). Of course, I'm assuming my interpretation is correct... perhaps it's not ;)

flohofwoe 4y ago

The stdlib needs a modernization much more than the language, unlike 'C the language', 'C the stdlib' is still stuck deep in the K&R era (together with POSIX). For a different language syntax it makes a lot more sense to consider using a different language in the first place though, because everybody has a different opinion what such a 'better C' syntax should look like (e.g. it sounds like you'd actually want Zig).

WalterBright 4y ago

D has had a BetterC subset of D for a while: https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html

deleted 4y ago

[deleted]

omeysalvi 4y ago

>Why not just use C++? Nothing good has come to anyone who started an argument with those words.

gavinray 4y ago

Am sort of curious what the difference is between this and templated constexpr functions with span<T, N> in C++