6 ms·
D tried, but somehow failed.
by andi999 5y ago
D tried, but somehow failed.
- zarzavat 5y agoD suffered from too many options, multiple standard libraries and indecision between GC and manual memory management.
- generichuman 5y ago> 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 agoExciting. The tutorial says download the compiler, somehow cannot find it, do you have a link?
- generichuman 5y agoJai 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 agoJai 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.
- p0nce 5y agoI much more happy using D that I have ever been using C++. It is a perfect replacement, with none of the issues mentionned in GP comment.