Was watching the video while traveling, so I wrote down some timestamps. Comment if I missed anything :) Main topics of improvement: 1:00 Macro system / Metaprogramming 3:15 Cross compiling support 8:00 Optimizations with dynamic libraries Q&A: 11:30 Will there be standardizing of module and function naming? 19:05 Any schedule for public beta? 19:35 Support for cross-architecutre based memory ordering for better multi-threaded programs? 27:30 Tea break 28:50 Inline assembly and intrinsics 34:30 Return to topic about cross-architecutre based memory ordering 38:30 experimental inline assembler in the language for playing around with 41:00 Is there a way to emit VEX prefix imstructions instead of default SSE ones? 42:20 Lock free programming? 46:20 Any plans for stuctured notes? 49:15 How does poke name work? 55:50 Add C style API for printing? 1:04:25 Comment on prior SIMD topic 1:05:50 Any plans to address release and distribution more completely...? (metaprog. topic) 1:07:50 Does the Sokobon game support gamepad and does it do it with input module? 1:09:30 Any plans to improve static executible building? (libC/Linux topic) 1:14:50 Will simp3d be it's own module? 1:15:35 Any plans for the 10th anniversary of making the compiler? 1:15:50 32bit support? 1:19:05 Is having a partially optimized compilation on the roadmap? 1:19:45 How do the compiler's performance metrics compare to what you are targeting for the release target? 1:21:15 Must the compiler be completely publically released? 1:23:14 Any plans to support proprietary rendering APIs through compiler modules? 1:23:35 Do DLL calls go through C call directive? 1:26:44 Will thread local variables ever be a thing? Questions from start of the session: 1:27:55 Renaming with metaprogram hooks? 1:28:28 Have you considered scoped imports? 1:31:55 How do you think about the boundry between tooling and the language? 1:34:48 Does Jon have any unexpected benefits of using Jai? 1:35:38 Is clojure still on the roadmap? Also sad story 😢 1:37:30 How does Jon assess what is best for the language syntax? 1:40:05 What happens SHTF and you don't wanna work on the compiler any more and it is still closed source? 1:40:30 What is the current roadmap of making cross-compilation nicer? 1:42:15 Any plans for vector complete syntax that maps to wide operations like in shading languages? 1:49:05 Will Sokobon struct serialization feature be added to the compiler? 1:56:35 Notes in function argument list? 1:57:45 Will non-int/sub-script [ ] operator overloading be possible? 1:59:50 Is it possible to make a procedure to print out all variables used in code block parentheses scope? 2:01:00 Any plans for table literals? 2:02:20 Is it a priority to drop the necessary C runtime libraries for compiled binaries? 2:03:50 User difficulty with debugging? 2:04:20 Any way to discover modules made by 3rd parties? 2:05:03 Are notes always gonna stay as strings? 2:05:10 Array subscript using enums or other integer adjacent type.
I'll probably never code at this level but I enjoy listening to these Q and A in the background as if they are BBC radio or a 10 hour ambient thunder video.
I love the idea of distributing a compiler binary, that's pretty much all I need at the moment. I'd like to get a feel of a language without going too deep into it.
zig made their own libc, from what I've seen their cross compilation story seams really good. They also have a bunch of libcs from different os in the compiler so you can still link against that if you need to. It seams like a lot of work to support all of that tho
It is easy to get a static binary that will work on all Linux systems by just making the syscalls yourself (Go and Zig do this by default as you mentioned). However, issues begin as soon as you want to interact in any significant way with the full "operating system" beyond the Linux kernel since there is so much variation. To do graphics you are essentially required to dynamically link/load shared objects (e.g. the system libwayland and libvulkan) and that immediately ties your binary to a system libc. The magic of cosmopolitan libc apparently can solve this to some extent, but it irks me that such complexity is necessary.
Ok, I got curious and the way that cosmopolitan libc solves this is nuts. They at runtime execute the system C compiler to build a small C program that returns an array of function pointers containing the dynamic loading functions for the system libc. They then execute this compiled binary, longjmp back into the static executable, and wrap the returned functions. Very smart and cool, but uh... far from ideal.
@@permutationlockI mean, I'm not an expert, but couldn't you just write a loader yourself? mmap an executable region, parse the elf sections and put the code you need in the executable area, and do it recursively to load child dependencies?
@@DalenPS That is theoretically possible, but I haven't seen anyone do it. As I understand it, glibc is not designed to work this way and getting it to work would be painful and brittle. If you have a custom loader and load your desired system library, you will need to also load the libc and libdl shared objects. But libdl is not designed to be loaded, but to be run as the program interpreter, and thus will not have its internal data initialized.
Distributing just a compiler binary could be really beneficial for the language. Likely no headache of pollution or source code management as you talk about while letting a lot of people get hands-on with the language so it doesn't lose traction.
There is nolibc project in Linux Kernel since early 2023 that wraps libc calls to syscalls. It doesn't seem 100% ready yet but for common libc stuff it should be enough. It's header-only.
Ideas for namespaces maybe worth adopting (from python namespaces): 1. Default namespace for symbols in a file is: dir/file 2. Optionally rename the namespace 3. Optionally add the symbols into the global namespace
@@itr00ow93 Dislike it for 2 reasons: In Zig you have to make the arbitrary choice whenever to put a function in the struct or in a pure namespace(method or function). Also you can't separate struct declarations with functions in the code if you happen to choose to use the structs as namespaces. Zig does this I guess to make generics through comptime. However I would not put much weight on this when deciding what language to use.
I want an expert language that makes me feel like an intergalactic bounty hunter, Jai is that. I'm making do with my own something that generates C++ but it's inferior to Jai in pretty much every way. Jai is going to make some programmers really happy (in fact I've seen some programmers already saying it's their favorite/go-to language)
I bet you could easily have a group of volunteers who manage the open source portion of this in a manner that is mostly hands-off for you, if you open sourced the code sooner rather than later.
Are any plans for "advanced" linking pragmas? custom calling conventions, section sizing, placement, alignment, etc? I feel like mainstream c compilers have pretty limited (or nonexistent) functionality for low level system and embedded programming, and that there is no particular good reason for these limitations.
I admit haven't thought much about the how, but when I look at the calling conventions that eg. msvc supports, I don't see anything special about them. Is it really necessary for the compiler to predefine all the ways we can call functions? Why is crosscompiling for linux or windows so needlessly cumbersome? Are we doomed to wrapping syscalls for all eternity?
What file format does Jai use for debug information? I think I've heard Raphael talk about PDB, but I'm not sure. Is it sufficient for the language or is there any information that would be useful for a debugger that doesn't fit in that format? If you were to write a debug information file format from scratch (and a debugger that uses it), is there anything you would do differently? I'm just curious what your experience is on this. This is not meant to be a suggestion to actually do that.
Is it possible today to have a compile time procedure in Jai that verifies that a decorated piece of code fulfills some constraint? Would I be able to write a macro like //must_mention(SOME_ENUM_MEMBER) {function body} or //must_have_no_for_loops() {function body}
[I've not been following jai so idk ignore me] 13:25 ~"Maybe 'add' shouldn't be so overloaded"~: Personally I'm a strong believer that lists and sets should use the same verb for `add`. It is super useful to me to be able to change 1 line from array to set if I've grown too big for linear search. (And then I tell this to python people and they laugh at me)
Well, it's really easy to do that even if that isn't the name it has in the Basic module. You just type `add :: array_add;` and you're good to go. You can write the same for set procedures and it will work just like adding overloads.
@@saniancreations It causes a lot of inconsistency if people are renaming imports often, which I think is very undesirable. Renaming imports should be an exception, not the rule.
> And then I tell this to python people and they laugh at me For python the choice between list and set is a choice of ordering not about performance. A python programmer would never use the array+linear search in the first place, he would use the set, because the array would not give him much of a performance gain - you are writing python so small performance gains do not matter to you otherwise you would not write python - and coding the linear search for loop is tedious. (Also I don't think the array will be much faster even for relatively small arrays, the for loop of the linear search is slow and python lists do not have great cache layout so the list does not have as much of a data locality advantage, and because of the search the bytecode is probably more, but I am sure you can find expensive to hash object and stuff like that where the list is faster) So the question add vs append is a semantic one. Add adds anywhere. Append appends only at the end. (Though python has ordered dictionaries since 3.6 so yeah that argument does not count as much anymore, now it is an argument of compatibility and there is only one way to do it)
@@theevilcottonball [Not jai discussion -- DO IGNORE] > A python programmer would never use the array+linear search in the first place I can only assume that `3 in [1, 10, -5]` or `.find()` does a linear search. > and coding the linear search for loop is tedious A real for loop is easier to read and write if you need to search with a predicate than `next(filter(lambda it: it.name == "foo", people), None)` or `next((it for it in people if it.name == "bar"), None)` But cache locality aside, before I start exploring a problem, I will default to an array/list. I don't know and don't want to know if I semantically want a set until i get into it. j ava collections interface isn't too bad.
Nope. Jon is pretty adamant about there only being one single way to call functions: function(args), that is also the reason why there are no methods or member functions like obj.method(args), (unless you have an actual function pointer as a struct field)
The issue of needing prefixes to name things when not using "object oriented" syntax would go away if we move away from text files as program source. The true identity of the function should be a unique ID (auto-generated), the name would be metadata used for presentation and finding it. The association with a type (the type of "this" in OOP) really just comes from the parameter types, or at least the first parameter type. The editor should automatically show you existing functions that take in the current type. So in practice you'd write code much like C-like languages, i.e. cursor is on a variable of known type, press "." and type some of the function's name, editor finds matches and you select the one you meant. If there are 2 functions that match the current type and have the same display name, you choose the right one based on description, or whatever extra you know about it.
The easiest way to target Linux and be sure it works everywhere is to target the flatpak runtime. Flatpak has become the de-facto universal runtime on Linux and they do work everywhere, effectively.
sometimes things just _need_ to be complex. you may not like it, or understand why it needs to be that way. but that doesn't mean it's any less necessary. of course, if you're a-priori the smartest person in the room, then by-definition everything else is over-engineered nonsense. of course.
Hey, I just want to say that I've been coding for a long time now, 10 years actually. It's too bad my formative years as a programmer couldn't be with this language, because oh boy would it make me a different programmer. This language has also been in development for 10 years, and there is a lot of people here that have 2-3 years of experience in C++ right now, and they deserve a little better than for their thinking to be shaped by a boomer frankenstein language, as well as a bunch of guys same or more experienced than me, who didn't get the chance to do any better during their programmer maturation cycle, but could have gotten one. What I meant to say is Hurry up.
Your comment comes off entitled. It's Jon's creation and he can take as long as he pleases. Also nothing is stopping you from programming in a sane way with C++. It's not as good as jai, but you can avoid the junk and still get stuff done. Consider that the jai compiler is written in C++...
@@MikeCampo I am not entitled to anything. And I know all that and did actually write C++ like this. I have to admit I did also expect people to be angry at me, but I still feel strongly about this.
@@nexovec why look to others to make the world a better place? Do your own project or stop complaining. Jon is an artistic visionary and he is very deliberate about how he works.
try Odin for now, it's got some similar syntax in some places and different in others but the creator has pretty similar design philosophy to Jon and it's open source and publicly available.
@@jupiterapollo4985 Of course that's all he is to us. It's not like he's our bud. People are asking questions because they are interested in Jai as a development tool, not because they have a personal relationship with Jonathan Blow. Similarly, people's interest in the future of C# isn't because they're enamored with Anders Hejlsberg or Mads Torgersen. You find a reasonable pragmatic question "disrespectful" and "distasteful" because you have bizarre irrational sentiments. This is as relevant to me or anyone else as the fact that I don't like the taste of asparagus is to you.
having "Warning, this may not work on ARM" on screen while talking about how you don't need the modern memory model thing in your programming language, is kind of funny.
@@Lircking It's a comment about a potential issue. But arm programs do indeed work correctly. I'm using jai on android most days, and have even tried and failed to make one_time_init break in the past. And _even if there was an issue_, it could be resolved in a direct way without needing to add anything to the compiler.
to be fair, the C++ memory model specs are ambiguously worded and if you take them literally, you end up with extremely bad code because it makes the wrong guarantees.
GPT summary The document you've uploaded is a transcript of a Q&A session from September 2024, primarily discussing the roadmap, development challenges, and design considerations for a new programming language and compiler. Here’s a concise summary of the key points: Remaining Roadmap Before Public Release: Macro System: The goal is to simplify Lisp-style code rewrites while keeping strong typing and ease of debugging. It’s not fully crucial but feels like an important feature to finalize. Cross-compiling Support: The focus is on making cross-compilation more robust, particularly improving the user understanding and experience during this process, ensuring clarity on what happens at different compilation stages. Dynamic Libraries (DLLs): There's friction with calling into DLLs due to the non-deterministic order of context entries, and the goal is to make it more automatic and robust. Language Design Decisions: Function Naming Consistency: There’s an effort to harmonize how functions are named across different modules, particularly in basic operations like arrays. Code Complexity: There's a strong focus on keeping the language simple and avoiding unnecessary complexity, especially in terms of memory models and multi-threading semantics, unlike other languages like C++. Multithreading and Memory Semantics: The compiler currently doesn’t support explicit memory ordering semantics for multi-threading programs like in C++. The goal is to avoid complicating the language with features that are often difficult to use correctly. Debugging and Intrinsics: A shift from inline assembly to intrinsics might be considered for better portability, especially for simpler operations across different CPUs. Compilation and Performance: There’s a desire to optimize both the compilation process and runtime speed further, targeting about 1 million lines per second during compilation. Open-source and Public Beta: The team is cautious about a public release, as this would lock in design decisions. There might be an intermediate phase with access to binaries but not the full source code. This session provides detailed insights into the ongoing efforts to stabilize and refine the compiler for public use, balancing simplicity, performance, and flexibility for the end users.
![Pointers in C / C++ [Full Course]](http://i.ytimg.com/vi/zuegQmMdy8M/mqdefault.jpg)
Was watching the video while traveling, so I wrote down some timestamps. Comment if I missed anything :)
Main topics of improvement:
1:00 Macro system / Metaprogramming
3:15 Cross compiling support
8:00 Optimizations with dynamic libraries
Q&A:
11:30 Will there be standardizing of module and function naming?
19:05 Any schedule for public beta?
19:35 Support for cross-architecutre based memory ordering for better multi-threaded programs?
27:30 Tea break
28:50 Inline assembly and intrinsics
34:30 Return to topic about cross-architecutre based memory ordering
38:30 experimental inline assembler in the language for playing around with
41:00 Is there a way to emit VEX prefix imstructions instead of default SSE ones?
42:20 Lock free programming?
46:20 Any plans for stuctured notes?
49:15 How does poke name work?
55:50 Add C style API for printing?
1:04:25 Comment on prior SIMD topic
1:05:50 Any plans to address release and distribution more completely...? (metaprog. topic)
1:07:50 Does the Sokobon game support gamepad and does it do it with input module?
1:09:30 Any plans to improve static executible building? (libC/Linux topic)
1:14:50 Will simp3d be it's own module?
1:15:35 Any plans for the 10th anniversary of making the compiler?
1:15:50 32bit support?
1:19:05 Is having a partially optimized compilation on the roadmap?
1:19:45 How do the compiler's performance metrics compare to what you are targeting for the release target?
1:21:15 Must the compiler be completely publically released?
1:23:14 Any plans to support proprietary rendering APIs through compiler modules?
1:23:35 Do DLL calls go through C call directive?
1:26:44 Will thread local variables ever be a thing?
Questions from start of the session:
1:27:55 Renaming with metaprogram hooks?
1:28:28 Have you considered scoped imports?
1:31:55 How do you think about the boundry between tooling and the language?
1:34:48 Does Jon have any unexpected benefits of using Jai?
1:35:38 Is clojure still on the roadmap? Also sad story 😢
1:37:30 How does Jon assess what is best for the language syntax?
1:40:05 What happens SHTF and you don't wanna work on the compiler any more and it is still closed source?
1:40:30 What is the current roadmap of making cross-compilation nicer?
1:42:15 Any plans for vector complete syntax that maps to wide operations like in shading languages?
1:49:05 Will Sokobon struct serialization feature be added to the compiler?
1:56:35 Notes in function argument list?
1:57:45 Will non-int/sub-script [ ] operator overloading be possible?
1:59:50 Is it possible to make a procedure to print out all variables used in code block parentheses scope?
2:01:00 Any plans for table literals?
2:02:20 Is it a priority to drop the necessary C runtime libraries for compiled binaries?
2:03:50 User difficulty with debugging?
2:04:20 Any way to discover modules made by 3rd parties?
2:05:03 Are notes always gonna stay as strings?
2:05:10 Array subscript using enums or other integer adjacent type.
Hey, thank you for this!
"some time stamps" :D :D thanks!
still using simd today to save ms of time in certain visiblity and physics calculations. Do need to support them. Intrinsic is fine.
I'll probably never code at this level but I enjoy listening to these Q and A in the background as if they are BBC radio or a 10 hour ambient thunder video.
weirdest compliment ever? :D
I love the idea of distributing a compiler binary, that's pretty much all I need at the moment. I'd like to get a feel of a language without going too deep into it.
Agreed!
Agreed, I would love getting our hands on just the compiler binary and that might* be the perfect intermediate step for them
please, let thsis be real.
but I would go full serious into building a good game during 2-3 years
Thanks for the update!
Oh nice I have been for more content about Jai !
can't wait to finally use the compiler in 2034
zig made their own libc, from what I've seen their cross compilation story seams really good. They also have a bunch of libcs from different os in the compiler so you can still link against that if you need to. It seams like a lot of work to support all of that tho
It is easy to get a static binary that will work on all Linux systems by just making the syscalls yourself (Go and Zig do this by default as you mentioned). However, issues begin as soon as you want to interact in any significant way with the full "operating system" beyond the Linux kernel since there is so much variation. To do graphics you are essentially required to dynamically link/load shared objects (e.g. the system libwayland and libvulkan) and that immediately ties your binary to a system libc. The magic of cosmopolitan libc apparently can solve this to some extent, but it irks me that such complexity is necessary.
Ok, I got curious and the way that cosmopolitan libc solves this is nuts. They at runtime execute the system C compiler to build a small C program that returns an array of function pointers containing the dynamic loading functions for the system libc. They then execute this compiled binary, longjmp back into the static executable, and wrap the returned functions. Very smart and cool, but uh... far from ideal.
@@permutationlockI mean, I'm not an expert, but couldn't you just write a loader yourself? mmap an executable region, parse the elf sections and put the code you need in the executable area, and do it recursively to load child dependencies?
@@DalenPS That is theoretically possible, but I haven't seen anyone do it. As I understand it, glibc is not designed to work this way and getting it to work would be painful and brittle. If you have a custom loader and load your desired system library, you will need to also load the libc and libdl shared objects. But libdl is not designed to be loaded, but to be run as the program interpreter, and thus will not have its internal data initialized.
I think we'll all retire before Jon releases Jai...😃
you must be really old
I really appreciate learning about programming language design atm, thanks for the upload
I've been waiting so long for Jai to be released...
Distributing just a compiler binary could be really beneficial for the language. Likely no headache of pollution or source code management as you talk about while letting a lot of people get hands-on with the language so it doesn't lose traction.
There is nolibc project in Linux Kernel since early 2023 that wraps libc calls to syscalls. It doesn't seem 100% ready yet but for common libc stuff it should be enough. It's header-only.
Ideas for namespaces maybe worth adopting (from python namespaces):
1. Default namespace for symbols in a file is: dir/file
2. Optionally rename the namespace
3. Optionally add the symbols into the global namespace
personally I prefer zig's way where an import is just a struct
@@itr00ow93 Dislike it for 2 reasons: In Zig you have to make the arbitrary choice whenever to put a function in the struct or in a pure namespace(method or function). Also you can't separate struct declarations with functions in the code if you happen to choose to use the structs as namespaces. Zig does this I guess to make generics through comptime. However I would not put much weight on this when deciding what language to use.
So it's going to be another 10 years.
the GOAT is here
yes im here
i look forward to the release
I want an expert language that makes me feel like an intergalactic bounty hunter, Jai is that.
I'm making do with my own something that generates C++ but it's inferior to Jai in pretty much every way. Jai is going to make some programmers really happy (in fact I've seen some programmers already saying it's their favorite/go-to language)
I saw tsoding video, Jai has best syntax out there.
I bet you could easily have a group of volunteers who manage the open source portion of this in a manner that is mostly hands-off for you, if you open sourced the code sooner rather than later.
Well you know what he thinks about open-source
@@theonewithoutidentity He's arrogant and wrong, and we see the results (or rather lack of them).
Yes, a Pajets group that shuffles README, or the useless PRs themselves
Are any plans for "advanced" linking pragmas? custom calling conventions, section sizing, placement, alignment, etc? I feel like mainstream c compilers have pretty limited (or nonexistent) functionality for low level system and embedded programming, and that there is no particular good reason for these limitations.
How are you going to describe a custom calling convention with pragmas?
I admit haven't thought much about the how, but when I look at the calling conventions that eg. msvc supports, I don't see anything special about them.
Is it really necessary for the compiler to predefine all the ways we can call functions? Why is crosscompiling for linux or windows so needlessly cumbersome? Are we doomed to wrapping syscalls for all eternity?
love the say Jai feels there. wonder what Jon thinks about Zig vs Rust, or about Zig in general..
What file format does Jai use for debug information? I think I've heard Raphael talk about PDB, but I'm not sure. Is it sufficient for the language or is there any information that would be useful for a debugger that doesn't fit in that format? If you were to write a debug information file format from scratch (and a debugger that uses it), is there anything you would do differently?
I'm just curious what your experience is on this. This is not meant to be a suggestion to actually do that.
I use RemedyBG and Rad Debugger with Jai just fine. It uses PDB.
Is it possible today to have a compile time procedure in Jai that verifies that a decorated piece of code fulfills some constraint?
Would I be able to write a macro like
//must_mention(SOME_ENUM_MEMBER) {function body}
or
//must_have_no_for_loops() {function body}
Yes, easily.
@@jblow888 This opens up so many possibilities, no more trading off simplicity&performance for developer sanity.
[I've not been following jai so idk ignore me]
13:25 ~"Maybe 'add' shouldn't be so overloaded"~: Personally I'm a strong believer that lists and sets should use the same verb for `add`. It is super useful to me to be able to change 1 line from array to set if I've grown too big for linear search.
(And then I tell this to python people and they laugh at me)
Well, it's really easy to do that even if that isn't the name it has in the Basic module. You just type `add :: array_add;` and you're good to go. You can write the same for set procedures and it will work just like adding overloads.
@@saniancreations It causes a lot of inconsistency if people are renaming imports often, which I think is very undesirable. Renaming imports should be an exception, not the rule.
> And then I tell this to python people and they laugh at me
For python the choice between list and set is a choice of ordering not about performance. A python programmer would never use the array+linear search in the first place, he would use the set, because the array would not give him much of a performance gain - you are writing python so small performance gains do not matter to you otherwise you would not write python - and coding the linear search for loop is tedious. (Also I don't think the array will be much faster even for relatively small arrays, the for loop of the linear search is slow and python lists do not have great cache layout so the list does not have as much of a data locality advantage, and because of the search the bytecode is probably more, but I am sure you can find expensive to hash object and stuff like that where the list is faster)
So the question add vs append is a semantic one. Add adds anywhere. Append appends only at the end. (Though python has ordered dictionaries since 3.6 so yeah that argument does not count as much anymore, now it is an argument of compatibility and there is only one way to do it)
@@theevilcottonball [Not jai discussion -- DO IGNORE]
> A python programmer would never use the array+linear search in the first place
I can only assume that `3 in [1, 10, -5]` or `.find()` does a linear search.
> and coding the linear search for loop is tedious
A real for loop is easier to read and write if you need to search with a predicate than `next(filter(lambda it: it.name == "foo", people), None)` or `next((it for it in people if it.name == "bar"), None)`
But cache locality aside, before I start exploring a problem, I will default to an array/list. I don't know and don't want to know if I semantically want a set until i get into it. j ava collections interface isn't too bad.
im waiting sn 2022-2023 so maybe i can have a betakey(300 key -> 700 beta key increasment). (=
Where I can watch this translations and ask questions. Is that Twitch?
WASM support would be aswesome
Is there an operator like |> that passes the LHS as first argument to fn call on RHS?
Nope. Jon is pretty adamant about there only being one single way to call functions: function(args), that is also the reason why there are no methods or member functions like obj.method(args), (unless you have an actual function pointer as a struct field)
@@saniancreations Sounds like religion.
@@JimBalter
There should be only one way to do things.
C# used to be a good small language, now there are many ways to do almost anything.
Nice to see how things are progressing.
This is a bit more complicated than RPG MAKER MV and JS
That's a web browser; instantly millions of lines of code.
That's complex.
@@microcolonel still easier to use lol
The issue of needing prefixes to name things when not using "object oriented" syntax would go away if we move away from text files as program source. The true identity of the function should be a unique ID (auto-generated), the name would be metadata used for presentation and finding it. The association with a type (the type of "this" in OOP) really just comes from the parameter types, or at least the first parameter type. The editor should automatically show you existing functions that take in the current type. So in practice you'd write code much like C-like languages, i.e. cursor is on a variable of known type, press "." and type some of the function's name, editor finds matches and you select the one you meant. If there are 2 functions that match the current type and have the same display name, you choose the right one based on description, or whatever extra you know about it.
A long time ago you talked about automatically copying modules into projects to get more control over dependencies. Where is that on the roadmap?
de-overfitting be upon ye, and all
does Jon's editor use treesitter for syntax highlighting or what?
No, he doesn't use LSPs. It's just simple keyword and symbol highlighting and nothing else.
@@saniancreations treesitter ain't an lsp.
@@adicide9070 Okay, let me rephrase. The answer is no, as for the "or what", it's just simple keyword and symbol highlighting and nothing else.
@@saniancreations thanks. and I didn't mean to be nitpicking, sorry!
@@adicide9070 He uses the latest version of Emacs and I think it uses treesitter as default.
The easiest way to target Linux and be sure it works everywhere is to target the flatpak runtime. Flatpak has become the de-facto universal runtime on Linux and they do work everywhere, effectively.
sometimes things just _need_ to be complex. you may not like it, or understand why it needs to be that way. but that doesn't mean it's any less necessary.
of course, if you're a-priori the smartest person in the room, then by-definition everything else is over-engineered nonsense.
of course.
Hey, I just want to say that I've been coding for a long time now, 10 years actually. It's too bad my formative years as a programmer couldn't be with this language, because oh boy would it make me a different programmer. This language has also been in development for 10 years, and there is a lot of people here that have 2-3 years of experience in C++ right now, and they deserve a little better than for their thinking to be shaped by a boomer frankenstein language, as well as a bunch of guys same or more experienced than me, who didn't get the chance to do any better during their programmer maturation cycle, but could have gotten one.
What I meant to say is Hurry up.
Does it really need to be perfect for you to launch this thing?
Your comment comes off entitled. It's Jon's creation and he can take as long as he pleases. Also nothing is stopping you from programming in a sane way with C++. It's not as good as jai, but you can avoid the junk and still get stuff done. Consider that the jai compiler is written in C++...
@@MikeCampo I am not entitled to anything. And I know all that and did actually write C++ like this.
I have to admit I did also expect people to be angry at me, but I still feel strongly about this.
@@nexovec why look to others to make the world a better place? Do your own project or stop complaining. Jon is an artistic visionary and he is very deliberate about how he works.
try Odin for now, it's got some similar syntax in some places and different in others but the creator has pretty similar design philosophy to Jon and it's open source and publicly available.
How can I get a copy of Jai from you? I wanna try it out in system programming, i.e. for shell tools that I typically write in sh, bash or C.
Please?
When it releases.
LOL
I hate when people ask questions about possible death outcomes towards developers of a project. Seems very disrespecful...
That is why I never told anyone that I was working on my project when I started it in 1992.
@@____uncompetative It's just very distasteful to me. Like all the person is to them is their project. So weird.
@@jupiterapollo4985 I agree.
@@jupiterapollo4985 Of course that's all he is to us. It's not like he's our bud. People are asking questions because they are interested in Jai as a development tool, not because they have a personal relationship with Jonathan Blow. Similarly, people's interest in the future of C# isn't because they're enamored with Anders Hejlsberg or Mads Torgersen.
You find a reasonable pragmatic question "disrespectful" and "distasteful" because you have bizarre irrational sentiments. This is as relevant to me or anyone else as the fact that I don't like the taste of asparagus is to you.
@@JimBalter Agree, it is a pragmatic question and got answered.
having "Warning, this may not work on ARM" on screen while talking about how you don't need the modern memory model thing in your programming language, is kind of funny.
I think he explained pretty clearly why he hasn't rushed to add anything like that at 35:05.
@@halfwaydown he states that it's an "unnecessary complication", while we clearly see his own program not working correctly
@@Lircking It's a comment about a potential issue. But arm programs do indeed work correctly. I'm using jai on android most days, and have even tried and failed to make one_time_init break in the past. And _even if there was an issue_, it could be resolved in a direct way without needing to add anything to the compiler.
to be fair, the C++ memory model specs are ambiguously worded and if you take them literally, you end up with extremely bad code because it makes the wrong guarantees.
It's kind of pathetic.
GPT summary
The document you've uploaded is a transcript of a Q&A session from September 2024, primarily discussing the roadmap, development challenges, and design considerations for a new programming language and compiler. Here’s a concise summary of the key points:
Remaining Roadmap Before Public Release:
Macro System: The goal is to simplify Lisp-style code rewrites while keeping strong typing and ease of debugging. It’s not fully crucial but feels like an important feature to finalize.
Cross-compiling Support: The focus is on making cross-compilation more robust, particularly improving the user understanding and experience during this process, ensuring clarity on what happens at different compilation stages.
Dynamic Libraries (DLLs): There's friction with calling into DLLs due to the non-deterministic order of context entries, and the goal is to make it more automatic and robust.
Language Design Decisions:
Function Naming Consistency: There’s an effort to harmonize how functions are named across different modules, particularly in basic operations like arrays.
Code Complexity: There's a strong focus on keeping the language simple and avoiding unnecessary complexity, especially in terms of memory models and multi-threading semantics, unlike other languages like C++.
Multithreading and Memory Semantics:
The compiler currently doesn’t support explicit memory ordering semantics for multi-threading programs like in C++. The goal is to avoid complicating the language with features that are often difficult to use correctly.
Debugging and Intrinsics:
A shift from inline assembly to intrinsics might be considered for better portability, especially for simpler operations across different CPUs.
Compilation and Performance:
There’s a desire to optimize both the compilation process and runtime speed further, targeting about 1 million lines per second during compilation.
Open-source and Public Beta:
The team is cautious about a public release, as this would lock in design decisions. There might be an intermediate phase with access to binaries but not the full source code.
This session provides detailed insights into the ongoing efforts to stabilize and refine the compiler for public use, balancing simplicity, performance, and flexibility for the end users.
Being less complex than C++ is a low bar. It's ignorant and intellectually dishonest to use it as the comparand.
Namespaces seems like it would be a good feature to have
Uhh
@@jblow888 Can you elaborate why namespaces would be a good/bad idea to implement?
You can "namespace" a module on import so ...
I think he meant LSP support for namespaces
holy ratiod
J O N = = G O D
😂
bro is straight up snorting that blowcaine