←back to thread

Four Years of Jai (2024)

(smarimccarthy.is)
166 points xixixao | 5 comments | | HN request time: 0.876s | source
Show context
TinkersW ◴[] No.43726834[source]
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.

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.

I do like the build script being in the same language, CMake can just die.

The metaprogramming looks more confusing than C++, why is "sin"/"cos" a string?

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.

replies(4): >>43727697 #>>43731025 #>>43733282 #>>43736239 #
unclad5968 ◴[] No.43731025[source]
I seriously doubt that any of them have trouble understanding a concept as simple as RAII.
replies(1): >>43732144 #
kbr- ◴[] No.43732144[source]
Yeah it's weird but the author of this post claiming that defer can replace RAII kinda suggests that. RAII isn't just about releasing the resource you acquired in the current scope in the same scope. You can pass the resource across multiple boundaries with move semantics and only at the end when it's no longer needed the resources will be released.
replies(1): >>43734447 #
deagle50 ◴[] No.43734447[source]
I don't get the point, what does this have to do with defer?
replies(1): >>43739724 #
kbr- ◴[] No.43739724[source]
The author of the post claims that defer eliminates the need for RAII.

Well, goto also eliminates the "need" but language features are about making life easier, and life is much easier with RAII compared to having only defer.

replies(1): >>43740123 #
1. deagle50 ◴[] No.43740123[source]
I got that, but the I don't see what the example of move semantics has to do with RAII or defer.
replies(1): >>43742813 #
2. kbr- ◴[] No.43742813[source]
It makes things easier. Usually the move constructor (or move assignment operator) will cause the moved-from object to stop being responsible for releasing a resource, moving the responsibility to the moved-to object. Simplest example: move- construct unique-ptr X from unique-ptr Y. When X is destroyed it will free the memory, when Y is destroyed it will do nothing.

So you can allocate resource in one function, then move the object across function boundaries, module boundaries, into another object etc. and in the end the resource will be released exactly once when the final object is destroyed. No need to remember in each of these places along the path to release the resource explicitly if there's an error (through defer or otherwise).

replies(1): >>43746178 #
3. deagle50 ◴[] No.43746178[source]
I agree that it makes some things easier (at the expense of managing constructors/destructors), I'm disputing the blanket assertion that it's superior to manual management, in the context of Jai (and Odin). You're also introducing a reference count, but that's besides the point.

In Jai/Odin, every scope has default global and temp allocators, there's nothing stopping you from transferring ownership and/or passing pointers down the callstack. Then you either free in the last scope where the pointer lives or you pick a natural lifetime near the top of the callstack, defer clear temp there, and forget about it.

replies(2): >>43748893 #>>43749888 #
4. jguegant ◴[] No.43748893{3}[source]
> You're also introducing a reference count, but that's besides the point.

How so? RAII absolutely doesn't imply reference counting.

5. kbr- ◴[] No.43749888{3}[source]
You may also want to pass a resource through something like a channel, promise/future pair or similar. So it's not just down/up the callstack, sometimes it's "sideways". In those cases RAII is a life savior. Otherwise you have to explicitly remember about covering all possibilities: - what if resource never enters the channel - what if it enters the channel but never gets retrieved on the other side - what if the channel gets closed - what if other side tries to retrieve but cancels

Or you leak the resource.