Surprising deep and level headed analysis. Jai intrigues me a lot, but my cantankerous opinion is that I will not waste my energy learning a closed source language; this ain’t the 90s any more.<p>I am perfectly fine for it to remain a closed alpha while Jonathan irons out the design and enacts his vision, but I hope its source gets released or forked as free software eventually.<p>What I am curious about, which is how I evaluate any systems programming language, is how easy it is to write a kernel with Jai. Do I have access to an asm keyword, or can I easily link assembly files? Do I have access to the linker phase to customize the layout of the ELF file? Does it need a runtime to work? Can I disable the standard library?
I have my doubts with Jai, the fact that Blow & co seems to have major misunderstandings with regards to RAII doesn't lend much confidence.<p>Also a 19,000 line C++ program(this is tiny) does not take 45 minutes unless something is seriously broken, it should be a few seconds at most for full rebuild even with a decent amount of template usage.
This makes me suspect this author doesn't have much C++ experience, as this should have been obvious to them.<p>I do like the build script being in the same language, CMake can just die.<p>The metaprogramming looks more confusing than C++, why is "sin"/"cos" a string?<p>Based on this article I'm not sure what Jai's strength is, I would have assumed metaprogramming and SIMD prior, but these are hardly discussed, and the bit on metaprogramming didn't make much sense to me.
> The net effect of this is that the software you’re running on your computer is effectively wiping out the last 10-20 years of hardware evolution; in some extreme cases, more like 30 years.<p>As an industry we need to worry about this more. I get that in business, if you can be less efficient in order to put out more features faster, your dps[0] is higher. But as both a programmer and an end user, I care <i>deeply</i> about efficiency. Bad enough when just one application is sucking up resources unnecessarily, but now it's nearly <i>every</i> application, up to and including the OS itself if you are lucky enough to be a Microsoft customer.<p>The hardware I have sitting on my desk is vastly more powerful that what I was rocking 10-20 years ago, but the user experience seems about the same. No new features have really revolutionized how I use the computer, so from my perspective all we have done is make everything slower in lockstep with hardware advances.<p>[0] dollars per second
> async/await, a pattern increasingly polluting Javascript and Python codebases in the name of performance<p>In JS world async/await was never about performance, it was always about having more readable code than Promise chain spagetti.
Jai's perpetual closed beta is such a weird thing... On the one hand, I sort of get that the developers don't want to waste their time and attention on too many random people trying to butt in with their ideas and suggestions. On the other hand, they are thereby wasting the time and attention of all the people who watched the development videos and read the blog posts, and now can do basically nothing with that knowledge other than slowly forget it. (Except for the few who take the ideas and incorporate them into their own languages).
> It’s a simple keyword, but it singlehandedly eliminates the need for any kind of RAII.<p>What if you want to put a resource object (which needs a cleanup on destruction) into a vector then give up ownership of the vector to someone?<p>I write code in go now after moving from C++ and God do I miss destructors. Saying that defer eliminates need for RAII triggers me so much
> rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compiler, dudes.<p>And how would that compiler work? Magic? Maybe clairvoyance?
The biggest "crime" of Jai is that it (soft-)launched like an open source programming language and didn't actually become open source shortly. There are so many programming languages that did go through the "beta" period and still remain open sourced all the time. Open source doesn't imply open governance, and most such languages are still evolved almost solely with original authors' judgements. It is fine for Jai to remain closed of course, but there is no practical reason for Jai to remain closed to this day. The resulting confusion is large enough to dismiss Jai at this stage.
> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compiler, dudes.<p>That exists; it's called garbage collection.<p>If you don't want the performance characteristics of garbage collection, something has to give. Either you sacrifice memory safety or you accept a more restrictive paradigm than GC'd languages give you. For some reason, programming language enthusiasts think that if you think really hard, every issue has some solution out there without any drawbacks at all just waiting to be found. But in fact, creating a system that has zero runtime overhead and unlimited aliasing with a mutable heap is as impossible as finding two even numbers whose sum is odd.
> because most Javascript programmers are entirely unaware of the memory allocation cost associated with each call to anonymous functions<p>How does <i>calling</i> an anonymous function in JS cause memory allocations?
I didn't know much about Jai, and started reading it, and it really has (according to the article) some exciting features, but this caught my eye:<p>"... Much like how object oriented programs carry around a this pointer all over the place when working with objects, in Jai, each thread carries around a context stack, which keeps track of some cross-functional stuff, like which is the default memory allocator to ..."<p>It reminds me of GoLang's context, and it should've existed in any language dealing with multi-threading, as a way of carrying info about parent thread/process (and tokens) for trace propagation, etc.
> Software has been getting slower at a rate roughly equivalent to the rate at which computers are getting faster.<p>Cite?<p>This problem statement is also such a weird introduction to specifically this new programming language. Yes, compiled languages with no GC are faster than the alternatives. But the problem is and was not the alternatives. Those alternatives fill the vast majority of computing uses and work well enough.<p>The problem is compiled languages with no GC, before Rust, were bug prone, and difficult to use safely.<p>So -- why are we talking about this? Because jblow won't stop catastrophizing. He has led a generation of impressionable programmers to believe that we in some dark age of software, when that statement couldn't be further from the truth.
I sincerely dread that by the time jblow releases jai, people will just have moved on to zig or rust, and that it will just become irrelevant.<p>I'm sure jblow is having the same fears, and I hope to be wrong.<p>Still, it's fun to be remembering the first few videos about "hey, I have those ideas for a language". Great that he could afford to work on it.<p>Sometimes, mandalas are what we need.
odin has replaced the need for jai, and even then, i'm not sure there is a need for "yet another sugar for LLVM"<p>they show an adoration for C, and they both hate C++, yet they chose C++ for their compiler, go figure
I am not interested. I am just trying to code with C3 and make some binding with another language like C and Zig, it is quiet easy and fun. I think it's enough for me to learn kinds of language than using jai that never released the compiler to the public till now.