4 ms·

I'm watching Zig and Jai closely. We need a better C and C++ isn't it. Good luck!

electrograv 8y ago
I honestly think Zig has the potential to be the C/C++ replacement. I haven’t checked out Jai yet but will now that you mention, thanks! This is somewhat subjective of course, but from what I’ve seen, Zig has just the right set of features to modernize systems programming, without making the language too complex or difficult to write (which arguably Rust’s “borrow checker” system does), and (like Rust) gets rid of some huge legacy language design mistakes most people agree on today (e.g. nullable-by-default pointer types, or no way to know at compile time or at a glance what range of exceptions a function may throw). And of course, the “automatic” interoperability with C is an essential part of any C/C++ replacement contender.
- Jach 8y ago
  There are a lot of contenders. My own unsorted list is Nim, Rust, C++20xx, D, Objective C, Pony, Zig, Crystal, Red, and maybe a form of Lisp (why not Common Lisp). Even more unlikely a maybe and only for the C/C++ trenches of embedded systems, some form of Forth. If Jai ever ships I might consider adding it (at least as a contender to the C/C++ trenches of games and game engines), but it's absurd to think it will have any impact when it can't even be used by anyone other than jblow yet. Even if it ships, I would bet its highest anywhere-realistic impact (which is still damn high) would be to become the PHP of game programming. The mythical C/C++ replacement that everyone will choose when they previously would have chosen C or C++, causing C/C++ to die like COBOL? Much less likely.
  - electrograv 8y ago
    Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references. Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility of null dereference exceptions, without negatively impacting performance or code style! But it goes beyond just static checking. It makes coding easier, too: You will never have to wonder whether a function returning a reference might return null on a common failure, vs throw an exception. You’ll never have to wonder if an object reference parameter is optional or not, because this will be explicit in the data type accepter/returned. You’ll never have to wonder if this variable of type T in fact contains a valid T value, or actually is just “null”, because the possible range of values will be encoded in the type system: If it could be null, you’ll know it and so will the compiler. Not only is this better for safety (the compiler won’t let you do the wrong thing), it’s self-documenting. It blows my mind that any modern language design would willingly think nullable object references is still a good idea (or perhaps its out of ignorance), when there are truly zero-cost solutions to this — in both runtime performance and ease of writing code, as you can see for example from Zig or Kotlin. [1] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare https://www.infoq.com/presentations/Null-References-The-Bill...
    - Jach 8y ago
      Null isn't that bad -- or rather, the concept of a missing value. Certain languages handle null better than others, but even then, it seems like the more costly mistake has been the accumulation of made-up data to satisfy non-null requirements.[0] More costly for non-programmers who have to deal with the programmers' lazy insistence that not knowing a value for some data in their system is forbidden, anyway. In any case I think the modern fashion of trying to eliminate null from PLs won't matter much in the effort to replace C, whereas something like a mandatory GC is an instant no-go (though Java at least was very successful at sparing the world a lot of C++). OTOH a language that makes more kinds of formal verification possible (beyond just type theory proofs) might one day replace C and have null-analysis as a subfeature too. [0] http://john.freml.in/billion-dollar-mistake http://john.freml.in/billion-dollar-mistake
      - electrograv 8y ago
        I think the author of that blog post fundamentally misunderstands the point: The damage of nullable pointers is not that they are nullable, but that compilers allow you to write code everywhere that assumes they’re not null (in fact, this is the only possible way to code, when the language cannot express the notion of a non-nullable reference!) For example, most older languages with “the billion dollar mistake” have no complaint whatsoever when your write “object.method();” where it’s unknown at this scope whether “object” is null or not. The fact that such code compiles is the billion dollar mistake; not the fact that the pointer is nullable. I don’t care if you want to write nullable references everywhere, or whatever else you prefer or your application demands. That’s fine, so long as: 1. Non-nullable reference types must exist. 2. Nullable references types must exist as statically distinct from #1. 3. The compiler must not let you write code that assumes a nullable reference is not null, unless you check via a control flow statement first. Now to take a step back, the principle behind this certainly applies beyond just nullability (if that was the point you were trying to make): Generally, dynamic, untyped invalidation states are dangerous/bad, while statically typed invalidation states are ideal. And yes, this does include bad states internal to a non-null reference, just as much as to a null reference. Sum types are the key to being able to statically declare what range of values a function may return (or accept), and ensure at compile time that these different cases are all accounted for. If you aren’t aware of how elegantly sum types solve this, you should look into it — and I suspect it will be quickly clear why nullable references are useless, outdated, and harmful. But at the very least, we’ve solved the pain of null dereference — and virtually without compromise. So, it’s irresponsible or ignorant IMO to create a new language that doesn’t include this solution in its core.
  - nickpsecurity 8y ago
    "maybe a form of Lisp (why not Common Lisp)." Yes, a Lisp-like language could do it. Why not Common Lisp? Because PreScheme and ZL were both better if we're aiming at C's niche: https://en.wikipedia.org/wiki/Scheme_48 https://en.wikipedia.org/wiki/Scheme_48 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4031 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.40... http://www.schemeworkshop.org/2011/papers/Atkinson2011.pdf http://www.schemeworkshop.org/2011/papers/Atkinson2011.pdf http://zl-lang.org/ http://zl-lang.org/ I was looking for a way to do metaprogramming, verified programming, LISP-like programming, and low-level programming. Past few years of searching led me to a lot of verification stuff obviously, PreScheme for low-level Lisp, ZL for Scheme/C, and Red/System for a REBOL-like answer. I was eyeballing Nim, too, since the masses usually hate LISP's syntax. Then, I thought a front-end that let one go with various syntax's, esp inspired by famous languages, with the same underlying semantics or just easy integration. On a practical note, I noticed that strong integration with the dominant language with little to no performance hit is extremely important. Clojure building on Java in enterprise space is an example. It reuses it's ecosystem. For system space, I started recommending using C's data types and calling conventions where possible in new language so calling it would cost nothing. Then, maybe an option to extract to C for its compilers. So, whatever above languages are created need to integrate with C really well.
muthdra 8y ago
I'm betting on Jai.
- kungtotte 8y ago
  Really? You're betting on the one language out of all the one's mentioned that you can't actually use yet?
  - coldtea 8y ago
    Never underestimate the power of hype and marketing over rational assessment.
    - kungtotte 8y ago
      Yeah I guess. The only charitable thing I can think to say is that maybe they've tried all the others and found them lacking somehow (what language is perfect, after all?) and so they put their hopes to the one as yet untested. It could, theoretically, be perfect. Since it's all theoretical at this point I mean.
    - muthdra 8y ago
      There's no marketing. There's only Jonathan Blow.
- skrebbel 8y ago
  I hadn't heard of Jai yet, but wow! That's a lot of hype (and even tool support) for something that doesn't work yet. At first glance, Zig vs Jai reminds me a lot of the Linux vs GNU Hurd thing (or a lot of other "worse is better" examples). A couple of geniuses locking themselves up telling the world "Just wait! It'll be awesome!" seldomly produces something that lasts.
  - gameswithgo 8y ago
    >seldomly produces something that lasts. of course, but sometimes it does.

I honestly think Zig has the potential to be the C/C++ replacement. I haven’t checked out Jai yet but will now that you mention, thanks! This is somewhat subjective of course, but from what I’ve seen, Zig has just the right set of features to modernize systems programming, without making the language too complex or difficult to write (which arguably Rust’s “borrow checker” system does), and (like Rust) gets rid of some huge legacy language design mistakes most people agree on today (e.g. nullable-by-default pointer types, or no way to know at compile time or at a glance what range of exceptions a function may throw). And of course, the “automatic” interoperability with C is an essential part of any C/C++ replacement contender.

Jach 8y ago
There are a lot of contenders. My own unsorted list is Nim, Rust, C++20xx, D, Objective C, Pony, Zig, Crystal, Red, and maybe a form of Lisp (why not Common Lisp). Even more unlikely a maybe and only for the C/C++ trenches of embedded systems, some form of Forth. If Jai ever ships I might consider adding it (at least as a contender to the C/C++ trenches of games and game engines), but it's absurd to think it will have any impact when it can't even be used by anyone other than jblow yet. Even if it ships, I would bet its highest anywhere-realistic impact (which is still damn high) would be to become the PHP of game programming. The mythical C/C++ replacement that everyone will choose when they previously would have chosen C or C++, causing C/C++ to die like COBOL? Much less likely.
- electrograv 8y ago
  Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references. Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility of null dereference exceptions, without negatively impacting performance or code style! But it goes beyond just static checking. It makes coding easier, too: You will never have to wonder whether a function returning a reference might return null on a common failure, vs throw an exception. You’ll never have to wonder if an object reference parameter is optional or not, because this will be explicit in the data type accepter/returned. You’ll never have to wonder if this variable of type T in fact contains a valid T value, or actually is just “null”, because the possible range of values will be encoded in the type system: If it could be null, you’ll know it and so will the compiler. Not only is this better for safety (the compiler won’t let you do the wrong thing), it’s self-documenting. It blows my mind that any modern language design would willingly think nullable object references is still a good idea (or perhaps its out of ignorance), when there are truly zero-cost solutions to this — in both runtime performance and ease of writing code, as you can see for example from Zig or Kotlin. [1] https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare https://www.infoq.com/presentations/Null-References-The-Bill...
  - Jach 8y ago
    Null isn't that bad -- or rather, the concept of a missing value. Certain languages handle null better than others, but even then, it seems like the more costly mistake has been the accumulation of made-up data to satisfy non-null requirements.[0] More costly for non-programmers who have to deal with the programmers' lazy insistence that not knowing a value for some data in their system is forbidden, anyway. In any case I think the modern fashion of trying to eliminate null from PLs won't matter much in the effort to replace C, whereas something like a mandatory GC is an instant no-go (though Java at least was very successful at sparing the world a lot of C++). OTOH a language that makes more kinds of formal verification possible (beyond just type theory proofs) might one day replace C and have null-analysis as a subfeature too. [0] http://john.freml.in/billion-dollar-mistake http://john.freml.in/billion-dollar-mistake
    - electrograv 8y ago
      I think the author of that blog post fundamentally misunderstands the point: The damage of nullable pointers is not that they are nullable, but that compilers allow you to write code everywhere that assumes they’re not null (in fact, this is the only possible way to code, when the language cannot express the notion of a non-nullable reference!) For example, most older languages with “the billion dollar mistake” have no complaint whatsoever when your write “object.method();” where it’s unknown at this scope whether “object” is null or not. The fact that such code compiles is the billion dollar mistake; not the fact that the pointer is nullable. I don’t care if you want to write nullable references everywhere, or whatever else you prefer or your application demands. That’s fine, so long as: 1. Non-nullable reference types must exist. 2. Nullable references types must exist as statically distinct from #1. 3. The compiler must not let you write code that assumes a nullable reference is not null, unless you check via a control flow statement first. Now to take a step back, the principle behind this certainly applies beyond just nullability (if that was the point you were trying to make): Generally, dynamic, untyped invalidation states are dangerous/bad, while statically typed invalidation states are ideal. And yes, this does include bad states internal to a non-null reference, just as much as to a null reference. Sum types are the key to being able to statically declare what range of values a function may return (or accept), and ensure at compile time that these different cases are all accounted for. If you aren’t aware of how elegantly sum types solve this, you should look into it — and I suspect it will be quickly clear why nullable references are useless, outdated, and harmful. But at the very least, we’ve solved the pain of null dereference — and virtually without compromise. So, it’s irresponsible or ignorant IMO to create a new language that doesn’t include this solution in its core.
- nickpsecurity 8y ago
  "maybe a form of Lisp (why not Common Lisp)." Yes, a Lisp-like language could do it. Why not Common Lisp? Because PreScheme and ZL were both better if we're aiming at C's niche: https://en.wikipedia.org/wiki/Scheme_48 https://en.wikipedia.org/wiki/Scheme_48 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4031 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.40... http://www.schemeworkshop.org/2011/papers/Atkinson2011.pdf http://www.schemeworkshop.org/2011/papers/Atkinson2011.pdf http://zl-lang.org/ http://zl-lang.org/ I was looking for a way to do metaprogramming, verified programming, LISP-like programming, and low-level programming. Past few years of searching led me to a lot of verification stuff obviously, PreScheme for low-level Lisp, ZL for Scheme/C, and Red/System for a REBOL-like answer. I was eyeballing Nim, too, since the masses usually hate LISP's syntax. Then, I thought a front-end that let one go with various syntax's, esp inspired by famous languages, with the same underlying semantics or just easy integration. On a practical note, I noticed that strong integration with the dominant language with little to no performance hit is extremely important. Clojure building on Java in enterprise space is an example. It reuses it's ecosystem. For system space, I started recommending using C's data types and calling conventions where possible in new language so calling it would cost nothing. Then, maybe an option to extract to C for its compilers. So, whatever above languages are created need to integrate with C really well.

muthdra 8y ago

I'm betting on Jai.

kungtotte 8y ago
Really? You're betting on the one language out of all the one's mentioned that you can't actually use yet?
- coldtea 8y ago
  Never underestimate the power of hype and marketing over rational assessment.
  - kungtotte 8y ago
    Yeah I guess. The only charitable thing I can think to say is that maybe they've tried all the others and found them lacking somehow (what language is perfect, after all?) and so they put their hopes to the one as yet untested. It could, theoretically, be perfect. Since it's all theoretical at this point I mean.
  - muthdra 8y ago
    There's no marketing. There's only Jonathan Blow.
skrebbel 8y ago
I hadn't heard of Jai yet, but wow! That's a lot of hype (and even tool support) for something that doesn't work yet. At first glance, Zig vs Jai reminds me a lot of the Linux vs GNU Hurd thing (or a lot of other "worse is better" examples). A couple of geniuses locking themselves up telling the world "Just wait! It'll be awesome!" seldomly produces something that lasts.
- gameswithgo 8y ago
  >seldomly produces something that lasts. of course, but sometimes it does.