6 ms·

> D suffered from [...] indecision between GC and manual memory management. It is still suffering from that. If you want to manage memory yourself you can't us

> D suffered from [...] indecision between GC and manual memory management. It is still suffering from that. If you want to manage memory yourself you can't use some parts of the standard library + you can't use a lot of the community packages since they assume there is a GC present. So far it looks like the best alternative is Zig, but sadly it doesn't have some of the higher-level language features such as function overloading, compile-time interfaces (Rust traits) or macros. Jai seems to have most D features and more without the GC [0] but Zig is more likely win popular mindshare since it already is in the open + comes with a C/C++ compiler which is pretty cool. [0] https://github.com/Jai-Community/Jai-Community-Library/wiki https://github.com/Jai-Community/Jai-Community-Library/wiki

andi999 5y ago
Exciting. The tutorial says download the compiler, somehow cannot find it, do you have a link?
- generichuman 5y ago
  Jai isn't available to public, sadly. That's why I said Zig is "already in the open". Jai has been in private beta since early 2020 and there are about 150 people that have access to the compiler beta AFAIK. The reason for the language not being available is that the designer (Jonathan Blow) doesn't want to release something half-baked to the world (because "there is already so much garbage software out in the world", or some line of reasoning similar to that). I don't agree with his reasoning, but I understand it TBH. He also has the reputation of taking too long to develop his games, but when they're finally released they're pretty good. Anyway, it doesn't look like it'll be released to the public soon so like I said, Zig is the best alternative right now -- and it's gaining more and more users, so when Jai finally gets released, Zig might have already won.
  - cyber_kinetist 5y ago
    Jai and Zig are my next two bets (after exploring some Nim and concluding that it needs more time to develop), but Jai has made design decisions that are much more appealing to gamedev, and Zig seems less pragmatic in this regard. Both seem to be promising languages in general, I'm only comparing them from a perspective of a specific domain of programming. - Zig doesn't have operator overloading while Jai does. Maybe a minor nitpick compared to the other ones, but this is a must-have for any math-heavy code, even crufty Orthodox C++ practicioners seem to use it. - Jai's dev team is also developing a compiler backend that is much faster than LLVM - it's only for debug builds, but that compile speed is very important for any iteration-based workflow. - Jai's compile time evaluation is far more powerful - it can access the disk/internet and call any libraries. This is probably a horror show for any webdevs who like to do "npm install" without any thought, but in the case of gamedev where you have precise control over your dependencies this gives a much more higher degree of freedom. (For example, with this I imagine not only Jai code replacing all your build system scripts, but also asset management, packaging, localization, and publishing as well.) Jai's compile time evaluation also runs in a custom made bytecode-interpreter, which is probably going to be way faster than interpreting raw LLVM IR (which is what I think Zig's implementation is doing) - Jai's support for switching allocators on the fly seems a bit less elegant than Zig's approach, but for actual usage I imagine it will be a lot ergonomic to use. As you have said, you can't dismiss the community traction of Zig. But for me the most important thing will be: which language will actually ship a (reasonably sized) commercial game first. In that regard, as Jai's release will coincide with the Sokoban game that Blow's making it with, I think Jai will be the next language I try after C++ (well, if it releases though...)
    - UncleOxidant 5y ago
      > Jai's dev team is also developing a compiler backend that is much faster than LLVM I suppose you mean compile time when you say "faster". But LLVM also gives you many backend CPU (and even GPU) targets out of the box. Rolling your own backend probably means x86 and maybe ARM. Lots of work targeting new architectures that is saved by going with LLVM.
      - cyber_kinetist 5y ago
        The custom compiler backend is only intended to use for development, so limiting it to x86 makes sense (well, unless you are planning to develop with one of the new M1 Macs…) For actual deployment (release builds for various architectures), the LLVM compiler can be used for Jai.
    - pron 5y ago
      > Zig doesn't have operator overloading Zig, by design, doesn't have overloading of any name, period (which also includes operators).
      - dnautics 5y ago
        Sure, but I also proposed an equivalent way to get "custom operators without overloading" (lexical scope-namespacing in @ functions with a special parser rule for certain infix binary forms that do not conflict with builtin operators) and this, too, was rejected.
    - dralley 5y ago
      > - Jai's dev team is also developing a compiler backend that is much faster than LLVM - it's only for debug builds, but that compile speed is very important for any iteration-based workflow. So is Zig. In fact Zig might be even more aggressive about this - they chose to aim for an in-place binary patching approach explicitly for the purpose of fast rebuilds and simplifying live-reloading.
      - cyber_kinetist 5y ago

andi999 5y ago

Exciting. The tutorial says download the compiler, somehow cannot find it, do you have a link?

generichuman 5y ago
Jai isn't available to public, sadly. That's why I said Zig is "already in the open". Jai has been in private beta since early 2020 and there are about 150 people that have access to the compiler beta AFAIK. The reason for the language not being available is that the designer (Jonathan Blow) doesn't want to release something half-baked to the world (because "there is already so much garbage software out in the world", or some line of reasoning similar to that). I don't agree with his reasoning, but I understand it TBH. He also has the reputation of taking too long to develop his games, but when they're finally released they're pretty good. Anyway, it doesn't look like it'll be released to the public soon so like I said, Zig is the best alternative right now -- and it's gaining more and more users, so when Jai finally gets released, Zig might have already won.
- cyber_kinetist 5y ago
  Jai and Zig are my next two bets (after exploring some Nim and concluding that it needs more time to develop), but Jai has made design decisions that are much more appealing to gamedev, and Zig seems less pragmatic in this regard. Both seem to be promising languages in general, I'm only comparing them from a perspective of a specific domain of programming. - Zig doesn't have operator overloading while Jai does. Maybe a minor nitpick compared to the other ones, but this is a must-have for any math-heavy code, even crufty Orthodox C++ practicioners seem to use it. - Jai's dev team is also developing a compiler backend that is much faster than LLVM - it's only for debug builds, but that compile speed is very important for any iteration-based workflow. - Jai's compile time evaluation is far more powerful - it can access the disk/internet and call any libraries. This is probably a horror show for any webdevs who like to do "npm install" without any thought, but in the case of gamedev where you have precise control over your dependencies this gives a much more higher degree of freedom. (For example, with this I imagine not only Jai code replacing all your build system scripts, but also asset management, packaging, localization, and publishing as well.) Jai's compile time evaluation also runs in a custom made bytecode-interpreter, which is probably going to be way faster than interpreting raw LLVM IR (which is what I think Zig's implementation is doing) - Jai's support for switching allocators on the fly seems a bit less elegant than Zig's approach, but for actual usage I imagine it will be a lot ergonomic to use. As you have said, you can't dismiss the community traction of Zig. But for me the most important thing will be: which language will actually ship a (reasonably sized) commercial game first. In that regard, as Jai's release will coincide with the Sokoban game that Blow's making it with, I think Jai will be the next language I try after C++ (well, if it releases though...)
  - UncleOxidant 5y ago
    > Jai's dev team is also developing a compiler backend that is much faster than LLVM I suppose you mean compile time when you say "faster". But LLVM also gives you many backend CPU (and even GPU) targets out of the box. Rolling your own backend probably means x86 and maybe ARM. Lots of work targeting new architectures that is saved by going with LLVM.
    - cyber_kinetist 5y ago
      The custom compiler backend is only intended to use for development, so limiting it to x86 makes sense (well, unless you are planning to develop with one of the new M1 Macs…) For actual deployment (release builds for various architectures), the LLVM compiler can be used for Jai.
  - pron 5y ago
    > Zig doesn't have operator overloading Zig, by design, doesn't have overloading of any name, period (which also includes operators).
    - dnautics 5y ago
      Sure, but I also proposed an equivalent way to get "custom operators without overloading" (lexical scope-namespacing in @ functions with a special parser rule for certain infix binary forms that do not conflict with builtin operators) and this, too, was rejected.
  - dralley 5y ago
    > - Jai's dev team is also developing a compiler backend that is much faster than LLVM - it's only for debug builds, but that compile speed is very important for any iteration-based workflow. So is Zig. In fact Zig might be even more aggressive about this - they chose to aim for an in-place binary patching approach explicitly for the purpose of fast rebuilds and simplifying live-reloading.
    - cyber_kinetist 5y ago