I’m in the private beta and things are changing constantly. I’m not sure why anyone would pick a language that won’t ever have a real ecosystem of libraries. Coming from C++ and need to remain low-level? Pick Rust, done.
[deleted]
Porting 58k lines of D and C++ to Jai
191–200 of 264 posts
Re: Porting 58k lines of D and C++ to Jai
#192Earlier quoted context omitted.
With the almost total incompatibility in mindset and preferences between Jai and Rust, I’m not sure if this is actually practical ‘advice’. I can’t help but think most devs that want to use Jai are avoiding Rust purposefully so advising them to skip Jai as a potential replacement for their low level development needs and use Rust is just not going to happen.
Who is avoiding Rust (an open source, publicly accessible, and relatively widespread language) for Jai (a closed vapourware language that is apparently not anywhere near release) for anything but toy projects?
I was not implying that people were specifically avoiding Rust in favor of Jai. My comment was more to the point that people who would be interested in Jai are most likely the same devs that are not interested in Rust.
The reasons devs give for avoiding Rust are mixed but tend to focus on the restrictiveness inherent in Rust’s chosen memory model or the appearance of continual expansion of the language and its complexity or a strong aversion to the manner of dealing with and heavy usage of third party dependency, along with some other topics (syntax, functional-adjacent styling, insistence on idiomatic code at any cost, etc).
While some or all of those reasons may be overblown, some devs just do not want Rust but are looking for an alternative to C or C++.
Re: Porting 58k lines of D and C++ to Jai
#193Earlier quoted context omitted.
I'm starting to actually believe that Rust will eat C's lunch for systems programming.
I think there is a space for other alternative low-level languages that aren't that strict about compile-time safety though (Zig, Jai, Odin), that Rust cannot capture. Many proclaim that compile-time safety using type theory is the only way to create reliable low-level software, but I think it can alternatively be done with good data structure design and various compiler tooling that instead catch these errors at run…
You can even get safety using logic without the compiler. I think resource cleanup responsibility tracking as a static analysis tool is likely to happen with some of these languages. I think zig is a good candidate, once they lock down the intermediate representation.
It's already the case that people are using "logic add-ons" for additional rust static analysis, so one wonders exactly why is it generally speaking that borrow checking itself must occur at the compilation step.
Trivially, one could create an annotation layer on top of zig or c that exactly replicates the rust syntax and performance borrow checking in the same way. It wouldn't be exactly the same because there isn't RAII but you can make correct inferences about what is happening in the body of the functions.
Re: Porting 58k lines of D and C++ to Jai
#194I'm really interested to see Jai in the wild, but I have to say I find the Jai v.s. Rust comparison here...unconvincing to say to least. It's particularly funny to be excited about "being able to do anything during compilation" using Jai and then complain to that the #1 problem in programming is "culturally tolerated and even encouraged complexity."
I'm also slightly puzzled at saying "compilation is too slow!" followed by "I want to do anything during compilation". I think these are somewhat opposed to each other. Obviously it's not the only reason for slowness (stuff like templates vs vtables for example are also a huge impact), but at some point I tried to do some more advanced comptime stuff in Zig (it's pretty long ago, around Zig 0.6 or 0.7), and it became…
It depends on how you implement compile time execution.
Creating a VM to run the code directly rather than reusing the compile+run cycle can speed things up. The VM executes slower but takes less time overall, especially with a complex language like Rust.
Re: Porting 58k lines of D and C++ to Jai
#195Earlier quoted context omitted.
> D is closer to C++ than C, in my opinion. In terms of what the language allows you to do, yes. However, if you're a C programmer, you can pretty much just keep writing the same code you've always written (minus the preprocessor, thankfully). You can even compile C code with the D compiler and call those functions from your D code without doing anything further. That's definitely not the case with C++.
Oh, come on now. I'm no C++ apologist, but you can do both of those things in C++ as well as in D.
I meant you can't do things like compile C++ code directly into your D project.
Re: Porting 58k lines of D and C++ to Jai
#196I'm really interested to see Jai in the wild, but I have to say I find the Jai v.s. Rust comparison here...unconvincing to say to least. It's particularly funny to be excited about "being able to do anything during compilation" using Jai and then complain to that the #1 problem in programming is "culturally tolerated and even encouraged complexity."
I'm also frustrated at a language in closed beta being perpetually compared to a language that is open source and in production. It's a complete apples to oranges comparison. By being in closed beta, there is no way of verifying anything said about Jai. Instead you have to take the word of people in the Jai community, which is a very biased source to say the least.
Re: Porting 58k lines of D and C++ to Jai
#197"That said, D definitely has some advantages over C++, like more powerful metaprogramming, no need for headers, no uninitialized values and more. But unfortunately, these upsides are outweighed by the downsides."
Yes, after working with D for far too long, I have decided to delete it off my computer and I'm going back to C++, where a class is still a first-class 'type', and a 'value' type at that (at least by default).
In D, a class is a reference type only and worse, the D language has no means of declaring, let alone enforcing at compile time, a perimeter around such a type, within the so called 'D module'. The entire D module is within the perimeter of your class type, at all times!
Re: Porting 58k lines of D and C++ to Jai
#198As someone who is aware of jai but not at all following the development, do the terms of the closed beta the OP is in permit code to be shown? I guess "yes", it seems so pointless otherwise. Would be very interesting to see e.g. "here is how this (gnarly) C++ turned into beatiful jai", zoomed-in to actual code level.
Blow regularly streams himself hacking on jai on Twitch, so I don't think there's any concern about hiding the code.
Re: Porting 58k lines of D and C++ to Jai
#199Earlier quoted context omitted.
I think that Jai / Zig / Odin all started around the same time. D is closer to C++ than C, in my opinion. I suspect that Jai was an inspiration for Zig and Odin. Many developers in gamedev circles are still using C or orthodox C++ (C++ without most of the bullshit) but are frustrated by many features and gaps. Short compilation time is one of the big goals, as it is crucial for fast iteration. The goal is simply to h…
> D is closer to C++ than C I'd put C++ as being between C and D, as D leaves a lot of things behind like the preprocessor.
.. you forgot to mention also, that (in the context of a D module) D stops treating a user-defined class-type as real type. Additionally, a D class is a reference type. Whereas in C++, a class type is a real type (treated as any built-in type), and is a value type (by default).
Nor does D have a concept of C++ friend.
So even when it comes to classes, C++ and D are miles apart.
Re: Porting 58k lines of D and C++ to Jai
#200Earlier quoted context omitted.
I think that Jai / Zig / Odin all started around the same time. D is closer to C++ than C, in my opinion. I suspect that Jai was an inspiration for Zig and Odin. Many developers in gamedev circles are still using C or orthodox C++ (C++ without most of the bullshit) but are frustrated by many features and gaps. Short compilation time is one of the big goals, as it is crucial for fast iteration. The goal is simply to h…
> D is closer to C++ than C I'd put C++ as being between C and D, as D leaves a lot of things behind like the preprocessor.
Honest question: as a GC’d language, D seems to occupy the same niches as Go, JVM-based, and CLR-based languages rather than that of C++. Wouldn’t it be more accurate to compare to them than C/C++? Am I misunderstanding something?