7 ms·

Honestly, I don't see it happening. Zig and rust and jai and d all feast on c's remains, but the result can only be fragmentation. And then you lose one of th

Honestly, I don't see it happening. Zig and rust and jai and d all feast on c's remains, but the result can only be fragmentation. And then you lose one of the big draws of c: ubiquity. Zig has two compilers. Rust has one (serious) compiler. Jai has 1, d has either 1.5 or 3.5 (depending on how you count). And although all those languages want to replace c as the language-that-you-use-for-everything, and they might each be better than c as a language-that-you-use-for-everything, but for a given use a 'lighter' language like python is frequently even better. And it gets to the point where the only languages that allow you to program anything (lisp and perl6, really) are garbage collected and have heavy runtimes, so they won't be taking over games or the os. C might die, but there's no replacing it. Sorry.

strmpnk 8y ago
I don't see any single thing replacing C (or C++) but what's interesting here is many of these languages work very well with the C ABI, not just as an FFI concept but with notions of memory and data layout. The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions). This lowers the barrier significantly. The hard part is build tool compatibility but I think there are a lot of good ideas being worked on actively, Zig and Rust being two examples of advanced programatic control over the build process. With a reasonable linker, it should be possible to combine these and more languages today. An interesting counter example to the binary interface compatibility story has been Go, which seems to let cgo become less and less functional in each release. The pressure to keep everything in Go is an interesting trade-off. I wonder if certain kinds of systems will be paying for this lock-in later down the line while other languages give much easier ways to gradually evolve and reuse code or adopt libraries from multiple communities removing the need to do yet-another-rewrite in language X kinds of projects. Or perhaps this kind of interoperation is overrated? Time will tell.
- timClicks 8y ago
  On build processes, it's surprising to me that the Rust community hasn't developed its own linker. I suppose LD works fine.
- earenndil 8y ago
  > The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions) That already works, not a hypothetical. I can write, right now, a zig function, call it from rust, slap the whole thing into a library and wrap it with d. It hasn't taken the world by storm because these languages provide support the system c abi and calling convention, but do not embrace it. If I write a fancy templated function in zig, d, or rust, the name mangling, type-information, templating, maybe even call conventions -- are all different. This is why I have been and continue to be disappointed that things like COM or the jvm or cli aren't more popular, because they actually work that way. I can write, right now a clojure function, call it from java and then pass it into kotlin. Effortlessly, it's just an import away. Sure there are, for example, stdlib conflicts in scala but overall it's a much more frictionless experience. The problem? COM is windows-specific, jvm and cli are managed runtimes and people don't like managed runtimes. Another place I look for a solution is racket, but again it wants to manage too much of the runtime to be practical. What zig is doing with the build system is great, the fact that the build script is actually a fully customizable script means it has a much better chance of taking off, but until I can import a jai module from d and call it in zig, we're gonna have problems. EDIT: something which possibly almost could have had a good chance of pulling this off is llvm. Except that llvm comes too late in the compilation process to be used to resolve imports and symbols. Something like libclang, maybe, except not specific to c and c++.
  - jplayer01 8y ago
    Wouldn't a managed runtime mean it isn't suited for systems programming? The benefit of something like Rust is it provides a lot of the benefits of a managed language while producing native code and "zero-cost abstractions". A runtime adds a lot of overhead etc.
    - pjmlp 8y ago
      C also has a runtime, that is what takes care of calling main(), handling VLAs, floating point emulation, constructor/destructors (GCC C extensions), ... Besides there are plenty of OSes written in type safe system languages to learn from, including surviving mainframe OSes.
- pjmlp 8y ago
  On Windows we just use COM/UWP or .NET libraries most of the time, no need to be stuck with C ABI. Same applies on Android, where using a Java based library, even if stuck on their Java 6 - 8 world is much more desireable than having to deal with NDK and JNI boilerplate. Likewise IBM and Unisys mainframes make use of their language environments instead of C based ABIs.
  - Crinus 8y ago
    > COM/UWP Assuming with COM/UWP you mean "UWP's flavor of COM" instead of "COM and/or UWP", is anyone actually using that outside of mobile trash and game engine backends for XB1? All the Windows software i use and see people make are either Win32 or (much more often) built on top of Win32 (well, UWP is technically also built on top of Win32, but you are supposed to ignore that and act as if it isn't the case).
    - pjmlp 8y ago
      Yes they are, UWP is the future of Windows APIs since Windows 8, like it or not. Win32 is slowly being migrated into sandbox model with each Windows 10 release and hasn't seen any big update since Vista. All major APIs introduced since then are based on COM.
      - flohofwoe 8y ago
        I believe Windows will sooner become completely irrelevant than UWP becoming the dominant API to write Windows applications. Also seeing how MS is switching the system browser to Chromium, and kills the UWP version of MS Office, it looks like most people in Microsoft have lost faith in UWP too.
        pjmlp 8y ago
        What?!? Office was the team driving the new UWP Fluent components and happy early adopters of the new C++/WinRT framework and XAML Islands on Win32. The year of desktop Linux is just around the corner. /s
bacon_waffle 8y ago
I feel like C hasn't been a "language-that-you-use-for-everything" for some time, so it's more about replacing C in the situations where C is currently a reasonable choice for new development.
- earenndil 8y ago
  C has been and continues to be a general-purpose language people use to write all kinds of things; just, fewer things are being written in it.
rat87 8y ago
Maybe I'm a bit of a rust fanboy and a bit of a skeptic but Zig and Jai aren't going anywhere. Zig appears to be a largely single contibutor (https://github.com/ziglang/zig/graphs/contributors https://github.com/ziglang/zig/graphs/contributors the creator has < 2/3 of commits). Jai does not have a public compiler and is not likely to get a public release anytime soon. As for rust we don't know yet how big of a chunk of marketshare it will take from new c and c++ code. Not many people still use c code for "everything", most have already switched.
- StreamBright 8y ago
  What is the actual argument that you support with pointing out that Zig is "largely single contributor"? Linux was largely a single contributor up to a point.
  - ModernMech 8y ago
    There is nothing wrong with single contributor languages. But for every C there are thousands of flatlined github repositories of single contributor languages. Building a language is a marathon, not a sprint. It takes years and years to grow something worthwhile, and this requires a lot of persistence. In the meantime, technical challenges, finances, family, and even busses get in the way of languages being fully realized. Having a team rather than a BDFL increase the chances of a language flourishing and persisting.
    - AndyKelley 8y ago
      Fun fact, I'm also training for a marathon! https://twitter.com/andy_kelley/status/1109906861241847816 https://twitter.com/andy_kelley/status/1109906861241847816 There are 8 people on the Zig team, all with significant contributions and deep understanding of the project. https://github.com/orgs/ziglang/people https://github.com/orgs/ziglang/people
- rurban 8y ago
  > Zig appears to be a largely single contributor That's a good thing. The less contributors, the better the project usually.
pjmlp 8y ago
Just like when it was born, for C to die, UNIX has to die, that's the only reason it will be an herculean task to ever replace it.
mysterydip 8y ago
Naïve thought of the day: What if instead of replacing c with another c-like language, there was a c library that you included in your code that overloaded operators and functions into safer ones? You would gain some of the benefits and retain the ubiquity.

strmpnk 8y ago

I don't see any single thing replacing C (or C++) but what's interesting here is many of these languages work very well with the C ABI, not just as an FFI concept but with notions of memory and data layout. The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions). This lowers the barrier significantly. The hard part is build tool compatibility but I think there are a lot of good ideas being worked on actively, Zig and Rust being two examples of advanced programatic control over the build process. With a reasonable linker, it should be possible to combine these and more languages today. An interesting counter example to the binary interface compatibility story has been Go, which seems to let cgo become less and less functional in each release. The pressure to keep everything in Go is an interesting trade-off. I wonder if certain kinds of systems will be paying for this lock-in later down the line while other languages give much easier ways to gradually evolve and reuse code or adopt libraries from multiple communities removing the need to do yet-another-rewrite in language X kinds of projects. Or perhaps this kind of interoperation is overrated? Time will tell.

timClicks 8y ago
On build processes, it's surprising to me that the Rust community hasn't developed its own linker. I suppose LD works fine.
earenndil 8y ago
> The interesting side effect might be that we'll see Zig not just work with C code but Zig work with Jai with D with Rust. All of that code can still interface with C or C++ code (in both directions) That already works, not a hypothetical. I can write, right now, a zig function, call it from rust, slap the whole thing into a library and wrap it with d. It hasn't taken the world by storm because these languages provide support the system c abi and calling convention, but do not embrace it. If I write a fancy templated function in zig, d, or rust, the name mangling, type-information, templating, maybe even call conventions -- are all different. This is why I have been and continue to be disappointed that things like COM or the jvm or cli aren't more popular, because they actually work that way. I can write, right now a clojure function, call it from java and then pass it into kotlin. Effortlessly, it's just an import away. Sure there are, for example, stdlib conflicts in scala but overall it's a much more frictionless experience. The problem? COM is windows-specific, jvm and cli are managed runtimes and people don't like managed runtimes. Another place I look for a solution is racket, but again it wants to manage too much of the runtime to be practical. What zig is doing with the build system is great, the fact that the build script is actually a fully customizable script means it has a much better chance of taking off, but until I can import a jai module from d and call it in zig, we're gonna have problems. EDIT: something which possibly almost could have had a good chance of pulling this off is llvm. Except that llvm comes too late in the compilation process to be used to resolve imports and symbols. Something like libclang, maybe, except not specific to c and c++.
- jplayer01 8y ago
  Wouldn't a managed runtime mean it isn't suited for systems programming? The benefit of something like Rust is it provides a lot of the benefits of a managed language while producing native code and "zero-cost abstractions". A runtime adds a lot of overhead etc.
  - pjmlp 8y ago
    C also has a runtime, that is what takes care of calling main(), handling VLAs, floating point emulation, constructor/destructors (GCC C extensions), ... Besides there are plenty of OSes written in type safe system languages to learn from, including surviving mainframe OSes.
pjmlp 8y ago
On Windows we just use COM/UWP or .NET libraries most of the time, no need to be stuck with C ABI. Same applies on Android, where using a Java based library, even if stuck on their Java 6 - 8 world is much more desireable than having to deal with NDK and JNI boilerplate. Likewise IBM and Unisys mainframes make use of their language environments instead of C based ABIs.
- Crinus 8y ago
  > COM/UWP Assuming with COM/UWP you mean "UWP's flavor of COM" instead of "COM and/or UWP", is anyone actually using that outside of mobile trash and game engine backends for XB1? All the Windows software i use and see people make are either Win32 or (much more often) built on top of Win32 (well, UWP is technically also built on top of Win32, but you are supposed to ignore that and act as if it isn't the case).
  - pjmlp 8y ago
    Yes they are, UWP is the future of Windows APIs since Windows 8, like it or not. Win32 is slowly being migrated into sandbox model with each Windows 10 release and hasn't seen any big update since Vista. All major APIs introduced since then are based on COM.
    - flohofwoe 8y ago
      I believe Windows will sooner become completely irrelevant than UWP becoming the dominant API to write Windows applications. Also seeing how MS is switching the system browser to Chromium, and kills the UWP version of MS Office, it looks like most people in Microsoft have lost faith in UWP too.
      - pjmlp 8y ago
        What?!? Office was the team driving the new UWP Fluent components and happy early adopters of the new C++/WinRT framework and XAML Islands on Win32. The year of desktop Linux is just around the corner. /s

bacon_waffle 8y ago

I feel like C hasn't been a "language-that-you-use-for-everything" for some time, so it's more about replacing C in the situations where C is currently a reasonable choice for new development.

earenndil 8y ago
C has been and continues to be a general-purpose language people use to write all kinds of things; just, fewer things are being written in it.

rat87 8y ago

Maybe I'm a bit of a rust fanboy and a bit of a skeptic but Zig and Jai aren't going anywhere. Zig appears to be a largely single contibutor (https://github.com/ziglang/zig/graphs/contributors https://github.com/ziglang/zig/graphs/contributors the creator has < 2/3 of commits). Jai does not have a public compiler and is not likely to get a public release anytime soon. As for rust we don't know yet how big of a chunk of marketshare it will take from new c and c++ code. Not many people still use c code for "everything", most have already switched.

StreamBright 8y ago
What is the actual argument that you support with pointing out that Zig is "largely single contributor"? Linux was largely a single contributor up to a point.
- ModernMech 8y ago
  There is nothing wrong with single contributor languages. But for every C there are thousands of flatlined github repositories of single contributor languages. Building a language is a marathon, not a sprint. It takes years and years to grow something worthwhile, and this requires a lot of persistence. In the meantime, technical challenges, finances, family, and even busses get in the way of languages being fully realized. Having a team rather than a BDFL increase the chances of a language flourishing and persisting.
  - AndyKelley 8y ago
    Fun fact, I'm also training for a marathon! https://twitter.com/andy_kelley/status/1109906861241847816 https://twitter.com/andy_kelley/status/1109906861241847816 There are 8 people on the Zig team, all with significant contributions and deep understanding of the project. https://github.com/orgs/ziglang/people https://github.com/orgs/ziglang/people
rurban 8y ago
> Zig appears to be a largely single contributor That's a good thing. The less contributors, the better the project usually.

pjmlp 8y ago

Just like when it was born, for C to die, UNIX has to die, that's the only reason it will be an herculean task to ever replace it.

mysterydip 8y ago

Naïve thought of the day: What if instead of replacing c with another c-like language, there was a c library that you included in your code that overloaded operators and functions into safer ones? You would gain some of the benefits and retain the ubiquity.