8 ms·

I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C w

I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that make it annoying to program in. But since Zig 1.0 is unlikely until 2026 I'd say we wouldn't start seeing Zig majorly displace any C programs until about ten years after 1.0, which would be 2036. Rust 1.0 was in 2015 and we are just starting to see it in the Linux kernel ~ 8 years out, so that seems like a good timeline. Then just give it another 40 years and I could see a future where Zig and Rust replace all code where C is currently used. Sure there might be some ancient legacy systems that use C, but just like COBOL, would not be something that you would come across unless you wanted to.

keewee7 4y ago
Is there a reason Zig is taking so long to go 1.0? The language itself feels mature.
- ptato 4y ago
  the self-hosted rewrite took a long time so it felt like the project had stalled for the past ~year. the team has started working on new features like the package manager, though.
addaon 4y ago
Is there any other systems language that's even moving towards a mature ecosystem with a compiler like CompCert? It feels like this is still decades away for any realistic competitor to C.
zozbot234 4y ago
SafeC and CheckedC do nothing for temporal safety. Zig is in the same boat. There's not really a simpler alternative to Rust with the same featureset, even its direct predecessor Cyclone was in fact quite a bit harder to use. Rust itself is also improving very quickly and becoming easier to use over time.
- elcritch 4y ago
  Unfortunately, Rust's core design philosophy is fundamentally opposed to much of the design philosophy that made C and C++ so popular and flexible. It's almost the exact opposite extreme on the pendulum, where C allowed anything while Rust limits to only what the language designers conceive as proper and not just safe. Zig can gain memory management systems like Nim's ARC which works well for system design and adds temporal safety. On the other hand Rust's trait system likely will never become an "open ended" type system like say Julia's. Heck, even overloaded function types don't seem likely in Rust.
  - estebank 4y ago
    What task can you do in C that you can't in Rust (or Zig, for that matter)?
    - elcritch 4y ago
      No, I'd count Zig as having more of an "open ended" type system / philosophy. Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `vec.insert(...)`. The biggest ones for me in Rust is that it disallows extending traits for types you don't own, and the lack of function overloading. Neither of those are required for the borrow checker or safety, but it's a philosophical design decision. 1: https://github.com/ziglang/zig/issues/1251 https://github.com/ziglang/zig/issues/1251
      - kristoff_it 4y ago
        > Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `vec.insert(...)`. Zig doesn't have function overloading but it does have namespaced functions, so you can define your types and your "methods" on them. https://ziglang.org/documentation/master/#struct https://ziglang.org/documentation/master/#struct
WalterBright 4y ago
D (in betterC mode) is C but with proper arrays, modules, advanced metaprogramming, member functions, lots of memory safety features, compile time function execution, nested functions, etc.

keewee7 4y ago

Is there a reason Zig is taking so long to go 1.0? The language itself feels mature.

ptato 4y ago
the self-hosted rewrite took a long time so it felt like the project had stalled for the past ~year. the team has started working on new features like the package manager, though.

addaon 4y ago

Is there any other systems language that's even moving towards a mature ecosystem with a compiler like CompCert? It feels like this is still decades away for any realistic competitor to C.

zozbot234 4y ago

SafeC and CheckedC do nothing for temporal safety. Zig is in the same boat. There's not really a simpler alternative to Rust with the same featureset, even its direct predecessor Cyclone was in fact quite a bit harder to use. Rust itself is also improving very quickly and becoming easier to use over time.

elcritch 4y ago
Unfortunately, Rust's core design philosophy is fundamentally opposed to much of the design philosophy that made C and C++ so popular and flexible. It's almost the exact opposite extreme on the pendulum, where C allowed anything while Rust limits to only what the language designers conceive as proper and not just safe. Zig can gain memory management systems like Nim's ARC which works well for system design and adds temporal safety. On the other hand Rust's trait system likely will never become an "open ended" type system like say Julia's. Heck, even overloaded function types don't seem likely in Rust.
- estebank 4y ago
  What task can you do in C that you can't in Rust (or Zig, for that matter)?
  - elcritch 4y ago
    No, I'd count Zig as having more of an "open ended" type system / philosophy. Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `vec.insert(...)`. The biggest ones for me in Rust is that it disallows extending traits for types you don't own, and the lack of function overloading. Neither of those are required for the borrow checker or safety, but it's a philosophical design decision. 1: https://github.com/ziglang/zig/issues/1251 https://github.com/ziglang/zig/issues/1251
    - kristoff_it 4y ago
      > Though, it looks like Zig doesn't do function overloading either [1]. That's a disappointment. So you end up with `array_count`, `map_count`, etc instead of just `count`. In my way of thinking that's more work reduces readability. It's one of the paint points of C vs C++ to need `array_list_count` and `hash_map_add` instead of just saying `vec.insert(...)`. Zig doesn't have function overloading but it does have namespaced functions, so you can define your types and your "methods" on them. https://ziglang.org/documentation/master/#struct https://ziglang.org/documentation/master/#struct

WalterBright 4y ago

D (in betterC mode) is C but with proper arrays, modules, advanced metaprogramming, member functions, lots of memory safety features, compile time function execution, nested functions, etc.