4 ms·

https://github.com/ziglang/zig https://github.com/ziglang/zig and Jonathan Blow's JAI language seem to be contenders for C replacement.

bokglobule 8y ago
Arguably the Rust language is a replacement candidate for 'C' (and C++).
- 1bent 8y ago
  I'm studying Rust, though wouldn't claim I know it yet. I believe Rust is an effort to create a language in which you can write code that's as fast and portable as C; and yet, for which, the compiler can help you coordinate a "single owner permitted to write" strategy for thread safety -- at the expense of increased bother and fuss coaxing your program into that pattern. I wouldn't call it a C replacement; while I'm glad to have Rust available, I prefer concurrency (when I need it at all) via processes, rather than threads, with no shared memory.
  - kbenson 8y ago
    > while I'm glad to have Rust available, I prefer concurrency (when I need it at all) via processes, rather than threads, with no shared memory. Are you implying that Rust can't do multi-processing through processes?
    - 1bent 8y ago
      I don't know yet. I've heard about at least two languages that adore threads, and have issues with multi-processing. Perl6 has threads in its runtime helping its GC --- and calling fork kills its programs. I don't know yet if rust has threads _required_ in a fashion that makes it crash if you try to fork(). perl6 cannot fork; and golang behaves badly if you fork in a program that uses goroutines. Ends up unhappy, since shared library manipulation is kinda dependent on the process loader. Oops. I'm tempted to hope that the Rust lang devs have kept use of threads out of its required runtime. To answer your question, I didn't mean to imply that rust cannot call fork(2), and I hope it isn't true. I meant to say that I wouldn't call Rust a C replacement; it's an effort to solve a problem (threads with shared heap or stack) that C flat doesn't attempt to consider. I love C, and feel obliged to learn Rust.
      - lizmat 8y ago
        FWIW, Perl 6 does have `Proc` (to run an external process) and `Proc::Async` (to run an external process asynchronously). But `fork`, no: it was decided that `fork` was a unixism that was not supportable on OS's like Windows. And it was also decided to not make the same mistake that Perl 5 made with regards to trying to mimic `fork` on Windows, and use that idea later to try to mimic threads on non-Windows OS's.
        1bent 8y ago
        Thank you! That's great to hear. I'm sorry that they chose that direction; I'd much, much rather not support Windows than not support Unix's fundamental primitive for multiprocessing (and its coordinated IPC). But I do realize that not everyone can act on such preferences. Fortunately, perl5 is still well and strong.
      - nicoburns 8y ago
        Rust has no more runtime than c. Threads are implemented in the standard library, but they'll only be used if you explicitly create one (or a library you are using does). Fork works fine :) Rust has a very different design philosphy to c, and in that respect you are right that it isn't a complete replacement. That said, Rust is good for far more than just multithreading. It solves memory safety as well as tgread safety.
        steveklabnik 8y ago
        > Fork works fine. It can work but it’s quite unsafe. The standard library doesn’t make any guarantees about fork safety. The language itself doesn’t understand what fork is, and so can’t guarantee anything.
  - steveklabnik 8y ago
    These guarantees are useful for more than threads, too: http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit...
- msla 8y ago
  > Arguably the Rust language is a replacement candidate for 'C' (and C++). Or is it C and 'C++'? As it happens, I disagree, because I think a lot of programmers who can otherwise handle pointers and manual memory allocation are going to revolt if we made them do the explicit ownership management notation Rust demands. It's too different from anything done in any other language, and the push-back that it's "too high-level" and "inefficient" and "bloated" will kill it for sure.
jcalabro 8y ago
I'm very excited about Jai and I'm eager to test it out when it's released!
WalterBright 8y ago
And, of course, DasBetterC (D as a Better C), which is a D subset designed to only require the existence of the C runtime library.
- ropeadopepope 8y ago
  Zig and Jai were designed to not require the C runtime library. You can't replace C if you're building on top of it, can you?
  - WalterBright 8y ago
    You'll need something to set up an entry point, stack, somewhere for assert() failures to go, etc. The C library is minimal enough and fine for that. If you know what you're doing, it's easy enough to take care of those services yourself with DasBetterC.
    - backpropaganda 8y ago
      That something can be written in machine code or the alternative language though. Could you provide a link for DasBetterC? Googling didn't really lead to anything.
      - WalterBright 8y ago
        The name is a bit of a pun. I wrote a presentation at DConf "D as Better C" and noticed what I'd unintentionally written :-) https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html http://dconf.org/2018/talks/bright.html http://dconf.org/2018/talks/bright.html

bokglobule 8y ago

Arguably the Rust language is a replacement candidate for 'C' (and C++).

1bent 8y ago
I'm studying Rust, though wouldn't claim I know it yet. I believe Rust is an effort to create a language in which you can write code that's as fast and portable as C; and yet, for which, the compiler can help you coordinate a "single owner permitted to write" strategy for thread safety -- at the expense of increased bother and fuss coaxing your program into that pattern. I wouldn't call it a C replacement; while I'm glad to have Rust available, I prefer concurrency (when I need it at all) via processes, rather than threads, with no shared memory.
- kbenson 8y ago
  > while I'm glad to have Rust available, I prefer concurrency (when I need it at all) via processes, rather than threads, with no shared memory. Are you implying that Rust can't do multi-processing through processes?
  - 1bent 8y ago
    I don't know yet. I've heard about at least two languages that adore threads, and have issues with multi-processing. Perl6 has threads in its runtime helping its GC --- and calling fork kills its programs. I don't know yet if rust has threads _required_ in a fashion that makes it crash if you try to fork(). perl6 cannot fork; and golang behaves badly if you fork in a program that uses goroutines. Ends up unhappy, since shared library manipulation is kinda dependent on the process loader. Oops. I'm tempted to hope that the Rust lang devs have kept use of threads out of its required runtime. To answer your question, I didn't mean to imply that rust cannot call fork(2), and I hope it isn't true. I meant to say that I wouldn't call Rust a C replacement; it's an effort to solve a problem (threads with shared heap or stack) that C flat doesn't attempt to consider. I love C, and feel obliged to learn Rust.
    - lizmat 8y ago
      FWIW, Perl 6 does have `Proc` (to run an external process) and `Proc::Async` (to run an external process asynchronously). But `fork`, no: it was decided that `fork` was a unixism that was not supportable on OS's like Windows. And it was also decided to not make the same mistake that Perl 5 made with regards to trying to mimic `fork` on Windows, and use that idea later to try to mimic threads on non-Windows OS's.
      - 1bent 8y ago
        Thank you! That's great to hear. I'm sorry that they chose that direction; I'd much, much rather not support Windows than not support Unix's fundamental primitive for multiprocessing (and its coordinated IPC). But I do realize that not everyone can act on such preferences. Fortunately, perl5 is still well and strong.
    - nicoburns 8y ago
      Rust has no more runtime than c. Threads are implemented in the standard library, but they'll only be used if you explicitly create one (or a library you are using does). Fork works fine :) Rust has a very different design philosphy to c, and in that respect you are right that it isn't a complete replacement. That said, Rust is good for far more than just multithreading. It solves memory safety as well as tgread safety.
      - steveklabnik 8y ago
        > Fork works fine. It can work but it’s quite unsafe. The standard library doesn’t make any guarantees about fork safety. The language itself doesn’t understand what fork is, and so can’t guarantee anything.
- steveklabnik 8y ago
  These guarantees are useful for more than threads, too: http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit...
msla 8y ago
> Arguably the Rust language is a replacement candidate for 'C' (and C++). Or is it C and 'C++'? As it happens, I disagree, because I think a lot of programmers who can otherwise handle pointers and manual memory allocation are going to revolt if we made them do the explicit ownership management notation Rust demands. It's too different from anything done in any other language, and the push-back that it's "too high-level" and "inefficient" and "bloated" will kill it for sure.

jcalabro 8y ago

I'm very excited about Jai and I'm eager to test it out when it's released!

WalterBright 8y ago

And, of course, DasBetterC (D as a Better C), which is a D subset designed to only require the existence of the C runtime library.

ropeadopepope 8y ago
Zig and Jai were designed to not require the C runtime library. You can't replace C if you're building on top of it, can you?
- WalterBright 8y ago
  You'll need something to set up an entry point, stack, somewhere for assert() failures to go, etc. The C library is minimal enough and fine for that. If you know what you're doing, it's easy enough to take care of those services yourself with DasBetterC.
  - backpropaganda 8y ago
    That something can be written in machine code or the alternative language though. Could you provide a link for DasBetterC? Googling didn't really lead to anything.
    - WalterBright 8y ago
      The name is a bit of a pun. I wrote a presentation at DConf "D as Better C" and noticed what I'd unintentionally written :-) https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html http://dconf.org/2018/talks/bright.html http://dconf.org/2018/talks/bright.html