5 ms·

> 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

> 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
        JVM startup times are only an issue for those that don't want to buy a commercial JDK with AOT compiler support. Good news, now OpenJDK and GraalVM offer it for free, gratis. Object Pascal/Delphi is quite pratical on Windows.
        jstimpfle 8y ago
        > Object Pascal/Delphi It has a sane subset which is basically C with a slightly saner syntax than C (the begin...end and lacking data initialization syntax are terrible though!), and with a proper module system and much better compile times. On the other hand, it was crippled by missing a usable preprocessor and an ecosystem that has bought into each hype since the 90's, resulting in 23 incompatible kinds of strings, 101 different dynamic arrays, and about 5 (really) incompatible object models with different kinds of memory management. Programmers with many years in the language don't really understand all the ways memory is managed in this language. Now try writing something on top of the broken RTTI for that. Even official guides basically concede the fact by writing quirky code that easily breaks. Also you have to declare typealiases for every little thing like pointer-to-types, before you can use that type in a function signature. This alone renders it almost completely unusable for my purposes. It has a culture of goto-considered-harmful where people like to indent 13 times instead of using return/continue/break, which would yield readable control flow. If you want to return something, you need to write two lines - assigning to the result and calling exit(). You can't call exit() though when the current class has a method called exit(), since that method is closer in scope (REALLY REALLY WEIRD). I know what I'm talking about. I've been paid to work in it, and refactored a subsystem written in idiomatic Delphi to be halfway maintainable, achieving real speedups of 100-1000x by following a straightforward "data-oriented" approach, just like I would write it in C, writing complicated code only where the straightforward approach was not feasible in the language. Despite completing the project successfully (there hasn't been a single problem since the rewrite), in the end I was burnt out due to having to work with the original code. Didn't work for 5 months afterwards.
stevek 8y ago
COM is not windows specific any more! Or rather there is a portable COM-like thing which looks like a good fit for cross language development https://github.com/Microsoft/xlang https://github.com/Microsoft/xlang It's from the team who delivered cppwinrt (aka moderncpp). So the C++ projection doesn't have all the nasty baggage one usually associates with COM. https://msdn.microsoft.com/en-us/magazine/mt745094.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-us/magazine/mt745094.aspx?f=25...

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
        JVM startup times are only an issue for those that don't want to buy a commercial JDK with AOT compiler support. Good news, now OpenJDK and GraalVM offer it for free, gratis. Object Pascal/Delphi is quite pratical on Windows.
        jstimpfle 8y ago
        > Object Pascal/Delphi It has a sane subset which is basically C with a slightly saner syntax than C (the begin...end and lacking data initialization syntax are terrible though!), and with a proper module system and much better compile times. On the other hand, it was crippled by missing a usable preprocessor and an ecosystem that has bought into each hype since the 90's, resulting in 23 incompatible kinds of strings, 101 different dynamic arrays, and about 5 (really) incompatible object models with different kinds of memory management. Programmers with many years in the language don't really understand all the ways memory is managed in this language. Now try writing something on top of the broken RTTI for that. Even official guides basically concede the fact by writing quirky code that easily breaks. Also you have to declare typealiases for every little thing like pointer-to-types, before you can use that type in a function signature. This alone renders it almost completely unusable for my purposes. It has a culture of goto-considered-harmful where people like to indent 13 times instead of using return/continue/break, which would yield readable control flow. If you want to return something, you need to write two lines - assigning to the result and calling exit(). You can't call exit() though when the current class has a method called exit(), since that method is closer in scope (REALLY REALLY WEIRD). I know what I'm talking about. I've been paid to work in it, and refactored a subsystem written in idiomatic Delphi to be halfway maintainable, achieving real speedups of 100-1000x by following a straightforward "data-oriented" approach, just like I would write it in C, writing complicated code only where the straightforward approach was not feasible in the language. Despite completing the project successfully (there hasn't been a single problem since the rewrite), in the end I was burnt out due to having to work with the original code. Didn't work for 5 months afterwards.

stevek 8y ago

COM is not windows specific any more! Or rather there is a portable COM-like thing which looks like a good fit for cross language development https://github.com/Microsoft/xlang https://github.com/Microsoft/xlang It's from the team who delivered cppwinrt (aka moderncpp). So the C++ projection doesn't have all the nasty baggage one usually associates with COM. https://msdn.microsoft.com/en-us/magazine/mt745094.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-us/magazine/mt745094.aspx?f=25...