Actually pretty cool, makes me like Jai a whole lot more than I expected.
The closed development model still kinda boggles my mind though. Seems like a gigantic bottleneck and liability for the sake of maintaining the illusion of control. Main benefit is, I guess, you get to head off lots of design arguments? Mmmmmmmaybe worth it.
I think the main benefit might be “mental health”, no need to worry about lack of adoption if no one can adopt it. No need to worry about people writing articles about why your project sucks if only “friendlies” have access to it. No need to worry about how to politely decline patches if no one can submit patches. Etc.
Yeah, that’s the thing. If you want to be a control freak, fine, there’s plenty of ways of doing it besides forcing people to ask permission to get the heckin’ compiler. Doesn’t that just create more work?
I would think it would! Though, perhaps the whole thing is a growth hack. You have this trickle of blog posts that come out about Jai, that continuously make people curious about it.
Re. manual memory management: I kinda feel that, if we’re in a metaphorical epidemic of razor-slashings, then it would be good if language designers stopped coming out with new and exciting varieties of double-edged razor blades, and maybe considered product safety. I mean, even C++ has managed to wrap tape around one of the blades so you can hold it safely, most of the time, if you don’t slip.
I realize Jai is aimed at game dev, not something with bigger security concerns like OS kernels or banking systems, but given the well-known endemic problems in the game industry, it might be better to pay some attention to making development more reliable so teams don’t have to spend all their time in crunch-mode fixing bugs, rather than cowboying memory management to eke out another frame-per-second. (But then, I don’t work in games.)
That being said, there do seem to be some cool ideas. The “context” thing would be useful — it looks basically like Go’s ‘context’ package but with the context passed invisibly. I wonder, though, whether the ABI passes it as an invisible parameter to everything (which will take a toll on performance) or if it’s effectively a thread-local global (in which case you can pretty easily do the same thing in C/C++/Rust/etc.)
stopped coming out with new and exciting varieties of double-edged razor blades, and maybe considered product safety
Eh, I feel like slices + bounds checking + maybe types + no (easy) pointer arithmetic gives you 90% of the memory safety that you need for problems with relatively simple memory-management schemes. Double-frees aren’t common in arena-allocated stuff like game code.
That being said, I’d be interested in seeing a memory-safe(r) language use a region-based or arena-based allocation scheme [1]. I wonder if that would be enough to convince more game devs to switch. C#’s structs are a huge help in reducing the amount of temporary short-lived allocations a program makes (and I regularly wish we had them in Java – garbage-free Java is not the most pleasant thing to write).
[1]: Although this might be a hard thing to combine with GC – I can’t have been the first person with this idea, but I can’t think of any languages that do this.
Very good article. I’m not going to spend enough time with Jai to ask for the beta but this reading has been very illustrative of how programming in Jai is like.
Lots of these design decision overlap with Odin, and Zig to a lesser extent. If this seems interesting to folks, I’d recommend checking them out as well. Odin has:
the implicit context in every function with a default allocator and temp allocator
compiler directives (different ones though, including #soa vectors which allows you to write code as if it’s an AoS but uses SoA under the hood!)
nice reflection
very similar syntax to Jai
built in mat/vec types that autovectorize allowing you to do some basic array programming, really nice for graphics programming code
auto generated string formatter
Zig has:
a scriptable build system in the same langauge
comptime programming (although comptime memory allocation is handled separately in Zig, I’m curious how Jai manages to use the same allocators – I’m guessing it compiles and runs the code block as part of the compilation step?)
auto generated string formatter
nice optional type/error type syntax
a ridiculously nice cross-compilation setup
Interesting to see what features Jai includes though. I’m glad to see more languages pop up in this “C+” space. There’s a lot of small improvements you can make to C while still keeping the language lightweight.
Actually pretty cool, makes me like Jai a whole lot more than I expected.
The closed development model still kinda boggles my mind though. Seems like a gigantic bottleneck and liability for the sake of maintaining the illusion of control. Main benefit is, I guess, you get to head off lots of design arguments? Mmmmmmmaybe worth it.
I think the main benefit might be “mental health”, no need to worry about lack of adoption if no one can adopt it. No need to worry about people writing articles about why your project sucks if only “friendlies” have access to it. No need to worry about how to politely decline patches if no one can submit patches. Etc.
I think you can do this in other ways–like these 5 words: “We do not accept patches.”
edit: well, I guess technically patches aren’t design arguments. But, anyone can write one of those on a blog or something.
Yeah, that’s the thing. If you want to be a control freak, fine, there’s plenty of ways of doing it besides forcing people to ask permission to get the heckin’ compiler. Doesn’t that just create more work?
I would think it would! Though, perhaps the whole thing is a growth hack. You have this trickle of blog posts that come out about Jai, that continuously make people curious about it.
Re. manual memory management: I kinda feel that, if we’re in a metaphorical epidemic of razor-slashings, then it would be good if language designers stopped coming out with new and exciting varieties of double-edged razor blades, and maybe considered product safety. I mean, even C++ has managed to wrap tape around one of the blades so you can hold it safely, most of the time, if you don’t slip.
I realize Jai is aimed at game dev, not something with bigger security concerns like OS kernels or banking systems, but given the well-known endemic problems in the game industry, it might be better to pay some attention to making development more reliable so teams don’t have to spend all their time in crunch-mode fixing bugs, rather than cowboying memory management to eke out another frame-per-second. (But then, I don’t work in games.)
That being said, there do seem to be some cool ideas. The “context” thing would be useful — it looks basically like Go’s ‘context’ package but with the context passed invisibly. I wonder, though, whether the ABI passes it as an invisible parameter to everything (which will take a toll on performance) or if it’s effectively a thread-local global (in which case you can pretty easily do the same thing in C/C++/Rust/etc.)
Eh, I feel like slices + bounds checking + maybe types + no (easy) pointer arithmetic gives you 90% of the memory safety that you need for problems with relatively simple memory-management schemes. Double-frees aren’t common in arena-allocated stuff like game code.
That being said, I’d be interested in seeing a memory-safe(r) language use a region-based or arena-based allocation scheme [1]. I wonder if that would be enough to convince more game devs to switch. C#’s structs are a huge help in reducing the amount of temporary short-lived allocations a program makes (and I regularly wish we had them in Java – garbage-free Java is not the most pleasant thing to write).
[1]: Although this might be a hard thing to combine with GC – I can’t have been the first person with this idea, but I can’t think of any languages that do this.
Really neat set of tradeoffs and benefits. The “Custom Iterators” section was a light bulb moment.
I think I would include custom iterators at least as a “medium idea”, not small, but overall a very good article. I appreciated it a lot.
Very good article. I’m not going to spend enough time with Jai to ask for the beta but this reading has been very illustrative of how programming in Jai is like.
Lots of these design decision overlap with Odin, and Zig to a lesser extent. If this seems interesting to folks, I’d recommend checking them out as well. Odin has:
Zig has:
Interesting to see what features Jai includes though. I’m glad to see more languages pop up in this “C+” space. There’s a lot of small improvements you can make to C while still keeping the language lightweight.