0:00 Introduction 2:20 Roadmap for the next few Beta releases 3:30 Upcoming module handling improvements 18:53 Upcoming default metaprogram improvements 23:40 Start of the Beta user Q&A 25:50 I can see that you can change the allocator on a context by changing an allocator (a function) and allocation_data. For allocators that allow individual allocations to be returned how do you specify the equivalent of free() to the context? Or don't you? 31:14 How do you configure the compiler to build a Jai library for use on Android/ARM64? 33:53 What made you shrink the compiler team back to just yourself? 43:46 How are you feeling about how the beta is progressing? Do you have an idea of how many more times you want to expand the closed beta, or roughly when it might go into open? 46:43 Would you prefer us to report bugs asap, or wait and bundle up a few at a time? 47:46 I like the monorepo/project approach for modularity, does it conflict with your earlier statement that compilers/languages are underspecified in many regards? Should metaprogramming fill all those gaps? 50:09 Why not closures? What are the alternatives to closures? What can we do in the language that is equivalent to what closures provide? 56:34 You often talk about how syntax is not definite right now, is there anything that you are seriously considering changing in the future? 58:58 As with standard modules, could there be standard metaprogram modules, which could be included to enhance build processes and such, for instance to impose common house rules 1:01:31 The question of what is standard library vs external stuff keeps coming up; how are you aiming to delineate it? Would a "batteries included" approach covering most of the everyday stuff not provide a reasonable amount of value? Relatedly, "Basic" is a bad name for a module, as it's fairly arbitrary and different from one person to another what counts as "Basic" 1:05:56 Are there plans to add build-in support for code hotloading for running executable? 1:07:24 I have a big change for the built-in hotloader module that fixes its totally broken linux part but these fixes need to change the API slightly. Do you want such bigger changes for built-in modules? 1:15:00 You mentioned that struct literals are new which explains some of my issue but what are your current thoughts on allowing non-constant values for struct literals? 1:19:00 I couldn't find classic C-style for loops anywhere in the docs, did I miss something? 1:19:43 Have you thought at all about array-programming? 1:20:11 Currently, a 'for' loop over an explicit range (e.g. 0..3) disallows use of 'it_index'. Would you consider allowing this in the future? This would reduce friction when, upon code maintenance, the explicit range is replaced with an array whose index needs to be tracked 1:20:57 Can we get a `sockets` (or `Networking` module)? Seems like it should be in standard library 1:21:32 Currently, the single underscore, _, can be used as a variable (like in C). Do you intend for this behavior to endure, or are there plans to change it to function as a blank identifier like in Go? 1:22:40 Are minor contributions to the existing documentation (like typo fixes and small content additions) welcome? 1:23:59 To align a big team on a project it proved useful to me to restrict certain features of the language. I understand that I should write a meta-program to fail on features I want to restrict. 1:24:55 Patrick had a question a couple days ago about trying to modify parameters to functions in a function, in external libraries this is possible but within a Jai program it's not. This confused me a lot early on as well. Perhaps this could be clarified in the how_to's (pass in a pointer...) 1:27:28 Something slightly confusing is dependencies between metaprograms. When two metaprograms share common namespace that they might both want to change you might get a dependency that doesn't really exist. 1:29:56 Are there any long-term plans about documentation, in terms of format and scope? I really like the current how_tos. But I imagine there is a large amount of work to do with documenting the distributed modules and language features. Maybe more people could help out with that? 1:33:14 What plans do you have for extending the procedure/declaration notes stuff? Specifically, I work on a team of ~20 people and issue tracking/project management tools like Jira which are separate to the code are a pain, maybe there's a way the language/metaprogram can help? 1:37:59 Do you see any places in the type system where things could be added to make robust parallel programming easier? 1:40:05 Any plans to move the temporary allocator to the context so we can change the way it works if we want to? 1:44:12 Threading is currently based on function calls; is there no interest in tying thread functionality more tightly to the language in ways that makes it easier and more natural? 1:47:47 Are there plans to add complex numbers or 16-bit half precision floats? 1:49:30 I've been using Visual Studio to debug programs and its been very good. But just wondering the current status on debugging with other tools, and what are the plans for the future? 1:51:00 Will you be releasing a recent game you wrote using the language when it's publicly released? The demo games that come with the compiler are great but the invaders example is quite old and I imagine you might be writing things a bit differently now 1:55:10 Will you add the `f32` and `f64` type aliases for consistency with other shortened types? 1:55:57 I'm porting a program from c++, which I understand is more liberal about implicit casts than this language. And one of the most common compilation errors for me are type conversion-related by far. My current impression is that the language seems to push you to use the default s64 integer type for numbers as much as possible, and only rely on smaller/unsigned numbers if necessary. Could you talk about how this decision was beneficial for you so far, and if it's been difficult to think harder about explicit type casts in you game's large codebase? 2:01:22 What are your plans for the future of the LLVM backend? On one hand its a dependency that would be good to not have but I'd be afraid of losing support for all the targets they already have. 2:04:07 What are your plans to handle language stewardship after it is public? Will it still mostly be a one-man show or will you focus on other things and delegate, while still helping to maintain the language's direction? 2:05:00 How likely is that Jai ever runs in a 32-bit system? (Thinking about embedded, maybe older hardware, etc) 2:09:25 There's a class of problem for which compile time metaprogramming is very useful, but for which you don't necessarily want to spend the time at compile-time every single time you compile your program (say, bindings for external libraries...). Have you thought about building more code generation/caching of compile-time results into the compiler or included modules? Something like a stickier version of .build/.added_strings? 2:13:45 Do you have plans for a Jai Foundation or similar to maintain the language? 2:14:10 Does the LLVM auto-vectorize anything currently? 2:14:52 What are the plans for intrinsics? 2:16:35 Do you plan on releasing a memory safety metaprogram in the standard library for the public release? (Like an optional, less-restrictive Rust borrow checker) 2:20:57 What is the current status and/or your view on dependency injection and compile time arguments for libraries. You had a talk about libraries a long time ago but I haven't heard as much since 2:21:40 Would you be open to do macros that are more friendly to pass in #code parameters? 2:23:25 I've been keeping notes about what I've thought about the language as I've been learning it, figuring to write it up further down the line when the compiler had stabilized somewhat. Is that preferred, or would you rather get feedback right away? 2:24:33 Have you considered adding annotations to other things besides just declarations? I would like to, for instance, be able to add an annotation to parameters passed to a function. This could be used to package your parameter to the function at compile time 2:25:45 What's the current compile time of the game? 2:28:07 Have you considered a command line option to swap between release and debug builds. I use Jai for a lot of small one-file programs that it's not worth fiddling with build_options. This is the main option that I'd like to be able to modify quickly 2:28:48 Even though Jai's philosophy is a lot about recompiling the code, it's very natural that a lot of companies will want to release libraries instead of the source. Are there any plans regarding libraries built in Jai? Any ideas on how that will work? 2:32:20 Time for a compilation is already (that I know) the best for a language of this kind and this level of features. You mentioned that there are still improvements to be made. What are the next things to tackle regarding this? How much of an improvement do you think is achievable compared to the current implementation? 2:36:50 In order to support IDE diagnostics it would be useful if the compiler reported all errors instead of the first error. Is there a plan to support additional error reports from the compiler? 2:39:01 Do you think it'd be useful to know what stuff is taking most of the compile time? In the same way we warn about structs having too much type info. Might be cool if we'd warn for things like, "this #run directive takes up 50% of your compile time" 2:39:45 A while back we discussed about using this language kind of like a scripting language (i.e. no entry point, doesn't produce output), but it still has some overhead to set it up. Any plans on improving this? 2:42:41 Start of the open Q&A (Twitch chat, not Beta users)
Really appreciate the preamble - the core goals you've laid out sound extremely appealing. I especially dislike the headaches that come with trying to build various projects, which often can't be done easily because of the slew of incompatible/outdated dependencies.
incompatible/outdated dependencies are extremely frustrating and distract from the initial task you set out to achieve. I'm with John Blow, i just want to be able to use a computer to run a program.There is room for the ideas John expresses.
@@m.p.jallan2172 yep... as many have said : assembly is more appealing in ways. there's just you, the CPU, and the other hardware. your code works or it doesn't, maybe it crashes. modern stuff just isn't that simple. it's especially bad in web development. [and FORCED on you since third-party or self-made, it's almost impossible to develop for web without boilerplate since the stock APIs are so half-assed] just running a program, what a novel idea! it's not like this is literally WHAT we developed the computer to do or anything... [seriously, good GOD am i tired of fighting with my software to make it do what it's actually supposed to do. my experience as an end-user and as a developer progressively becomes more and more absolutely MISERABLE.] i really hope this works-out. i won't touch the C family or its toolchain because they're difficult to use and full of flaws. [plus dependency hell...] JS also sucks massively. i never WANTED to use it. it was never INTENDED to write large programs with. also looked into some other native languages. [also python, java, and i WAS planning to do flash when i actually could properly learn how to use the IDE and program actionscript] they just...they don't do it for me. jai, or whatever it ends up officially being called actually does so far. but, it's indev and under closed beta. that leaves me with JS because it's quick and easy to setup [sometimes] and i know enough to usually make it do what i need done..eventually... but, oh how i hate it... stumbled upon jon's rant about C++ and have been loosely following this since. rarely i can say i legitimately look forward to something. pretty used to disappointments by now...
@championchap then, i challenge you to write an image filter in pure javascript. you must process a pretty large image. assuming you can do this once without a hang/crash, do it in a loop. this must be done on a web browser. good luck. also, no web assembly, no service workers. now, assuming you can manage that, do it on a low [even obsolete/potato]-mid range consumer-grade PC. i fully expect you will fail this, i've attempted this sort of shit before. JS is too slow to be practically used for this purpose. C, C++, Java, Flash ActionScript would not only be up to this task [maybe not in web browser] , but they would be able to do it on significantly older hardware/software. maybe there'd be framerate drops, but fully locking-up the system or a container software layer is unlikely as long as the system isn't excessively under-spec. languages, even interpreted ones that are actually intended for large software development, would be up to the challenge i present. furthermore, they would be able to do significantly more. even a single-threaded solution would manage this. many of JS's "improvements" are feeble attempts to monkey-patch an ancient scripting language for use in more involved applications. each has failed miserably, but no one can complain when the alternatives, at least for web, were eliminated. javascript can be used to create large software, but oh no, it's not intended to. it does better when running small scripts and utterly shits itself when asked to do anything else. if it didn't have access to native code, many of its features either wouldn't work or wouldn't be practical. if it didn't have access to the GPU via webgl, many graphically demanding programs [especially games] could simply not be made. service workers are a similar issue, JS is so bad at doing complex work efficiently that you borderline need them. then there's the frameworks. all proper programming languages have this in common : everything mentioned here, is by default, optional. in JS, it's essential. and that's without mentioning some truly awful/disgusting hacks that in JS, are also, quite necessary, though you mostly are free from touching those. i genuinely like very little JS has to offer. currently porting code to haxe so i can one day cross-compile or even abandon JS altogether. i like web games and web apps, i hate making them. modern "open" web killed any joy i'd have had in it. JS is an abomination, a monstrosity that exists in its current form for the sole purpose of justifying the not universally appreciated removal of existing tech that implemented nearly all of these features, and arguably implemented them better. the way it is currently used serves only to bury and abstract-away some fatal flaws in our systems and design processes, and that is quite appalling. i pity the generation left to maintain/fix the mess of future legacy code being generated now.
what an amazing time to be alive to watch you create a robust language Jonathon! Thank you for being such an incredible source of reliability in the field. Im a high school computer science teacher and have learn so much from you that I will be able to pass on in small pieces to my students.
Hi, I wanted to say that I really appreciate how much thought you put into this language, trying out and scrapping concepts as your knowledge of them develops. This is especially awesome, since it focuses on things mainstream languages don't and the start of a new language is a great opportunity. I really look forward to the language and I like the trend of going away from OOP to DOD
It is important to have robust set of default warnings because it will help beginners to google them. In that sense it would be even better if custom checkers build off the default one so the basic error/warnings will have the same message.
When I first found out about you creating Jai, that is when I first got an interest in programming. I have been chomping at the bit ever since to get my hands on jai.
I hadn't given project longevity much thought when doing JavaScript stuff, but yeah, npm might as well not exist 20 years from now. I think I'm starting to appreciate Yarn's way of doing it, where instead of node_modules it generates one compressed file with all the dependencies that you should push to your version control. Like that, if you have the workspace in 20 years, you don't need to install in order to run the code
As far as the other problems of package management culture, I dunno. I feel like it's inevitable given high-enough level code that users decide to write, that easy package stuff becomes necessary. If you delay it too long, you end up with the horrible horrible mess that makefiles are nowadays, and given how painful they are, users prefer to lay low on them. But if you neglect them now, you end up like Golang, with people complaining about it and the language quickly scrambling to pull one together once it's too late
That's one of the things I like with CMake + conan combo, conan might disappear or break compatibility, but then you can just get the libraries separately, and build everything, it's just more work than using conan. Of course, it's up to you to backup the libraries, whether with the package management environment (conan, npm, etc.) or separately.
i try not to touch dependencies except where i strictly require them. managed well without the packagers and all the CRAP that comes with them. makefiles and macros are still a pain, been transtioning to haxe so i can stop writing "this.someproperty" or "MyClassObject.prototype" millions of times. yeh, well, flash develop and/or the haxe compiler leave a lot to be desired. only use JS since flash isn't an option anymore [and i never learned how to use it properly] , i'm fine with mostly/entirely switching to something like jai to develop native apps. i only make "web" apps since it's somewhat fast [ignoring errors, browser crashes from accidental infinity loops, security features telling me "you can't do this, sorry", and js just being a PAIN to debug in general]
@championchap Negative. Not talking about yarn.lock. I'm talking about Yarn 2, which has negligible adoption rate because it sucks in other ways, but Yarn 2 has what it calls Plug'n'Play, which is a minified node_modules that you're supposed to check into source control, which contains all dependency code. Lockfiles have been around for a long time and npm does also have package-lock.json
I wonder if in your tutorial or documentation for the language you could explicitly specify the cost of each thing, so as to encourage noobs to be aware of the performance tradeoffs.
absolutely agree about the modules design (local copy at that point in time you can modify not just using the system copy). Check in modules with source control. It is a good idea
I think the best simple idea of a non-nullable pointer is as a subtype of an Option type. The Rust way of doing this is more general, but the simple thing is to treat nullable pointers as an option type. Rust also has some optimizations based on nullability, so it might be interesting to look at how those work.
A classic Javascript project today is a total nightmare with a node_modules folder that is bigger than a black hole with dependencies all over the place. I miss the days where my code was in a small set of source files which is why I really enjoy coding for old 8 bit systems.
Yeah, the problem is nesting. Dependencies that have dependencies and can't guarentee to share those dependencies so you have several versions of the same library deep in module hell. This is kind of a result of JS being so simple that everything has to be a library. But afaik Jon has problems with c++ having everything and the kitchen sink included? I dunno, it's a hard problem but for pet projects you can frequently roll your own simplified version and skip dependencies, and there's some cool stuff with tree shaking or whatever it is called that trims the library to just the parts you're importing. I have no idea what Jons idea to solve the problem is though, sounds like what every high level language already does.
it's possible, though painful/chaotic in a whole 'nother way to bypass using node/NPM and most/all of its dependency black hole. that's what i've been doing. and i only deal with THAT nightmare since i have NO desire to touch C++ or its toolchain. [and my uses luckily usually don't NEED to be super-performant, still it's been an issue a couple of times] i spend too much time writing boilerplate T-T ,but guess that beats makefiles and downloading literal GB of packages before i could create a "hello, world". that said, you're right. and a good part of this is corporate suits or their brainwashed servants/shills pushing so hard these technologies. so much CAN be done WITHOUT even adding a single third-party dependency. also to some extent you have browser vendors regularly failing to comply with the standards or the API just being too painful, so you use someone else's solution then. i wish i knew enough and had enough time to do it, because good god does the idea of messing with these primitive systems sound so much more fun and simple. and this despite the fact there are some pretty tricky bits in there to make games/software work properly. what do you make for those systems? i just [for now] watch videos about them or new software people made for them, and a few things about how they worked, including specific implementations. also watched ben eater's "hello world, from scratch" videos, which were really fun and educational, not that i have any of the hardware/tools to actually build it.
Generally with a package manager you can just let the community manage module best practices. Sure the average user might use the big clunky general purpose library. But the thing is that as the skills of the programmer improves they can make more decisions to use more specific libraries for their use case. Generally if you just give a community the tools to decide what they want it results in the most useful or helpful system.
There are ways to make pseudo-closures that can be solved at compile time (I know they do this with inline functions in kotlin). They would work kind of like a macro. It would be good to have something like this. But maybe that could also be let to meta-programming modules
1:38:10 "I am not going to talk about far away unannounced features because when I do that what happens is other people copy them for their stuff". The grandmaster with his ingenious ideas has spoken.
8:06 NPM doesn't use semantic versioning? I haven't used JS in years, but that would really surprise me. Devs don't have to maintain an interface forever, they'll increase the major version and break compatibility. I doubt NPM would just update a package on a major version change, but I might be wrong. I know cargo wouldn't.
Yup, and you can do the same with Composer for PHP, commit libraries to your VCS. I do that at work because I don't want a deploy to fail because of external deps.
Regarding documentation on timecode: 1:29:56 , I think a classical wiki is not a good idea. Would go for a way of "documentation that compiles". Something like an enhanced-wiki powered by a Jai compiler on the server. So, when the doc/code is modified, the person writing it could run a compilation. And the “enhanced-wiki” could have some flag that would inform if it compiled or not. That way would allow to embed documentation with code that compiles. Extending it a bit more, the enhanced wiki-thing could check that what is documented runs successfully. So, it should have a way of indicated some expected results that are checked against the sample doc/code execution. An another flag that would show that what the sample code/doc runs, complies with the indicated expected results. That last extension matches the unit-testing approach. Jon commented about unit-testing and TDD here: ruclips.net/video/21JlBOxgGwY/видео.html Which I mostly agree with. In my experience, unit-testing is very valuable if used diligently. Worked in railway signaling software for electronic systems and unit-testing was a must.
I'd love to be in the beta, but considering how little bandwidth I'd have for playing with it, my potential slot would probably be better used by someone who does have the time.
I don't understand why that thing is not just in the open, so that everyone who's interested can follow the development without having to feel guilty about "occupying the spot of a more deserving individual".
@@EvenTheDogAgrees So that Jon can actually handle the feedback that comes in directly in a focused manner, and so he can select for people who he actually wants to hear direct feedback from. To go in open beta would require more consideration of how to collect and process feedback. Also, because key features that he thinks should be in the open beta like the modules system aren't in yet, like he said in this video. He doesn't want to launch the language to the wider public (even if it is just beta) if key things that would make it work at scale aren't in yet. At least, that's an approximation of what he's said in the past. Don't take what I say as the full truth.
I would love to try out your language as soon as it becomes available! Likely, I will stay with C++ (with modules) because of industry standardization and support. But the first time I saw one of your videos about JAI I thought - "I want to use this for my own engine". Maybe that's too early for next couple of years, but I'm certainly very curious. Especially if you can manage to adapt the C++ philosophy of providing only light-weight abstractions but not limit the user too much in expressiveness. Anyways, great work - it's looking really good so far!
Systems that automatically download dependencies at build-time usually use a versioning system called Semantic Versioning, which by default only installs only bugfixes (patches) and API additions (minor versions), but not anything that changes the public API (major versions). There's something to say for it.
What's the timeline for Open beta? As someone coming from enterprise programming, I would love to do some low-level programming in a modern language again.
npm is both amazing and terrible at the same time. Amazing in that we can all easily just install packages to help us develop things very quickly and get updates for the modules we're using. Terrible in the way that it's a billion files and if you ever by some reason copy the folder, you'll be waiting for quite awhile and it'd do tons of reads/writes. Also when some vendor changes things and therefore becomes incompatible with other packages. Things become less fun.
that is why i hand-pick only ones i really need (one being zlib because i just don't feel like re-implementing deflate or ANY compression, another datastream because it hides a lot of those "read/write data from/to THIS offset" annoyances and remembering to specify endianness with EVERY read/write) and very carefully watch-out for extra dependencies or that accursed "you need node/NPM". downside is i spend a painful amount of time writing boilerplate because the default APIs are useless right out of the box. it's 'fun' ... T-T [yeh, this language can't be done fast ENOUGH.] i mostly try to ignore package.json tbh. at least in the more sane libraries (aka the ones that work without touching a packager/manager/compiler of any kind), you don't need it. but yeh, pretty stupid. this trend also exists in non-minimized script files and can also be seen in certain C/C++ source code, too... also, OOP by default. all those imports which usually eventually result in "i/you should just write import* or import package* and save yourself a lot of time/hassle". ofc, i say 'try' to ignore, i still read it... /: but in the end, i pluck the libraryname.min file out of the folder, put it in my project, make sure the docu/demo page is ready, and use it without thinking about node/npm or the package.json file. and it's wonderful. p.s. another 'favorite' JS trend of mine "how do i access/manipulate the DOM?" and the answer: '$("myelement")' jquery has a place, but i'm glad i learned of document.getElementById() [among others] because that's a massive amount of boilerplate to call just to use one function that's already built-into JS natively. regrettably, i have some older code that does the "use jquery to do ONLY this basic thing". that, however, uses libraries that... yep...need jquery. at some point, i MIGHT finally eliminate it from the dependencies once and for all. [one MIGHT work with the semi-stable CSS3 now, since the whole reason i added it was to stylize a scrollbar...ouch]
OK closures require going from the stack to the heap if you return them as values so I can see the speed argument there. But you can have a limited type of closures that you can't use as values and so don't have to move to the heap, gcc calls them nested functions (it's a GCC C extension). I've found those to be very useful. Can we have those? And yes, I understand that for small ones you can just use macros (or inlines whatever you call them -- if you can capture variables from the lexical scope? or are they hygienic so you can't? dunno) but that kind of copy-paste is not feasible if they're big or they have many call sites.
@@skepticmoderate5790 so what happens when a closure is returned from the function in which it was declared and the variables it captures go out of scope?
@@UGPepe It depends on how your language handle them and on whether you captured variables by value or reference. If by value, there is no problem, closure contains copies. If by reference, you are in trouble )
@@IsmeGenius yes, I suppose you can have either closures that are first-class objects but without shared captures (every closure has a copy as you say), or nested functions that can, but can't be first-class objects. I think both are useful in different ways and good to have. In any case, you can't have real closures like in Lua because that would require heap and gc which is out of scope for Jai. Personally, I think the future of programming languages is where you can have both low-level and hi-level primitives in the same language and they are well integrated. Every complex program today has an embedded scripting language but they have different runtimes and integrating them adds a lot of needless friction.
Libraries are not a problem in C++, the actual problem is the low quality of them. In many ways library development has been "outsourced" to random open source people who create something and then everyone just have to live with it.
NPM is a disaster, but the Web (proper) has ended up close to an ideal situation for modules. Small, self-contained and purposeful libraries, served from a cache that falls back to a content delivery network, avoids most of the problems associated with standard libraries. If everyone went through an API that redirected cache misses to a CDN, you could potentially switch to a different CDN without breaking anything. As long as you know which file is which, you can get those bytes from anywhere. You could also drop the cache, and use dependency management to fully determine what needs to be kept around. Users should also be able to try apps (and libraries) without (persistently) installing their dependencies. Standardizing half of your ecosystem (in perpetuity) is obviously going to retard its evolution and undermine adaptation. > The Python Standard Library is where modules go to die -- Kenneth Reitz
I wish open version will not come out in too long. So I could start playing around wish lower level language than I currently use. Although on the timeline it seems I would need to start playing around with C
21:30 Is shadowing really useful in programming languages? I feel like it should just be an error. It's just something that can cause hidden bugs but many languages allow it. Is there a good reason?
It's nice having the freedom to reuse the names when you want to. I can imagine getting irritated by the compiler errors, but you've got a good point. I really enjoy golang despite its compiler being quite strict with these types of things (can't compile if variable is unused etc).
Shadowing should be error in dynamicly typed laguages, but in static? If the types doesn't match compiler should not even copile code and let to it execution. Rust has shadowing of variables, those variables can even have different types after shadowing. But if you try to use wrong type with some function call you will get compiler error preventing code compilation and potential bug.
yes, I hate the guts of languages that don't have that, and no offence but I think people who don't understand that haven't written enough code to understand the trade-off and they side to the way of safety by default not because of their own experience.
@@fmease As I willfully interpreted the section, jai encourages s64 ints and therefore that is the type used for things like array sizes and indecies. Rust requires unsigned for those things. The stuff I wrote in rust had a bunch of into s and try_into s because I needed subtraction of counts and stuff to give me negative values. In C, my only use of unsigned is bittwiddling. Otherwise happy to avoid unsigned.
`let row_remainder = self.row_hints[iy] - isize::try_from(n_row).unwrap();` `let iy = iy_list[usize::try_from(invalid_cell_idx).unwrap()];` `let col_count: isize = col_x.iter().filter(|cell| cell.state == CellState::Flooded).count().try_into().unwrap();` And the like. A lot of friction compared to if everything was just signed. I don't value the compile time invariants unsigned types provide.
@@linkVIII I'm surprised that Rust made that mistake after it turned out to be a clunky solution in C++, where std::size_t is unsigned. Like, we don't need the other 9,223,372,036,854,775,807 values, we need basically intuitive subtraction semantics without tons of warnings no one should have to care about. In fact, if the values get that big then it's nice to state that by using std::uint64_t explicitly.
@@lm1338 Rust's reasoning with unsigned is that it eliminates < 0 checks for array access. It does make some hassle with arithmetics, but not to the point of linkfviii post, it just has different types everywhere for no reason. Also, one can use `as isize` for vector sizes/indexes. It will loose on panic semantics, but with the argument that u don't need unsigned for arrays, they will never be big enough too case overflow.
Is it just me or does this language sound a whole lot like LISP with types. All this discussion about meta compiler setup really makes me feel like the expectation for this language is to define the language per usecase.
It borrows a lot from other languages and makes some new stuff of its own. It's similar to C since you have very fine control over memory, but it also has many features that interpreted languages do like polymorphism and metaprogramming. It's a beginner language in terms of giving you a lot of control and flexibility over how you want to do things, but that also means it let's you mess up in many ways. It does have better error messages and how-to's than most languages which helps a lot, but the main aim of the language is to allow good programmers to perform to the best of their ability. The analogy he uses is that you shouldn't put adults in kid gloves just because the kids need kid gloves.
@@mosesturner4018 True, but he does not have to pretend to be someone who takes public PRs or something. I just wanna fuck around with the language because it seems super interesting. I also am interested in seeing the IR evaluation.
He had a copy-cat problem with even just doing language demos. Making the source widely available would allow it's momentum to escape him, and would let copy cats create jai-lite languages crowding out Jon in his own niche. At some point the project will grow beyond Jon and would likely be open sourced at that point (languages without open source tend to not generate momentum [conjecture]).
Why would you allow returning blank variables (underscore)? To my understanding it's more of a hint to the compiler: This is the syntax I mean but I don't actually need the value, say you're unpacking a tuple and only need the first value. foo, _, _ := (some, tuple, values); // I don't know enough about Jai syntax ;-) Returning _ wouldn't just be weird but basically impossible.
Hello Jonathan, I know this may seem as a weird question (it's also highly speculative) but is the Jai programming language named after Randy Pausch's wife as an homage/tribute to Randy and his legacy ?
Do you even need the "mode" for the allocator function? If you had old_ptr, old_size, new_size then isn't that enough? If new_size is 0, then it's a free (of old_ptr, with size old_size). If old_ptr is null then it's a malloc (old_size ignored). If old_ptr is non-null and size is non-zero, then it's a realloc. Isn't that unambiguous?
The enum being there is an artifact from earlier when there were more options. It's worth thinking about removing it, but the options you give above are not unambiguous ... for example a realloc to size 0 should not be a free, because the code will call free on it later and that needs to work. But since the arguments are signed, it could be -1 or something.
@@jblow888 Well if you're calling it with size zero and updating the pointer with the returned value (as you would for a realloc), then it'll get freed and the pointer will be null, so free later will be a no-op. But more importantly, I was suggesting that this call with size=0 _is_ the free (there's no separate free call later). It's a somewhat common trick in libs to let people provide their own allocators by just providing a function pointer to realloc, since this function can do both malloc, realloc and free depending on the parameters. In your case it would be a modified realloc because you also want to provide the allocation size to the free and realloc cases
About the SIMD intrinsics, I use them a lot (much more since MSVC removed them from 64bit compilation) and for most uses I would actually prefer to go back to inline assembly. The intrinsics can mix more easily with other code (without the compiler having to be needlessly pessimistic) which could be good for some "micro-use" of SIMD like in Swiss Tables, but that's about it. The main use of intrinsics is in heavy loops that are 90% SIMD anyway, not a lot of mixing. I don't buy the arguments that intrinsics are easier: they look absolutely terrible (worse than the assembly instructions they represent), and working with intrinsics requires a lot of work to poke the code until the compiler is "happy" and generates the right code (if it ever does). With inline assembly (or out-of-line assembly, but I don't like having mixed languages in a project, with extern function declarations that aren't kept in sync with their actual definition, and the weird build configuration etc) I can just write the right thing, without having to appease a stubborn compiler.
Did someone from the beta ask Jon why he always refers to the language as "the language" or "this programming language"? Any progress on the final name?
I'm expecting this project to end up as python 4.0, with explicit typing and non-garbage collected mode available through with-statement, and option to compile into C.
I personally find it strange that web doesn't do compression/compilation. You'd think with limited network capacity you wouldn't want to be sending data for whitespace and variable names and all that through javascript/html. I just find it confusing how much of a general waste there is with network traffic.
@@hasen_judi it really depends on the build system but yeah I've definitely come across systems where the javascript is minified. I just find the whole web interesting. Would we better off with some kind of universal bytecode like Java or C#? Or does javascript actually provide (albeit slow) but terse expression of operations (operations per character).
@FichDich InDemArsch That's true, and V8 is a marvel in optimization, although I'm pretty sure they meant bytecode over-the-wire to have smaller bundles. It's what WebAssembly does, but of course, that's not JavaScript :P
@@Dorumin Even with wasm the parent wrapper of the binary is javascript unicode characters. Its not like we send binary directly to clients screens. We have to create the running context and hand the wasm to it and all the rest with html dom object construction etc. Plus. Wasm is a relatively new technology.
As far as I understood it a while back the beta was for people that Jon and buddies/employees personally know. Which is why he mentioned maybe moving to a system where beta testers get invite codes to give away, which reminds me of how certain private torrent trackers work.
I'm definitely looking forward to the day I can get my hands on this language. Do you have any recommendations about things to read/watch/try out while we wait. (Apart from your talks and you stream of course)
how do you handle servicing of 3rd-party dependencies? let's say the jpeg lib you're using has a buffer-overflow that's being exploited in the wild. being able to handle this in a sane way implies having a system that understand semantic package versioning.
Jon, do you plan on adding interfaces at any point to language? While inheritance is extremely problematic and I avoid it at all costs (except for code I can control, there I use it if it feels beneficial to the structure), interfaces are awesome. You can't break an interface (local copy will take care of removed functions and there is no third-party low-level code you rely on) and you can't accidentally forget to override smth you have to or have some left over functions you kind of hope nobody uses (like one infamous java error with stack extending vector and having vector functions leak memory, because they are accessible, but don't know about additional stack properties). Also, they are great for library designers. I can safely add or remove anything I want and I honestly don't care about the end-user. I don't consider behaviour you can get with some smoke and mirrors (like C11 "inheritance" you can get with anonymous structs) to be a "core feature". I talk about real feature that is part of the intention, not a useful byproduct
For engagement of new people I'd suggest you give some context. 3hr long video without name, description, background, links. I might be interested, but without any brief and info I'm not gonna be wasting 3hrs on this. :(
Are there any other programming languages where folks involved in the creation/maintenance of the language ever even talk about being able to run some software in 20 years, with zero maintenance?
Common Lisp? If we are talking about compiling software on then-modern-platform one of the problems with is that you need to try to abstract many OS facing things (like file system access) and I feel like Jon would be against that.
@@digitalspecter If I search for “common lisp old programs” I am not left with the impression that there was any particular effort to make sure lisp programs were able to be run decades later. I wasn’t able to find examples of programs that can be run today, that had dependencies besides the interpreter itself, for example.
@@Ryan1729 The cpp comitte supposedly recently discussed whether a new feature should be included or not because some pcs from the 90s wouldn't be able to have fully conforming implementations then
@@user-sl6gn1ss8p That sounds like the opposite of what I care about: I want to be able to run software 20 years after it was written and beyond. Whether some code works on a machine from 20 to 30 years before the code was written seems a lot less important. I mean hearing about someone getting some modern language to compile down to say, a 6502 is cool and all, but I'm not sure who is actual expecting that from their programming language.
@@Ryan1729 well yeah, but I do think it goes both ways. Code written in Cpp on the 90s or early 2000's should mostly still work on current pcs. C, even more so. Fortran is just now being phased out on CERN I hear. Really it mostly comes down to compiler support: if the architecture of pcs change drastically than you'll need people willing to adapt your language to that, I don't think there's much dancing around this
1:38:10 "I'm not gonna talk about far away unnanounced features, because when I do that what happens is that other people copy them for their stuff." Is he that afraid to lose a tiny bit of fame to other developers or is Jai supposed to be closed source and propietary?
Jai will be closed-source at first, then open-sourced at some point down the road (my guess is that right as the compiler gets bootstrapped, it'll go open-source).
it makes sense. same reason i don't discuss too much about my unannounced game stuff. there are people who'd pounce on the opportunity to do it before me. in fact, it's happened a few times to me this exact thing happened, just not for code. that left a sour taste in my mouth. it'd be disastrous for something i plan to make money or game recognition from. also, some people who'd do this literally ONLY for money or fame may well half-ass the implementation. then you have companies like microsoft that can and will do shady things to stay-ahead of [potential] competitors. makes sense to me. also, that can lead to scope creep issues because then everyone wants it done yesterday. (thanks corporations!)
@@nickeshchauhan5661 Yes I finished everything, and it was amazing. Assuming the witness was perfect and everything has been done is ignorant IMO. I just want another out of the box thinking puzzle game.
Your whole spiel at the start here is literally no different than how NPM and Yarn already handle dependencies. They get pulled into your project, but you don't need to commit them into version control. You can do so if you want, however. Similarly, all package managers support locking down versions to majors, and updates aren't automatic, they are explicit. Why do you keep bashing systems you've seemingly not used?
@@jac1011 I've listened to enough of his talks to know he often misrepresents other ecosystems and often creates problems out of thin air. I'm not a fan of these ecosystems to start with, but he misrepresents them time and time again. It's incredible honestly. The problems he discusses in the first fifteen minutes here almost all package managers solve. It's not as if nobody has ever thought of escrow or mothballing projects before. It's just that it's not needed for a lot of projects; particularly when in development; so it's not the default.
@@SK83RJOSH It seems you're misunderstanding most of what I am saying. You are talking about options and things that can be made to happen; I am talking about culture-building and things that will happen by default if nothing is overridden (thus will happen most of the time). I strongly dislike package management culture, and am talking about stuff that I have experienced going all the way back to CPAN. You seem to be invested in making hostile interpretations of everything I say though, so, I mean, you do you, but can you not bother me with it? Thanks.
Maybe I’m incorrect, but what I have seen with many package managers is that often they install binaries and not source code. So if the pc architecture changes and you didn't download the source code, in 20 years you may be screwed, because you depended on someone keeping the source online for you. Of course, you could also just copy the source code of the site, but this isn't the default. (and for many applications for good reason, to avoid bloat) But we have to remember what Jon's language is about. Making standalone games. (I could be wrong, but it's kind of like making app images) It has to compile on various architectures without having to worry about internet connectivity. And here is the kicker, you can copy the source code directly to ensure that your code will compile safely 20 years from now, you always could. But people don't, and that is the cultural issue. Maybe a JB package manager just downloads source, and places the source directly in the project directory, it would avoid most of the issues he seems to be concerned about. There would be storage trade-offs, but i get the feeling It's not his main concern
Instead of coding the compiler yourself, can't you just flow chart the whole architecture out first, that way people can see the big picture and are on the same page?
@@hasen_judi Well!! thats how it works in my company because we have to do a lot of custom stuff and work with a lot of fussy clients , its freaking annoying doing it but it pays off big time. I hope your not one of those gun ho coders that makes those monster Classes that have Classes in Classes! lol! joke
@@larrybird3729 I don't work on this compiler so I can't speak on Jon's behalf, but there are many live coding sessions on this channel, you can take a look to see how Jon works.
That's just gatekeeping and it doesn't even work.. especially seeing how profit-driven development is so often the source of stupid quick hacks that never get fixed..
0:00 Introduction
2:20 Roadmap for the next few Beta releases
3:30 Upcoming module handling improvements
18:53 Upcoming default metaprogram improvements
23:40 Start of the Beta user Q&A
25:50 I can see that you can change the allocator on a context by changing an allocator (a function) and allocation_data. For allocators that allow individual allocations to be returned how do you specify the equivalent of free() to the context? Or don't you?
31:14 How do you configure the compiler to build a Jai library for use on Android/ARM64?
33:53 What made you shrink the compiler team back to just yourself?
43:46 How are you feeling about how the beta is progressing? Do you have an idea of how many more times you want to expand the closed beta, or roughly when it might go into open?
46:43 Would you prefer us to report bugs asap, or wait and bundle up a few at a time?
47:46 I like the monorepo/project approach for modularity, does it conflict with your earlier statement that compilers/languages are underspecified in many regards? Should metaprogramming fill all those gaps?
50:09 Why not closures? What are the alternatives to closures? What can we do in the language that is equivalent to what closures provide?
56:34 You often talk about how syntax is not definite right now, is there anything that you are seriously considering changing in the future?
58:58 As with standard modules, could there be standard metaprogram modules, which could be included to enhance build processes and such, for instance to impose common house rules
1:01:31 The question of what is standard library vs external stuff keeps coming up; how are you aiming to delineate it? Would a "batteries included" approach covering most of the everyday stuff not provide a reasonable amount of value? Relatedly, "Basic" is a bad name for a module, as it's fairly arbitrary and different from one person to another what counts as "Basic"
1:05:56 Are there plans to add build-in support for code hotloading for running executable?
1:07:24 I have a big change for the built-in hotloader module that fixes its totally broken linux part but these fixes need to change the API slightly. Do you want such bigger changes for built-in modules?
1:15:00 You mentioned that struct literals are new which explains some of my issue but what are your current thoughts on allowing non-constant values for struct literals?
1:19:00 I couldn't find classic C-style for loops anywhere in the docs, did I miss something?
1:19:43 Have you thought at all about array-programming?
1:20:11 Currently, a 'for' loop over an explicit range (e.g. 0..3) disallows use of 'it_index'. Would you consider allowing this in the future? This would reduce friction when, upon code maintenance, the explicit range is replaced with an array whose index needs to be tracked
1:20:57 Can we get a `sockets` (or `Networking` module)? Seems like it should be in standard library
1:21:32 Currently, the single underscore, _, can be used as a variable (like in C). Do you intend for this behavior to endure, or are there plans to change it to function as a blank identifier like in Go?
1:22:40 Are minor contributions to the existing documentation (like typo fixes and small content additions) welcome?
1:23:59 To align a big team on a project it proved useful to me to restrict certain features of the language. I understand that I should write a meta-program to fail on features I want to restrict.
1:24:55 Patrick had a question a couple days ago about trying to modify parameters to functions in a function, in external libraries this is possible but within a Jai program it's not. This confused me a lot early on as well. Perhaps this could be clarified in the how_to's (pass in a pointer...)
1:27:28 Something slightly confusing is dependencies between metaprograms. When two metaprograms share common namespace that they might both want to change you might get a dependency that doesn't really exist.
1:29:56 Are there any long-term plans about documentation, in terms of format and scope? I really like the current how_tos. But I imagine there is a large amount of work to do with documenting the distributed modules and language features. Maybe more people could help out with that?
1:33:14 What plans do you have for extending the procedure/declaration notes stuff? Specifically, I work on a team of ~20 people and issue tracking/project management tools like Jira which are separate to the code are a pain, maybe there's a way the language/metaprogram can help?
1:37:59 Do you see any places in the type system where things could be added to make robust parallel programming easier?
1:40:05 Any plans to move the temporary allocator to the context so we can change the way it works if we want to?
1:44:12 Threading is currently based on function calls; is there no interest in tying thread functionality more tightly to the language in ways that makes it easier and more natural?
1:47:47 Are there plans to add complex numbers or 16-bit half precision floats?
1:49:30 I've been using Visual Studio to debug programs and its been very good. But just wondering the current status on debugging with other tools, and what are the plans for the future?
1:51:00 Will you be releasing a recent game you wrote using the language when it's publicly released? The demo games that come with the compiler are great but the invaders example is quite old and I imagine you might be writing things a bit differently now
1:55:10 Will you add the `f32` and `f64` type aliases for consistency with other shortened types?
1:55:57 I'm porting a program from c++, which I understand is more liberal about implicit casts than this language. And one of the most common compilation errors for me are type conversion-related by far. My current impression is that the language seems to push you to use the default s64 integer type for numbers as much as possible, and only rely on smaller/unsigned numbers if necessary. Could you talk about how this decision was beneficial for you so far, and if it's been difficult to think harder about explicit type casts in you game's large codebase?
2:01:22 What are your plans for the future of the LLVM backend? On one hand its a dependency that would be good to not have but I'd be afraid of losing support for all the targets they already have.
2:04:07 What are your plans to handle language stewardship after it is public? Will it still mostly be a one-man show or will you focus on other things and delegate, while still helping to maintain the language's direction?
2:05:00 How likely is that Jai ever runs in a 32-bit system? (Thinking about embedded, maybe older hardware, etc)
2:09:25 There's a class of problem for which compile time metaprogramming is very useful, but for which you don't necessarily want to spend the time at compile-time every single time you compile your program (say, bindings for external libraries...). Have you thought about building more code generation/caching of compile-time results into the compiler or included modules? Something like a stickier version of .build/.added_strings?
2:13:45 Do you have plans for a Jai Foundation or similar to maintain the language?
2:14:10 Does the LLVM auto-vectorize anything currently?
2:14:52 What are the plans for intrinsics?
2:16:35 Do you plan on releasing a memory safety metaprogram in the standard library for the public release? (Like an optional, less-restrictive Rust borrow checker)
2:20:57 What is the current status and/or your view on dependency injection and compile time arguments for libraries. You had a talk about libraries a long time ago but I haven't heard as much since
2:21:40 Would you be open to do macros that are more friendly to pass in #code parameters?
2:23:25 I've been keeping notes about what I've thought about the language as I've been learning it, figuring to write it up further down the line when the compiler had stabilized somewhat. Is that preferred, or would you rather get feedback right away?
2:24:33 Have you considered adding annotations to other things besides just declarations? I would like to, for instance, be able to add an annotation to parameters passed to a function. This could be used to package your parameter to the function at compile time
2:25:45 What's the current compile time of the game?
2:28:07 Have you considered a command line option to swap between release and debug builds. I use Jai for a lot of small one-file programs that it's not worth fiddling with build_options. This is the main option that I'd like to be able to modify quickly
2:28:48 Even though Jai's philosophy is a lot about recompiling the code, it's very natural that a lot of companies will want to release libraries instead of the source. Are there any plans regarding libraries built in Jai? Any ideas on how that will work?
2:32:20 Time for a compilation is already (that I know) the best for a language of this kind and this level of features. You mentioned that there are still improvements to be made. What are the next things to tackle regarding this? How much of an improvement do you think is achievable compared to the current implementation?
2:36:50 In order to support IDE diagnostics it would be useful if the compiler reported all errors instead of the first error. Is there a plan to support additional error reports from the compiler?
2:39:01 Do you think it'd be useful to know what stuff is taking most of the compile time? In the same way we warn about structs having too much type info. Might be cool if we'd warn for things like, "this #run directive takes up 50% of your compile time"
2:39:45 A while back we discussed about using this language kind of like a scripting language (i.e. no entry point, doesn't produce output), but it still has some overhead to set it up. Any plans on improving this?
2:42:41 Start of the open Q&A (Twitch chat, not Beta users)
Still really excited for the day this goes into an open beta.
yes!
Still waiting 😊
Very exciting to see this language being developed.
I'm so happy that this project exists.
Really appreciate the preamble - the core goals you've laid out sound extremely appealing. I especially dislike the headaches that come with trying to build various projects, which often can't be done easily because of the slew of incompatible/outdated dependencies.
incompatible/outdated dependencies are extremely frustrating and distract from the initial task you set out to achieve. I'm with John Blow, i just want to be able to use a computer to run a program.There is room for the ideas John expresses.
@@m.p.jallan2172
yep... as many have said : assembly is more appealing in ways. there's just you, the CPU, and the other hardware. your code works or it doesn't, maybe it crashes. modern stuff just isn't that simple. it's especially bad in web development. [and FORCED on you since third-party or self-made, it's almost impossible to develop for web without boilerplate since the stock APIs are so half-assed]
just running a program, what a novel idea! it's not like this is literally WHAT we developed the computer to do or anything...
[seriously, good GOD am i tired of fighting with my software to make it do what it's actually supposed to do. my experience as an end-user and as a developer progressively becomes more and more absolutely MISERABLE.]
i really hope this works-out. i won't touch the C family or its toolchain because they're difficult to use and full of flaws. [plus dependency hell...] JS also sucks massively. i never WANTED to use it. it was never INTENDED to write large programs with. also looked into some other native languages. [also python, java, and i WAS planning to do flash when i actually could properly learn how to use the IDE and program actionscript] they just...they don't do it for me. jai, or whatever it ends up officially being called actually does so far. but, it's indev and under closed beta. that leaves me with JS because it's quick and easy to setup [sometimes] and i know enough to usually make it do what i need done..eventually... but, oh how i hate it...
stumbled upon jon's rant about C++ and have been loosely following this since. rarely i can say i legitimately look forward to something. pretty used to disappointments by now...
@championchap
then, i challenge you to write an image filter in pure javascript. you must process a pretty large image. assuming you can do this once without a hang/crash, do it in a loop. this must be done on a web browser. good luck.
also, no web assembly, no service workers.
now, assuming you can manage that, do it on a low [even obsolete/potato]-mid range consumer-grade PC. i fully expect you will fail this, i've attempted this sort of shit before. JS is too slow to be practically used for this purpose. C, C++, Java, Flash ActionScript would not only be up to this task [maybe not in web browser] , but they would be able to do it on significantly older hardware/software. maybe there'd be framerate drops, but fully locking-up the system or a container software layer is unlikely as long as the system isn't excessively under-spec.
languages, even interpreted ones that are actually intended for large software development, would be up to the challenge i present. furthermore, they would be able to do significantly more. even a single-threaded solution would manage this. many of JS's "improvements" are feeble attempts to monkey-patch an ancient scripting language for use in more involved applications. each has failed miserably, but no one can complain when the alternatives, at least for web, were eliminated.
javascript can be used to create large software, but oh no, it's not intended to. it does better when running small scripts and utterly shits itself when asked to do anything else. if it didn't have access to native code, many of its features either wouldn't work or wouldn't be practical. if it didn't have access to the GPU via webgl, many graphically demanding programs [especially games] could simply not be made. service workers are a similar issue, JS is so bad at doing complex work efficiently that you borderline need them. then there's the frameworks. all proper programming languages have this in common : everything mentioned here, is by default, optional. in JS, it's essential. and that's without mentioning some truly awful/disgusting hacks that in JS, are also, quite necessary, though you mostly are free from touching those.
i genuinely like very little JS has to offer. currently porting code to haxe so i can one day cross-compile or even abandon JS altogether. i like web games and web apps, i hate making them. modern "open" web killed any joy i'd have had in it. JS is an abomination, a monstrosity that exists in its current form for the sole purpose of justifying the not universally appreciated removal of existing tech that implemented nearly all of these features, and arguably implemented them better. the way it is currently used serves only to bury and abstract-away some fatal flaws in our systems and design processes, and that is quite appalling. i pity the generation left to maintain/fix the mess of future legacy code being generated now.
what an amazing time to be alive to watch you create a robust language Jonathon! Thank you for being such an incredible source of reliability in the field. Im a high school computer science teacher and have learn so much from you that I will be able to pass on in small pieces to my students.
"I'm not a giant named kayne" well damn there goes my main theory for who jonblow really is
what refernece is that? to kanye west?
I think I heard him say "I'm not a giant ego like a [certain] kanye"
@@JakobWolfMinigolf Dungeons & Dragons & Bitches skit by Key & Peele
The stream was falling down too often, glad the vod is here
Table of contents!! thank you Jon
start a comment with timestamp toc
Hi, I wanted to say that I really appreciate how much thought you put into this language, trying out and scrapping concepts as your knowledge of them develops. This is especially awesome, since it focuses on things mainstream languages don't and the start of a new language is a great opportunity. I really look forward to the language and I like the trend of going away from OOP to DOD
@FichDich InDemArsch aha
It is important to have robust set of default warnings because it will help beginners to google them. In that sense it would be even better if custom checkers build off the default one so the basic error/warnings will have the same message.
This Q&A was awesome as always. Thank you for doing this, even without ads.
When I first found out about you creating Jai, that is when I first got an interest in programming. I have been chomping at the bit ever since to get my hands on jai.
How should I learn to code?
Great talk again. Excited to see this being developed!
I hadn't given project longevity much thought when doing JavaScript stuff, but yeah, npm might as well not exist 20 years from now. I think I'm starting to appreciate Yarn's way of doing it, where instead of node_modules it generates one compressed file with all the dependencies that you should push to your version control. Like that, if you have the workspace in 20 years, you don't need to install in order to run the code
As far as the other problems of package management culture, I dunno. I feel like it's inevitable given high-enough level code that users decide to write, that easy package stuff becomes necessary. If you delay it too long, you end up with the horrible horrible mess that makefiles are nowadays, and given how painful they are, users prefer to lay low on them. But if you neglect them now, you end up like Golang, with people complaining about it and the language quickly scrambling to pull one together once it's too late
That's one of the things I like with CMake + conan combo, conan might disappear or break compatibility, but then you can just get the libraries separately, and build everything, it's just more work than using conan. Of course, it's up to you to backup the libraries, whether with the package management environment (conan, npm, etc.) or separately.
i try not to touch dependencies except where i strictly require them. managed well without the packagers and all the CRAP that comes with them. makefiles and macros are still a pain, been transtioning to haxe so i can stop writing "this.someproperty" or "MyClassObject.prototype" millions of times. yeh, well, flash develop and/or the haxe compiler leave a lot to be desired.
only use JS since flash isn't an option anymore [and i never learned how to use it properly] , i'm fine with mostly/entirely switching to something like jai to develop native apps. i only make "web" apps since it's somewhat fast [ignoring errors, browser crashes from accidental infinity loops, security features telling me "you can't do this, sorry", and js just being a PAIN to debug in general]
@championchap Negative. Not talking about yarn.lock. I'm talking about Yarn 2, which has negligible adoption rate because it sucks in other ways, but Yarn 2 has what it calls Plug'n'Play, which is a minified node_modules that you're supposed to check into source control, which contains all dependency code. Lockfiles have been around for a long time and npm does also have package-lock.json
Looking forward to a future open beta.
@@甘楽-t9l The closed yeah, that's why I'm looking forward to an Open Beta.
I wonder if in your tutorial or documentation for the language you could explicitly specify the cost of each thing, so as to encourage noobs to be aware of the performance tradeoffs.
absolutely agree about the modules design (local copy at that point in time you can modify not just using the system copy). Check in modules with source control. It is a good idea
I think the best simple idea of a non-nullable pointer is as a subtype of an Option type. The Rust way of doing this is more general, but the simple thing is to treat nullable pointers as an option type. Rust also has some optimizations based on nullability, so it might be interesting to look at how those work.
11:00 Sounds like what the kids today call "vendoring".
I'm 20mins in and so far he's reinvented node_modules & linters, c/c++ is truly a different universe (don't get me wrong, I'm a fan of JB)
A classic Javascript project today is a total nightmare with a node_modules folder that is bigger than a black hole with dependencies all over the place. I miss the days where my code was in a small set of source files which is why I really enjoy coding for old 8 bit systems.
Yeah, the problem is nesting. Dependencies that have dependencies and can't guarentee to share those dependencies so you have several versions of the same library deep in module hell.
This is kind of a result of JS being so simple that everything has to be a library. But afaik Jon has problems with c++ having everything and the kitchen sink included?
I dunno, it's a hard problem but for pet projects you can frequently roll your own simplified version and skip dependencies, and there's some cool stuff with tree shaking or whatever it is called that trims the library to just the parts you're importing. I have no idea what Jons idea to solve the problem is though, sounds like what every high level language already does.
it's possible, though painful/chaotic in a whole 'nother way to bypass using node/NPM and most/all of its dependency black hole. that's what i've been doing. and i only deal with THAT nightmare since i have NO desire to touch C++ or its toolchain. [and my uses luckily usually don't NEED to be super-performant, still it's been an issue a couple of times]
i spend too much time writing boilerplate T-T ,but guess that beats makefiles and downloading literal GB of packages before i could create a "hello, world".
that said, you're right. and a good part of this is corporate suits or their brainwashed servants/shills pushing so hard these technologies. so much CAN be done WITHOUT even adding a single third-party dependency. also to some extent you have browser vendors regularly failing to comply with the standards or the API just being too painful, so you use someone else's solution then.
i wish i knew enough and had enough time to do it, because good god does the idea of messing with these primitive systems sound so much more fun and simple. and this despite the fact there are some pretty tricky bits in there to make games/software work properly. what do you make for those systems? i just [for now] watch videos about them or new software people made for them, and a few things about how they worked, including specific implementations. also watched ben eater's "hello world, from scratch" videos, which were really fun and educational, not that i have any of the hardware/tools to actually build it.
20:14 LOL way too funny! Especially with the mostly serious tone
What is the process to becone a beta tester? I am really interested in being one.
1:01:31 : I think you should exploit the 80/20 rule; basic should include the 20% of libraries that get 80% of work done
Generally with a package manager you can just let the community manage module best practices. Sure the average user might use the big clunky general purpose library. But the thing is that as the skills of the programmer improves they can make more decisions to use more specific libraries for their use case. Generally if you just give a community the tools to decide what they want it results in the most useful or helpful system.
There are ways to make pseudo-closures that can be solved at compile time (I know they do this with inline functions in kotlin). They would work kind of like a macro. It would be good to have something like this. But maybe that could also be let to meta-programming modules
1:38:10 "I am not going to talk about far away unannounced features because when I do that what happens is other people copy them for their stuff".
The grandmaster with his ingenious ideas has spoken.
8:06 NPM doesn't use semantic versioning? I haven't used JS in years, but that would really surprise me. Devs don't have to maintain an interface forever, they'll increase the major version and break compatibility. I doubt NPM would just update a package on a major version change, but I might be wrong. I know cargo wouldn't.
Yes, npm use semantic versioning.
Yup, and you can do the same with Composer for PHP, commit libraries to your VCS. I do that at work because I don't want a deploy to fail because of external deps.
Regarding documentation on timecode: 1:29:56 , I think a classical wiki is not a good idea.
Would go for a way of "documentation that compiles".
Something like an enhanced-wiki powered by a Jai compiler on the server.
So, when the doc/code is modified, the person writing it could run a compilation.
And the “enhanced-wiki” could have some flag that would inform if it compiled or not.
That way would allow to embed documentation with code that compiles.
Extending it a bit more, the enhanced wiki-thing could check that what is documented runs successfully.
So, it should have a way of indicated some expected results that are checked against the sample doc/code execution.
An another flag that would show that what the sample code/doc runs, complies with the indicated expected results.
That last extension matches the unit-testing approach.
Jon commented about unit-testing and TDD here:
ruclips.net/video/21JlBOxgGwY/видео.html
Which I mostly agree with.
In my experience, unit-testing is very valuable if used diligently.
Worked in railway signaling software for electronic systems and unit-testing was a must.
I'd love to be in the beta, but considering how little bandwidth I'd have for playing with it, my potential slot would probably be better used by someone who does have the time.
I don't understand why that thing is not just in the open, so that everyone who's interested can follow the development without having to feel guilty about "occupying the spot of a more deserving individual".
@@EvenTheDogAgrees So that Jon can actually handle the feedback that comes in directly in a focused manner, and so he can select for people who he actually wants to hear direct feedback from. To go in open beta would require more consideration of how to collect and process feedback. Also, because key features that he thinks should be in the open beta like the modules system aren't in yet, like he said in this video. He doesn't want to launch the language to the wider public (even if it is just beta) if key things that would make it work at scale aren't in yet.
At least, that's an approximation of what he's said in the past. Don't take what I say as the full truth.
I would love to try out your language as soon as it becomes available! Likely, I will stay with C++ (with modules) because of industry standardization and support.
But the first time I saw one of your videos about JAI I thought - "I want to use this for my own engine".
Maybe that's too early for next couple of years, but I'm certainly very curious. Especially if you can manage to adapt the C++ philosophy of providing only light-weight abstractions but not limit the user too much in expressiveness.
Anyways, great work - it's looking really good so far!
Systems that automatically download dependencies at build-time usually use a versioning system called Semantic Versioning, which by default only installs only bugfixes (patches) and API additions (minor versions), but not anything that changes the public API (major versions). There's something to say for it.
The thing is, it's not enforced so you rely on trusting that the library author will not mess up, but in reality, they will and do.
What's the timeline for Open beta? As someone coming from enterprise programming, I would love to do some low-level programming in a modern language again.
Exciting stuff!
8:44 it's hilarious to see js library have more lines of "dependencies" or "funding" in package.json than the actual code
npm is both amazing and terrible at the same time.
Amazing in that we can all easily just install packages to help us develop things very quickly and get updates for the modules we're using.
Terrible in the way that it's a billion files and if you ever by some reason copy the folder, you'll be waiting for quite awhile and it'd do tons of reads/writes. Also when some vendor changes things and therefore becomes incompatible with other packages. Things become less fun.
that is why i hand-pick only ones i really need (one being zlib because i just don't feel like re-implementing deflate or ANY compression, another datastream because it hides a lot of those "read/write data from/to THIS offset" annoyances and remembering to specify endianness with EVERY read/write) and very carefully watch-out for extra dependencies or that accursed "you need node/NPM". downside is i spend a painful amount of time writing boilerplate because the default APIs are useless right out of the box. it's 'fun' ... T-T [yeh, this language can't be done fast ENOUGH.]
i mostly try to ignore package.json tbh. at least in the more sane libraries (aka the ones that work without touching a packager/manager/compiler of any kind), you don't need it. but yeh, pretty stupid. this trend also exists in non-minimized script files and can also be seen in certain C/C++ source code, too... also, OOP by default. all those imports which usually eventually result in "i/you should just write import* or import package* and save yourself a lot of time/hassle". ofc, i say 'try' to ignore, i still read it... /: but in the end, i pluck the libraryname.min file out of the folder, put it in my project, make sure the docu/demo page is ready, and use it without thinking about node/npm or the package.json file. and it's wonderful.
p.s.
another 'favorite' JS trend of mine "how do i access/manipulate the DOM?" and the answer: '$("myelement")'
jquery has a place, but i'm glad i learned of document.getElementById() [among others] because that's a massive amount of boilerplate to call just to use one function that's already built-into JS natively. regrettably, i have some older code that does the "use jquery to do ONLY this basic thing". that, however, uses libraries that... yep...need jquery. at some point, i MIGHT finally eliminate it from the dependencies once and for all. [one MIGHT work with the semi-stable CSS3 now, since the whole reason i added it was to stylize a scrollbar...ouch]
Therapist: Big JBlow is not real, he can't hurt you
JBlow: 13:25
HAHAHAAHAHAHAH
that was good ngl
I feel like, even if I never use jai, learning it would make me understand c/c++ way better
29:35 omg if that is a way to specify a function signature that is perfect for static polymorphism. Are function pointers supported?
Got it btw, it is not a function signature, but func signatures are easy to write.
OK closures require going from the stack to the heap if you return them as values so I can see the speed argument there. But you can have a limited type of closures that you can't use as values and so don't have to move to the heap, gcc calls them nested functions (it's a GCC C extension). I've found those to be very useful. Can we have those? And yes, I understand that for small ones you can just use macros (or inlines whatever you call them -- if you can capture variables from the lexical scope? or are they hygienic so you can't? dunno) but that kind of copy-paste is not feasible if they're big or they have many call sites.
You can allocate closures on the stack just like any other struct. They don't necessarily have to be allocated on the heap.
@@skepticmoderate5790 so what happens when a closure is returned from the function in which it was declared and the variables it captures go out of scope?
@@UGPepe It depends on how your language handle them and on whether you captured variables by value or reference. If by value, there is no problem, closure contains copies. If by reference, you are in trouble )
@@IsmeGenius yes, I suppose you can have either closures that are first-class objects but without shared captures (every closure has a copy as you say), or nested functions that can, but can't be first-class objects. I think both are useful in different ways and good to have. In any case, you can't have real closures like in Lua because that would require heap and gc which is out of scope for Jai. Personally, I think the future of programming languages is where you can have both low-level and hi-level primitives in the same language and they are well integrated. Every complex program today has an embedded scripting language but they have different runtimes and integrating them adds a lot of needless friction.
2:26:25 The latest visual studio updates have made their linker multithreaded
That must be why it fails to build every other time with "Tasks have been cancelled" and forces me to restart the program.. -_-
Is there any chance to get the seat in testers group? I'll love to try it out
Libraries are not a problem in C++, the actual problem is the low quality of them. In many ways library development has been "outsourced" to random open source people who create something and then everyone just have to live with it.
NPM is a disaster, but the Web (proper) has ended up close to an ideal situation for modules. Small, self-contained and purposeful libraries, served from a cache that falls back to a content delivery network, avoids most of the problems associated with standard libraries.
If everyone went through an API that redirected cache misses to a CDN, you could potentially switch to a different CDN without breaking anything. As long as you know which file is which, you can get those bytes from anywhere.
You could also drop the cache, and use dependency management to fully determine what needs to be kept around. Users should also be able to try apps (and libraries) without (persistently) installing their dependencies.
Standardizing half of your ecosystem (in perpetuity) is obviously going to retard its evolution and undermine adaptation.
> The Python Standard Library is where modules go to die -- Kenneth Reitz
I wish open version will not come out in too long. So I could start playing around wish lower level language than I currently use. Although on the timeline it seems I would need to start playing around with C
agreed...
what do you use? i use JS...hate it...a lot... but, least i don't need to touch the c toolchain
..."function has .data, .code" ... and .stack?
Can I and how do I join the beta testing?
Waiting for open beta
21:30 Is shadowing really useful in programming languages? I feel like it should just be an error. It's just something that can cause hidden bugs but many languages allow it. Is there a good reason?
It's nice having the freedom to reuse the names when you want to. I can imagine getting irritated by the compiler errors, but you've got a good point.
I really enjoy golang despite its compiler being quite strict with these types of things (can't compile if variable is unused etc).
To be honest, it feels like a forbidden luxury - a thing that I enjoy doing, but shouldn't do. IMO, compilers should error when shadowing.
Shadowing should be error in dynamicly typed laguages, but in static? If the types doesn't match compiler should not even copile code and let to it execution. Rust has shadowing of variables, those variables can even have different types after shadowing. But if you try to use wrong type with some function call you will get compiler error preventing code compilation and potential bug.
yes, I hate the guts of languages that don't have that, and no offence but I think people who don't understand that haven't written enough code to understand the trade-off and they side to the way of safety by default not because of their own experience.
@@UGPepe why tho? what is the problem that shadowing solves? In my experience it only led to bugs.
21:30 maybe you need to implement a keyword like 'var' to infer the type so the shadowing problem do not occur
I would like to see some cool syntax stuff. Is there a video where I can see that?
@Jonathan Blow How do I join beta?
Any idea what license the language will be released under?
1:58:00 happy to hear s64 is default. My first try with rust I was sad about unsigned numbers.
what does your first sentence have to do with your second one? Jai also has unsigned numbers just like Rust. For example, Jai has u32 and u64.
@@fmease As I willfully interpreted the section, jai encourages s64 ints and therefore that is the type used for things like array sizes and indecies.
Rust requires unsigned for those things. The stuff I wrote in rust had a bunch of into s and try_into s because I needed subtraction of counts and stuff to give me negative values.
In C, my only use of unsigned is bittwiddling. Otherwise happy to avoid unsigned.
`let row_remainder = self.row_hints[iy] - isize::try_from(n_row).unwrap();`
`let iy = iy_list[usize::try_from(invalid_cell_idx).unwrap()];`
`let col_count: isize = col_x.iter().filter(|cell| cell.state == CellState::Flooded).count().try_into().unwrap();`
And the like. A lot of friction compared to if everything was just signed. I don't value the compile time invariants unsigned types provide.
@@linkVIII I'm surprised that Rust made that mistake after it turned out to be a clunky solution in C++, where std::size_t is unsigned. Like, we don't need the other 9,223,372,036,854,775,807 values, we need basically intuitive subtraction semantics without tons of warnings no one should have to care about. In fact, if the values get that big then it's nice to state that by using std::uint64_t explicitly.
@@lm1338 Rust's reasoning with unsigned is that it eliminates < 0 checks for array access. It does make some hassle with arithmetics, but not to the point of linkfviii post, it just has different types everywhere for no reason. Also, one can use `as isize` for vector sizes/indexes. It will loose on panic semantics, but with the argument that u don't need unsigned for arrays, they will never be big enough too case overflow.
Is it just me or does this language sound a whole lot like LISP with types. All this discussion about meta compiler setup really makes me feel like the expectation for this language is to define the language per usecase.
Jai Hype!
What currently existing language will this one be most similar to?
Will this be a coding-beginner-friendly language?
It borrows a lot from other languages and makes some new stuff of its own. It's similar to C since you have very fine control over memory, but it also has many features that interpreted languages do like polymorphism and metaprogramming.
It's a beginner language in terms of giving you a lot of control and flexibility over how you want to do things, but that also means it let's you mess up in many ways. It does have better error messages and how-to's than most languages which helps a lot, but the main aim of the language is to allow good programmers to perform to the best of their ability.
The analogy he uses is that you shouldn't put adults in kid gloves just because the kids need kid gloves.
You should open source it, but have complete control over the official repository(s). Monarcho-anarchism.
That's how most FOSS projects that I"m familiar with work
@@mosesturner4018 True, but he does not have to pretend to be someone who takes public PRs or something. I just wanna fuck around with the language because it seems super interesting. I also am interested in seeing the IR evaluation.
So pretty much a source-available repository. I agree.
@@KaranLobana Oh, not taking PRs is a lot different. I could see that being good as long as bugs still did get fixed
He had a copy-cat problem with even just doing language demos. Making the source widely available would allow it's momentum to escape him, and would let copy cats create jai-lite languages crowding out Jon in his own niche. At some point the project will grow beyond Jon and would likely be open sourced at that point (languages without open source tend to not generate momentum [conjecture]).
There are microphones cameras and satellites in my head
Where we can test the langage ?
Why would you allow returning blank variables (underscore)? To my understanding it's more of a hint to the compiler: This is the syntax I mean but I don't actually need the value, say you're unpacking a tuple and only need the first value.
foo, _, _ := (some, tuple, values); // I don't know enough about Jai syntax ;-)
Returning _ wouldn't just be weird but basically impossible.
jai doesn't have tuples
Hello Jonathan, I know this may seem as a weird question (it's also highly speculative) but is the Jai programming language named after Randy Pausch's wife as an homage/tribute to Randy and his legacy ?
Can’t believe I hadn’t thought of that!
Do you even need the "mode" for the allocator function?
If you had old_ptr, old_size, new_size then isn't that enough? If new_size is 0, then it's a free (of old_ptr, with size old_size). If old_ptr is null then it's a malloc (old_size ignored). If old_ptr is non-null and size is non-zero, then it's a realloc. Isn't that unambiguous?
The enum being there is an artifact from earlier when there were more options. It's worth thinking about removing it, but the options you give above are not unambiguous ... for example a realloc to size 0 should not be a free, because the code will call free on it later and that needs to work. But since the arguments are signed, it could be -1 or something.
@@jblow888 Well if you're calling it with size zero and updating the pointer with the returned value (as you would for a realloc), then it'll get freed and the pointer will be null, so free later will be a no-op.
But more importantly, I was suggesting that this call with size=0 _is_ the free (there's no separate free call later).
It's a somewhat common trick in libs to let people provide their own allocators by just providing a function pointer to realloc, since this function can do both malloc, realloc and free depending on the parameters. In your case it would be a modified realloc because you also want to provide the allocation size to the free and realloc cases
The baited breath for the upcoming language has been baited enough!
About the SIMD intrinsics, I use them a lot (much more since MSVC removed them from 64bit compilation) and for most uses I would actually prefer to go back to inline assembly. The intrinsics can mix more easily with other code (without the compiler having to be needlessly pessimistic) which could be good for some "micro-use" of SIMD like in Swiss Tables, but that's about it. The main use of intrinsics is in heavy loops that are 90% SIMD anyway, not a lot of mixing. I don't buy the arguments that intrinsics are easier: they look absolutely terrible (worse than the assembly instructions they represent), and working with intrinsics requires a lot of work to poke the code until the compiler is "happy" and generates the right code (if it ever does). With inline assembly (or out-of-line assembly, but I don't like having mixed languages in a project, with extern function declarations that aren't kept in sync with their actual definition, and the weird build configuration etc) I can just write the right thing, without having to appease a stubborn compiler.
I literally just searched for this programming language yesterday. I wonder if it will be released?¿ lol I’m commenting before watching the vid
Did someone from the beta ask Jon why he always refers to the language as "the language" or "this programming language"? Any progress on the final name?
I don't have a timestamp, sorry, but at one point he mentioned that he was skipping all questions about the name
The name is jai
I'm expecting this project to end up as python 4.0, with explicit typing and non-garbage collected mode available through with-statement, and option to compile into C.
Nice!
I personally find it strange that web doesn't do compression/compilation. You'd think with limited network capacity you wouldn't want to be sending data for whitespace and variable names and all that through javascript/html. I just find it confusing how much of a general waste there is with network traffic.
Most JavaScript is minified to get rid of whitespace. Long variable babes get shortened, etc.
@@hasen_judi it really depends on the build system but yeah I've definitely come across systems where the javascript is minified. I just find the whole web interesting. Would we better off with some kind of universal bytecode like Java or C#? Or does javascript actually provide (albeit slow) but terse expression of operations (operations per character).
@FichDich InDemArsch yes I know what wasm is.
@FichDich InDemArsch That's true, and V8 is a marvel in optimization, although I'm pretty sure they meant bytecode over-the-wire to have smaller bundles. It's what WebAssembly does, but of course, that's not JavaScript :P
@@Dorumin Even with wasm the parent wrapper of the binary is javascript unicode characters. Its not like we send binary directly to clients screens. We have to create the running context and hand the wasm to it and all the rest with html dom object construction etc. Plus. Wasm is a relatively new technology.
Is the compiler going to be available as open source? How can I become a JAI user asap?
IIRC, it'll be closed-source at first, then open-sourced at some point. My guess is that it'll be open-sourced once the compiler is bootstrapped.
Where can one apply for a beta invite?
Good question....
As far as I understood it a while back the beta was for people that Jon and buddies/employees personally know.
Which is why he mentioned maybe moving to a system where beta testers get invite codes to give away, which reminds me of how certain private torrent trackers work.
Do you hire people outside the US?
I'm definitely looking forward to the day I can get my hands on this language. Do you have any recommendations about things to read/watch/try out while we wait. (Apart from your talks and you stream of course)
how do you handle servicing of 3rd-party dependencies? let's say the jpeg lib you're using has a buffer-overflow that's being exploited in the wild. being able to handle this in a sane way implies having a system that understand semantic package versioning.
so when is the COD Cold War chicken dinner coming?
Jon, do you plan on adding interfaces at any point to language? While inheritance is extremely problematic and I avoid it at all costs (except for code I can control, there I use it if it feels beneficial to the structure), interfaces are awesome. You can't break an interface (local copy will take care of removed functions and there is no third-party low-level code you rely on) and you can't accidentally forget to override smth you have to or have some left over functions you kind of hope nobody uses (like one infamous java error with stack extending vector and having vector functions leak memory, because they are accessible, but don't know about additional stack properties). Also, they are great for library designers. I can safely add or remove anything I want and I honestly don't care about the end-user.
I don't consider behaviour you can get with some smoke and mirrors (like C11 "inheritance" you can get with anonymous structs) to be a "core feature". I talk about real feature that is part of the intention, not a useful byproduct
Interfaces are already in Jai. E.g. f :: (x: $T/interface My_Interface) {}
For engagement of new people I'd suggest you give some context. 3hr long video without name, description, background, links. I might be interested, but without any brief and info I'm not gonna be wasting 3hrs on this. :(
Good thing I am not getting paid to entertain you!
@@jblow888 of course not. But I thought that you would want people to listen what you have to say. Anyway, sorry to bother you.
Closure seem to be redundant, maybe I if you're making a debugger it's needed to back track. Also is there a way to rotate images yet?
Are there any other programming languages where folks involved in the creation/maintenance of the language ever even talk about being able to run some software in 20 years, with zero maintenance?
Common Lisp? If we are talking about compiling software on then-modern-platform one of the problems with is that you need to try to abstract many OS facing things (like file system access) and I feel like Jon would be against that.
@@digitalspecter If I search for “common lisp old programs” I am not left with the impression that there was any particular effort to make sure lisp programs were able to be run decades later. I wasn’t able to find examples of programs that can be run today, that had dependencies besides the interpreter itself, for example.
@@Ryan1729 The cpp comitte supposedly recently discussed whether a new feature should be included or not because some pcs from the 90s wouldn't be able to have fully conforming implementations then
@@user-sl6gn1ss8p That sounds like the opposite of what I care about: I want to be able to run software 20 years after it was written and beyond. Whether some code works on a machine from 20 to 30 years before the code was written seems a lot less important. I mean hearing about someone getting some modern language to compile down to say, a 6502 is cool and all, but I'm not sure who is actual expecting that from their programming language.
@@Ryan1729 well yeah, but I do think it goes both ways. Code written in Cpp on the 90s or early 2000's should mostly still work on current pcs. C, even more so. Fortran is just now being phased out on CERN I hear. Really it mostly comes down to compiler support: if the architecture of pcs change drastically than you'll need people willing to adapt your language to that, I don't think there's much dancing around this
modules? like nodejs modules?
Didn't know Jon also belonged to the Church of Emacs ;) well well hello there saint
1:38:10
"I'm not gonna talk about far away unnanounced features, because when I do that what happens is that other people copy them for their stuff."
Is he that afraid to lose a tiny bit of fame to other developers or is Jai supposed to be closed source and propietary?
Jai will be closed-source at first, then open-sourced at some point down the road (my guess is that right as the compiler gets bootstrapped, it'll go open-source).
Considering how often he complains about other software and languages.. wouldn't it be good if they copied his ideas? Idk it's weird.
@@digitalspecter I'm guessing he's not gonna mind once Jai is out or once it's open-sourced, because that would take away from the language, no?
it makes sense. same reason i don't discuss too much about my unannounced game stuff. there are people who'd pounce on the opportunity to do it before me. in fact, it's happened a few times to me this exact thing happened, just not for code. that left a sour taste in my mouth. it'd be disastrous for something i plan to make money or game recognition from.
also, some people who'd do this literally ONLY for money or fame may well half-ass the implementation. then you have companies like microsoft that can and will do shady things to stay-ahead of [potential] competitors.
makes sense to me. also, that can lead to scope creep issues because then everyone wants it done yesterday. (thanks corporations!)
@@ETXAlienRobot201 Really sucks to hear.
The witness 2 ty
What kind of puzzles would the sequel have that haven't already been done? Did you finish the witness?
@@nickeshchauhan5661 Yes I finished everything, and it was amazing. Assuming the witness was perfect and everything has been done is ignorant IMO. I just want another out of the box thinking puzzle game.
Your whole spiel at the start here is literally no different than how NPM and Yarn already handle dependencies. They get pulled into your project, but you don't need to commit them into version control. You can do so if you want, however. Similarly, all package managers support locking down versions to majors, and updates aren't automatic, they are explicit.
Why do you keep bashing systems you've seemingly not used?
he has talked extensively about NPM. you've seemingly not listened.
@@jac1011 I've listened to enough of his talks to know he often misrepresents other ecosystems and often creates problems out of thin air. I'm not a fan of these ecosystems to start with, but he misrepresents them time and time again. It's incredible honestly.
The problems he discusses in the first fifteen minutes here almost all package managers solve. It's not as if nobody has ever thought of escrow or mothballing projects before. It's just that it's not needed for a lot of projects; particularly when in development; so it's not the default.
@@SK83RJOSH It seems you're misunderstanding most of what I am saying. You are talking about options and things that can be made to happen; I am talking about culture-building and things that will happen by default if nothing is overridden (thus will happen most of the time). I strongly dislike package management culture, and am talking about stuff that I have experienced going all the way back to CPAN. You seem to be invested in making hostile interpretations of everything I say though, so, I mean, you do you, but can you not bother me with it? Thanks.
I know now how to get JB to respond to me. i will misinterpret and criticize him 😂
Maybe I’m incorrect, but what I have seen with many package managers is that often they install binaries and not source code.
So if the pc architecture changes and you didn't download the source code, in 20 years you may be screwed, because you depended on someone keeping the source online for you.
Of course, you could also just copy the source code of the site, but this isn't the default. (and for many applications for good reason, to avoid bloat)
But we have to remember what Jon's language is about. Making standalone games. (I could be wrong, but it's kind of like making app images)
It has to compile on various architectures without having to worry about internet connectivity.
And here is the kicker, you can copy the source code directly to ensure that your code will compile safely 20 years from now, you always could.
But people don't, and that is the cultural issue.
Maybe a JB package manager just downloads source, and places the source directly in the project directory, it would avoid most of the issues he seems to be concerned about. There would be storage trade-offs, but i get the feeling It's not his main concern
Instead of coding the compiler yourself, can't you just flow chart the whole architecture out first, that way people can see the big picture and are on the same page?
That's not how things work
@@hasen_judi Well!! thats how it works in my company because we have to do a lot of custom stuff and work with a lot of fussy clients , its freaking annoying doing it but it pays off big time. I hope your not one of those gun ho coders that makes those monster Classes that have Classes in Classes! lol! joke
@@larrybird3729 I don't work on this compiler so I can't speak on Jon's behalf, but there are many live coding sessions on this channel, you can take a look to see how Jon works.
Like this one is really good
ruclips.net/video/rzE6bz2Uf7g/видео.html
I laughed on the inside, thanks
Bro its not cool to call them betas just cause you made The Witness
You should ask people to pay for the language...lol. Maybe ask people to pay if we all want better software.
r0ckinfirepower kinda like lisps do? or rebol, or eiffel? yea that worked
That's just gatekeeping and it doesn't even work.. especially seeing how profit-driven development is so often the source of stupid quick hacks that never get fixed..