6 ms·

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 conce

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.
    - jstimpfle 8y ago
      I feel much of the negativity that you like to express towards C is unwarranted. Fact is, it's both very easy and efficient to interface with "C" or more specifically, platforms' standard ABIs.
      - pjmlp 8y ago
        On platforms written in C. As for the negativity, Morris worm is now 30 years old and the CVE database gets C derived exploits every month.
        jstimpfle 8y ago
        You can interface with Object Pascal (which you frequently advertise) just fine. (That doesn't make Object Pascal a practical language, though). https://www.quora.com/Why-is-the-JVM-so-riddled-with-security-bugs https://www.quora.com/Why-is-the-JVM-so-riddled-with-securit... Another fact is, startup times alone make JVM impractical for many endeavours. For each task an appropriate tool I'll say.
        pjmlp 8y ago
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

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.
  - jstimpfle 8y ago
    I feel much of the negativity that you like to express towards C is unwarranted. Fact is, it's both very easy and efficient to interface with "C" or more specifically, platforms' standard ABIs.
    - pjmlp 8y ago
      On platforms written in C. As for the negativity, Morris worm is now 30 years old and the CVE database gets C derived exploits every month.
      - jstimpfle 8y ago
        You can interface with Object Pascal (which you frequently advertise) just fine. (That doesn't make Object Pascal a practical language, though). https://www.quora.com/Why-is-the-JVM-so-riddled-with-security-bugs https://www.quora.com/Why-is-the-JVM-so-riddled-with-securit... Another fact is, startup times alone make JVM impractical for many endeavours. For each task an appropriate tool I'll say.
        pjmlp 8y ago

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