00:00 _(Introduction)_ 01:43 Regarding compiler intercepting, is it intentional/final that code blocks are seemingly read-only? 05:17 What are current feature goals that you are working towards? 09:47 Wouldn't stability be the #1 priority before release? 11:10 What is #run,stallable? 15:39 How many neat general patterns/idioms emerged from Jai that you did not expect? 16:15 How will Jai deal with shaders? Are you still considering a particular shader transpilation? 20:01 How is the Jai compilation time lately? Are there any unforeseen obstacles to achieving the goal of 1 million lines / second? 31:14 What are some principles you have in mind for implementing an optimization pass for the compiler? 36:20 What is the most useful feedback we can give you as beta testers? 42:42 What would you consider technical problems/unknowns that someone should be aware if they want to ship production Jai software today? 46:03 Plans to add a compiler directive to handle pointer aliasing? 50:52 Thoughts on using raylib, SDL & OpenGL in Jai? 57:37 Regarding backends, do you plan on supporting metaprogram-supplied hints for program optimization? (e.g. block is unreachable, values have some expected range, pointer argument never null, ...) 01:01:13 How much of a productivity benefit do think Jai has provided you & your team compared to using C++ in Braid or The Witness? 01:02:50 Regarding block that return values (e.g. _ifx_), can they be made more general? 01:04:02 Is there some reason for unnamed #import inside a function scope being visible outside of it? 01:05:20 Plans for closures in Jai? 01:06:56 Plans for metaprogram plugins for modules? 01:11:10 Plans to do more optimizations for the x64 backend? 01:16:05 Why does operator overloading not work for structs defined in named modules? 01:16:30 Plans for notes on inner-scope blocks in Jai? 01:17:00 Will polymorphic procedure metaprogram messages be improved to better handle unused polymorphic procedures? 01:20:54 What is your policy for accepting new backend implementations for certain shipped modules? (e.g. adding Wayland support in addition to X11) 01:22:14 _(Same question for a Vulkan or Metal backend.)_ 01:24:50 What would you change in the Jai compiler if you could start over again? 01:27:27 How does resolving dependencies in identifiers work right now in Jai? 01:32:25 What is the reason that led to passing the context being part of the calling convention rather than being thread local storage (TLS)? 01:37:57 How to truncate a 64-bit pointer index into a 32-bit one for WASM32? 01:40:17 Is there anything obvious in the modules folder that can be combined to make it smaller? Any constraints? 01:44:00 _(A question on controlling namespacing for globals.)_ 01:45:13 _(The earlier context question was concerned about the cost of repeatedly duplicating the context.)_ 01:46:47 Is _remap_context()_ also usable for changing where an array returned from a function gets stored? 01:47:26 Would it be possible to compile to Xtensa architecture (ESP32) from Jai? 01:49:15 Are you considering limiting/weakening any other language semantics for the purpose of simplifying the implementation? (e.g. polymorphism & overloading seems to be a constant source of minor bugs.) 01:52:00 _(re: macOS bundler: it is necessary...)_ 01:53:39 _(re: WASM32: The WASM64 would be probably widely supported in the following two years, so there's maybe no point in supporting WASM32 from the compiler perspective - we can provide partial support with an external truncating program.)_ 01:55:15 Does unrolling to enable usage of SIMD operations still give enough benefit to be worth it? 01:58:06 _(Would not have thought of auto-vectorization to be that ineffective.)_ 01:58:42 How can you know if something is a bug without a specification? 01:59:20 _(Wrap up)_
The embedded world will 100% continue to use 8/16/32-bit systems. Each application for computation, power conservation, cost, and even footprint are different which is why there are so many different MCUs on the market.
@@space_cowboy007 No, it's a systems programming language. And every microcontroller toolchain is *d o g s h i t*. Basically each one requires an IDE for the least friction, use CMake, and their own custom C compiler. My point is that there'll still be use for architectures that aren't 64-bits that I would hope Jai could/would be ported to, though I know it's unreasonable. There's a lot that Jai does that takes plenty of overhead that 8-bit and maybe many 16-bit MCUs wouldn't be able to support-but I love and appreciate Jai nonetheless.
59:16 - Maybe it used to be even more important but I think loop unrolling is still very important because it can help with instruction level parallelism by breaking long chains of dependencies into multiple long chains.
What do you mean by "less width"? Love to hear an example of syntax for a theoretical language that has less width and still be "data oriented designed". You can technically use data oriented design in any language supporting data structures and types of some kind if that's what you're worried about.
1:16:00 You talk about giving SSA a go, FYI Cliff Click's Sea Of Nodes technique looked decent, for building a fast optimizer (and pretty much is SSA+). Relevant but beginnerish coffee compiler club episode: watch?v=aELiGg4SQXU He's talked about it many times.
I will make one game in my life and it will be written en Jai. I’ve been watching on the sidelines the development of the language, and while I understand 30% of what is being said, I can see how this is a developers first tool. I’ll let you know when my fps/mmo/trivia game is released lol hehhe no, my game ambition is strictly bounded. Both in scope & release date wise.
"The things in the compiler are too tangled together. We want them to be more orthogonal / decoupled" You guys heard it here first. Jonathan Blow's making an argument for encapsulation! ;)
@@TheDanVail people complain about the borrow checker when they haven't even spent a little bit of time writing Rust. It's ignorance. I consider myself to be a good developer but not anything close to a genius. If I can write Rust and have no friction with the borrow checker, he can do so as well.
@@user-ov5nd1fb7s I don't think the expectations you place on others are realistic or particularly fair. If everyone who's opinion you're going to respect needs to learn to program in Rust to the extent where they've modeled themselves to the language in such a way they don't feel friction with one of the big new features you've just introduced massive selection bias in who you listen to. You've already dismissed every opinion Blow could have as ignorance because he's not spent sufficient time with Rust. I doubt I have spent sufficient time with Rust for you to respect my opinion so I won't share.
@@0xCAFEF00D what do you call something, if not ignorant, when it's an opinion based on no real knowledge of the topic? That is the definition of ignorance, right?
