17:00 There's a talk from Peyton Jones, one of the Haskell guys, about how great it was/is for the language to not be super popular as that ensures flexibility. How much flexibility? They shipped a windows version of the compiler that deleted the source files in case of a type error (a feature more languages should have!).
I think it depends on what is "better" for you. Jai seems to be a general purpose language (system programming language). It should give you support to everything that C++ can use (you can link with C code and access memory as C), so if the question is "can Jai be used as a general purpose programming language" I would say "yes", but being better or worse depends on what works best for you, imo.
Programs in Jai will compile way faster than C++ programs, unless you use a very careful subset of C++, in which case I suspect Jai will give you more features
I've played around a bit with Zig, which is a language with goals somewhat equaling Jai (the dev even have said Jon's discussions has inspired him). I wonder if Jon has taken a look at that, maybe inspiration can go both ways :) I love that there are so many projects ongoing right now working on creating system languages that lets us write fast code but better than we have done in the past.
0:00 How much work was it to get stuff running on the Switch? 1:01 Will closed beta be first come first server or invite-only? 1:38 How will macros differ from C? 1:57 Are you still running with no_jobs? 3:25 How does the pipe dependency system work? 4:03 Is cross compilation with Switch only with LLVM or do you have a new backend? 4:12 What are your ideas about memory management? 8:02 Public beta estimated before 2020? 8:17 Do you also have a module for network stuff like simple TCP sockets? 8:42 Do you feel like it's holding well to the original principles/80% solutions/not a big idea language? 10:42 Do you have concrete plans for handling pointer aliasing? 11:20 With the removal of the CRT how do you implement math functionality like sine/cosine? Are you going to make custom implementations for the compiler? 12:17 How many people are actively working on the language? 12:31 Is zero-initialized still the default? 13:05 Demo at Handmade Seattle? 13:13 How closed will that beta be? 13:28 Can it run in all platforms? 13:51 Will this video be on RU-vid? 13:57 Did any handmade debugger developers contact you to work on support for this language? 14:27 Why did you decide on implementing macros in the language rather than using the pre-existing meta programming functionality? Are the macros semantic or one-step about textual? 16:39 What is your approach for marketing the language going to be? 17:40 How mature is the language currently in your opinion? 17:55 Are you sticking with your idea of putting all source on library imports? Will that shift the culture of distibuting source instead of distributing compiled binaries? 18:40 AOS feature is no longer in the language, right? How do you feel about the language's ability to provide support around that? 19:30 Can you briefly explain again why constructors and destructors were cut? 19:41 Is there some kind of replacement for it? 19:47 Will the closed beta be people you know personally? 20:03 Are you making your own linker now? 20:05 What was the feature in the compiler that took up most of the time? 20:36 Has memory profiling become easier or more involved with your current approach of not having ctors/dtors? 21:40 Are you generating LLVM IR and feeding that in or are you manually feeding the parts of the parts of the program to the LLVM library? 22:11 Do you have anything planned for audio synthesis in the audio module? 22:21 How does this compare to C/C++ for performance critical apps? 22:30 How much interest is this [getting] from other game developers? 22:40 Are structured notes on the roadmap? 23:03 The language is intended to get a screen on all operating systems or do I misunderstand this? 23:19 Do you think this language had ever been applied to make the web a sane place to develop? 23:45 How much of the game development process do you think will be sped up for most teams? 24:40 Are there portability issues with the intrinsic system? 24:57 What is meant by defer? 25:04 Will the closed beta participants be able to stream/make videos? 25:24 Is the module system similar to the approach of any other language? 25:35 How many lines to get pixels on the screen? 26:02 Do you think you'll end up writing an ARM backend or just leave it with LLVM? 26:20 Can you at some point show the tricks like atoms[?] that make the compiler so incredibly fast? 28:21 It's very hard for a new language to succeed. What are the two key features you think [...]? 28:50 How painful do you say the learning curve is? 29:29 Chucklefish gave up on Rust, they focus on C++ now. 29:47 What about type safety? What is the attitude towards the plethora of proven, useful type features being used in many languages now? 30:28 Can you do a rant about containerization sometime? 30:44 What do you think about games that aren't trying to push the boundary of performance? Surely the most important thing then would be ease of development and maintenance? 33:31 Do you have plans to add immutable non-alias strict pointers? 33:59 Will you open-source the compiler? 34:46 Are you encouraged to pass everything by value and let the compiler decide if it should be a const ref? 37:21 Do you plan on having some sort of built-in game loop? 37:30 Will you come with a math module with types like matrices? 37:35 Do you plan on supporting any architectures besides x86? 37:45 Are you going to make a package manager? 38:08 Do you think compiler supplied vector structs with only basic operator overloads is a good idea? 38:57 Will there be vector types with swizzling etc like in shader languages? 40:02 I find it amazing that I'm watching this live in an underground train half a world away in Melbourne but we still have crappy JS libraries. 40:20 Has Casey [Muratori] got to play with the language? 40:40 How are versions going to be managed post-release? 41:00 Is it fair to say that the language encourages meta programming over putting complexity in the type system? 41:16 Is there any plan for an IDE? 41:20 I'm generating LLVM IR for Odin, it's a nightmare. Are you admitting the bitcode or just using the libraries? 43:10 Will you provide a custom scalable allocator or rely on the system allocator? 43:50 I remember one of the optimization streams where you avoided looking into time spent in the type checker because it was too complicated. Did you go back since then and find some nice type checker performance wins? 44:42 Any plan to begin self-hosting? 45:32 For APIs in C or C++ do you think you could provide a tool to convert API headers? 46:10 Will it be possible to implement a working Edit&Continue? 46:27 How is the source code broken up into small pieces for the lexer/parser to be multi-threaded? 46:58 Do you consider creating your own internal representation? 47:05 How are binary sizes looking in general? 48:10 They [Chucklefish] have another game and wanted to use one engine for everything. 48:46 Are there a lot of features from C++ that have been left out? 48:54 Will you add any struct procedure call syntax to the language? 49:25 I've been told that web programming is so different than game programming that the knowledge is not transferrable. I disagree with that but are there principles of programming games you feel like should not be applied to the web? 50:23 Do you think this language will be easier to pick up by someone who doesn't use any low-level languages? 50:39 Would this be applicable for image processing? 50:48 Will the game engine you ship with the language support 2D games? 50:59 Will the game be open source? 51:01 Do you support RAII? 51:45 How stressful has the development of the compiler been compared to the stress of games you've worked on? 52:00 What debugging tools are you using? 52:10 Is there a grammar published? 52:28 wrap up
Currently the language supports "notes" on all structures and members of structures as part of the reflection system, but these notes are just strings. Some people want polymorphic notes so that they can do validation on them easier.
There's a recent post from Walter Bright on retrofitting ownership/borrowing like system into D language: dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ I don't know how much relevant that is to Jai. Probably little.
If the ECS you're talking about is "working around the borrow checker," wouldn't that be true for any other arena allocator? Or even any array? What _is_ working around the borrow checker is interior mutability, something which is often used in arenas... as well as every single use or implementation of a mutex. Any graph in Rust that's not a tree either indexes into a flat array, or uses interior mutability because if you're trying to make one node point to another, since you can already go the other way, Rust considers the nodes immutable, which defeats the purpose of a graph. The core of nearly every form of interior mutability rests on UnsafeCell, which as the name implies requires unsafe to use. But unsafe is not a complete blight. It's used when the programmer can prove something the compiler can't (which isn't very much). It's useless if the codebase is littered with unsafe, but otherwise, if you can prove to a future programmer reading your code that your unsafe code is sound, then it naturally follows that any safe code that calls it is also sound. It still requires scrutiny, but it's much less code to scrutinize. For allocated, but uninitialized memory, Vec maintains separate length and capacity fields. Any index between those values is uninitialized memory. Vec has a set_len method, but is tagged unsafe because you now have access to uninitialized memory. ManuallyDrop is a wrapper with 0 size overhead who's destructor specifically doesn't destruct whatever it's holding. Lastly there's MaybeUninit, which is a C-union so that it being uninitialized isn't undefined behavior. Rather than getting a reference to the internal data, which assumes it's initialized, you get back a raw pointer that you can write to without destructing what it's pointing at. If you want to fill a statically sized array with complex objects, you can use MaybeUninit to prevent the compiler from assuming there's valid data, allowing you to assert at the very end with assume_init. Getting the interior pointer to uninitialized memory (or even getting a null pointer) are actually completely safe in Rust. It's reading or writing to them that's unsafe. Interestingly, Rust doesn't zero-initialize it's memory. It requires the programmer specify an initialized value before it can be used. That "initialized" value could however be MaybeUninit::zeroed(). Honestly, the more I learn about Rust's memory management, the more impressed I become. People have even implemented the SoA system you've previously had, and I've been able to make the relative pointers with a mostly safe API thanks to MaybeUninit and Pin. The main points of unsafety can mostly be covered up by a safe macro (mostly because I would only be able to return a reference rather than the original object, but I'd need to make sure the object isn't temporary and stays on the stack even if it's inaccessible). Complex type systems are redundant? Rust's type system is why I was able to confidently implement one of your language features in user code. Rust also doesn't allow null for things beyond raw pointers, and then adds it back with algebraic data types, except now it's impossible to access the value if it doesn't exist, and it doesn't require any compiler code to handle nullable types because it's implemented with standard language features. They're also how Rust deals with error handling. Exceptions? We just have a macro that was promoted to an operator that just automatically returns to propagate errors, and, again, you can't access a value if there's an error; you have to handle it. And the Result is a first class type so there's no worrying about throws or try/catch.
Rust has a lot of pros for sure, I love its trait-based type system for one. But I'm not exactly sure how many of those pros has anything to do with the borrow checker. If bypassing it is what makes the ECS or arena or any other good stuff good, then what's exactly the benefit of emphasizing such constaint at the language level in the first place? It prevents some memory-related bugs from happening yes, but it's such an overkill... Is the trade-off really worthwhile if we have to bypass the constraint manually for so many use-cases? Jonathan had ranted about the ECS example he mentioned (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-4t1K66dMhWk.html), watching it raised these questions for me but I'm not sure about the answers yet>.
I should mention that a recent blog post was made detailing how much of Rust is actually necessary to make it work and very little is actual bloat. boats.gitlab.io/blog/post/notes-on-a-smaller-rust/
TL, DR: Does anyone know why Jon et al. decided to implement the language compiler in C++? Languages like Lua are written in ANSI C for great portability. AFAIK the Jai compiler code uses a bespoke hash table implementation, as opposed to the STL. Why use C++ if it has features you go out of your way to avoid? Why not go for optimum portability?
Probably because it uses llvm to target across platforms, which is in C++. At this point the platforms which only have C compilers are cross-compiled anyways so it’s not an issue.
I think the reason web programming is different is because you have to consider security and fraud, especially when dealing with credit/debit card transactions. I do agree that we can just use one language to simplify building websites, but there must be a client-to-server separation for security to work. Things like Apache could indeed be simplified down, databases probably could be simplified also, but they are integral parts of the web that have to be there. That being said, I see that the SAFE network by Maidsafe looks promising as a decentralised network, not necessarily it's development APIs. They also don't support traditional ecommerce. I think a decentralised web solution with a single language would be most useful, but people with good networking knowledge are best for that and there will be some opinions/objective points to contend with when it comes to security and their implementations.
The reason web programming is different is short-sightedness and sub-par tooling that thrived within a technological gap. When www was just starting to blossom, pretty much anything a server or client machine did was always going to be much, much faster than transmission. So "nobody cared" (c) if it took a few extra microseconds to compute something, if it was easier to express, or more people could learn to do it. But then one piece of crap was piled onto another, and another, and another, microseconds became milliseconds, and seconds. All the while time was jogging along, and "suddenly" there's fiber optics "everywhere", and companies with millions of customers all over the world. And again, "suddenly", those extra milliseconds and seconds cost hundreds of thousands, even millions, in power and/or environmental security, not to mention frustration of customers that now have to wait upon software instead of the wire. In all likelihood it'd take much longer to recover from this than it took to get to such state in the first place.
10:00 I would disagree that the notion of moving something into uninitialized memory complicates user code. It makes it more explicit (i.e. emplace_back). When you're overwriting something by move-assignment (i.e. arr[i] = move(x)) then yes, sure, it's dangerous and carries hidden complexity (at least in C++). But you're not doing that if memory is uninitialized (again, at least in C++)! And when you know it's uninitialized, you do an explicit constructor call/write. Although I guess having to make such informed decisions could be viewed as complication, it's not like there's a universal elegant solution here either way. In Jai you'd jump through some hoops as well. I.e. you wouldn't just overwrite a pointer and thereby dangle it, you would also have to take different paths depending on whether memory is initialized, and you'd have to be doing that manually. Generally, the most useful forms of constructors are copy and move ones, which are merely hooks that you'd have to write explicitly anyway in a language without constructors, if you have a need for such functionality. But even then it's mostly when you're hiding pointers behind "convenient" wrappers, which, IMHO, should be an exception rather than norm, C++ advocate views notwithstanding.
Hey Jon, thanks a lot for the updates about the language! This and Zig are holding my attention for new languages. Just a heads-up since you mentioned your burger, processed meat is a class 1 carcinogen (scientifically proven beyond reasonable doubt to cause cancer in humans) according to the American Cancer Society, the World Health Organization and at this point most serious nutritional bodies. Eating an amount of processed meat equivalent to a single hot dog per day increases your risk of cancer more than living with a smoker. Health is wealth mate, and keep up your great work improving the software development industry which the world relies on.
@@jack-d2e6i Why? Obviously processed bread buns are not healthy but they're also not a class 1 carcinogen. It seems to be the evidence shows that processed meat is worse for your health than white bread, but both should be avoided.
@@UltimaN3rd I'm not aware of any science directly comparing processed meat to white bread so let me lay out my case. 1. A burger is not necessarily using processed meat. Fresh mince rolled into patties. That's it. So "class 1 carcinogen" would not necessarily apply. 2. Meat does not spike insulin like bread does. This is important for hunger management. If you eat the bread, you'll feel more hungry quicker, and thus will be more likely to overeat. Incidentally, overeating will probably include eating even more meat, encourage obesity (which is a huge risk factor for an entire host of disease) and over time tend toward type 2 diabetes as your pancreas cannot produce enough insulin. The obesity and insulin resistance being *long term* effects of chronically high sugar intake from foods like bread. 3. Meat contains nutrients that bread does not. Creatine, protein, fats, minerals, amino acids, etc. This means on a basic level that bread is just "empty calories" compared to meat. This means that calorie for calorie the meat is more nutritious / better for your health.
@@jack-d2e6i Creatine is an amino acid, and amino acids make up protein so three of the five nutrients you listed present in meat but not bread are practically all the same. They're also contained in bread. . . As for diabetes, insulin resistance is caused by intramyocellular lipids - fat inside the muscle cells prevents the normal function of insulin to allow blood glucose into the muscles. Intramyocellular lipids are caused mainly by eating "free fats" - fat unbound from fibre, such as in processed foods (oils) and animal products (which contain no fibre). Relating to diabetes you might be interested in the BROAD study: www.nature.com/articles/nutd20173.pdf Like I said before, processed foods like white bread should be avoided so don't mistake me for saying white bread is healthy.
