Super well done video! For someone not at all familiar with all the lower level concepts of compilers and whatnot, this video explained it all in a very nice and easy to follow way. Well done whoever worked on it, you did a damn good job! Also very well presented by Svetlana!
Only now I saw this presentation. The new K2 compiler is so interesting! I found this one thanks to the talk by Amanda Hinchman-Dominguez on Kotlin Conf'23 in Amsterdam. I find it fascinating how much work has been put into this. Hopefully the coming Kotlin version 2 will make K2 a production ready reality! Can't wait to see that being rolled out. In the meantime I'm already testdriving the 2.0.0-Beta Kotlin version. Thanks for the great and in detail informative video!
Thanks for the great teaser! In the future, if you have subtitles (which are very nice btw), it'd be great if you could avoid drawing figures on the lowest part of the frame which is covered by subtitles. :)
I appreciate your successfully keeping the discussion reasonably scoped given all the complexity that lies beneath and all the compiler theory. Oh what a can of worms you would have opened if you also explored the possible uses of the front-end for the purposes of linters and other language processors. Also, that arc from the intermediate back-end code to the native target to LLVM and how LLVM, in turn, targets multiple different machine architectures and has its own intermediate form inside of it which it does internal optimizations on before it internally plugs into whichever back-end for the specific machine it's targeting. The would have been discussion on its own inception-style multi-targeting of multi-targeting. Ouch. People just using Kotlin who want the ultimate benefits resulting from all the rearchitecture would have their brains fall out and would not follow. In the end they would bail and leave without the answer to the question, "But what does this do FOR ME?" Good job! Myself, i'm excited for the new work on the native collector and what it offers async for native but that can't get very far before the new native back-end has a good chance to stabilize.
In my daily work with Kotlin, my #1 issue (by far) is the performance of the compiler and the IDE. I've witnessed the compiler come to a crawl at single files. It's great to see that there's work being done here.
I have one scenario in mind that I would love for the new compiler front-end when it's finished but much of that idea hinges on one question I have. What language is the compiler front-end written in? I ask because I fear it is written in Java because of an ANTLR requirement, having seen a published ANTLR grammar for it which I think was the official one used by jetbrains. Also, I could understand it running on the VM because Kotlin is used as a DSL for gradle where the VM is already spun up and so invocation is fast and convenient. However, I hope it is written in Kotlin itself as might be possible since self-hosting compilers are a thing. But what would be REALLY COOL would be if the compiler could run quick in the VM but also run as a native executable and a self-hosting compiler would allow for it since Kotlin allows for multi-platform targets. And a native compiler would be excellent for quick startup time since the JAVA VM can be a real slug. And fast startup time would be VERY useful it the front-end were used to launch an interpreter for the purpose of Kotlin SCRIPTS, an area where a programmer may not want all the artifact juggling since often scripts allow for users to avoid it. Furthermore, scripts allow for a very easy in for learners and certainly people coming from Python and Javascript would love it since all the intermediate juggling can be a stumbling block for beginners. Copying files around and build automation is a task not to be taken on lightly for beginners because why overload someone who is new to loops and variables and types with all the stupid troublesome details right when they're first learning a language? Also, for people who want to do what might otherwise be a bash (barf) script or a python script to just do some log rotation or onsie-twosie admin scrript - you may as well offer THEN a genuinely good language for the task. Artifact juggling can be a real tedious nuisance and if you want to win over the data science crowd from python, making scripting very easy would be just about as important as database connectivity.
I assumed it was called K2 because it's Kotlin compiler version 2. :P Can you explain why the original compiler frontend had the syntax tree and semantic table separate? Based on how you presented it, I assumed that it was the standard/only way to do it. Including the semantic info in the syntax tree seems like an obvious idea, so why wasn't it done that way from the start, if it was possible and such a good idea?
8:17 "In programming languages, it's very much the same idea, grammar defines the rules. In English, you can make mistakes, and people will understand you. But in the programming world, it can't happen, you need to strictly follow the rules, otherwise, the compiler won't understand and accept your code." JavaScript,... hold my beer...
@@AlanDarkworld I don't think kotlinc calls javac at all, because javac is only responsible for compiling Java source files into JVM bytecode, and really contributes nothing more to other JVM compilers for other languages, because their compilers translate directly into JVM bytecode without touching Java source code at all. The Kotlin compiler does all of this on its own, and translates all the Kotlin code into the relevant JVM bytecode by itself.
Oh hi, future me here: kotlinc does indeed call javac internally when building for the JVM, because it needs to build some Java files that it relies on to allow you to use Java APIs (on Android, this happens a lot more because the whole SDK is in Java, also when using any Java libraries). But pure-Kotlin code files are built directly with kotlinc, which knows how to keep the two-way interop between Java and Kotlin code when it calls into javac.
The folks at jetbrains are literal coding gods walking among us. Good job guys
Looking forward to trying out upcoming compiler!
Hope you enjoy it!
That was an excellent overview of the compiler. Great job!
Amazing talk, I love that to hear about Kotlin internals! Thank you Sveta for your great understandable English :-)
This is an amazing introduction to Kotlin compiler. Thank you so much for your effort. Please have more videos for Kotlin compiler & compiler plugins.
Super well done video! For someone not at all familiar with all the lower level concepts of compilers and whatnot, this video explained it all in a very nice and easy to follow way. Well done whoever worked on it, you did a damn good job! Also very well presented by Svetlana!
Great overview and understandable. Thanks
Only now I saw this presentation. The new K2 compiler is so interesting! I found this one thanks to the talk by Amanda Hinchman-Dominguez on Kotlin Conf'23 in Amsterdam. I find it fascinating how much work has been put into this. Hopefully the coming Kotlin version 2 will make K2 a production ready reality! Can't wait to see that being rolled out. In the meantime I'm already testdriving the 2.0.0-Beta Kotlin version. Thanks for the great and in detail informative video!
Thank you! Great job explaining the compiler. I finally understand it!
Thanks for the great teaser! In the future, if you have subtitles (which are very nice btw), it'd be great if you could avoid drawing figures on the lowest part of the frame which is covered by subtitles. :)
I appreciate your successfully keeping the discussion reasonably scoped given all the complexity that lies beneath and all the compiler theory. Oh what a can of worms you would have opened if you also explored the possible uses of the front-end for the purposes of linters and other language processors. Also, that arc from the intermediate back-end code to the native target to LLVM and how LLVM, in turn, targets multiple different machine architectures and has its own intermediate form inside of it which it does internal optimizations on before it internally plugs into whichever back-end for the specific machine it's targeting. The would have been discussion on its own inception-style multi-targeting of multi-targeting. Ouch. People just using Kotlin who want the ultimate benefits resulting from all the rearchitecture would have their brains fall out and would not follow. In the end they would bail and leave without the answer to the question, "But what does this do FOR ME?" Good job! Myself, i'm excited for the new work on the native collector and what it offers async for native but that can't get very far before the new native back-end has a good chance to stabilize.
Great explanation about kotlin compiler. Thanks!
Glad you enjoyed it!
In my daily work with Kotlin, my #1 issue (by far) is the performance of the compiler and the IDE. I've witnessed the compiler come to a crawl at single files. It's great to see that there's work being done here.
At 3:24, on the right side, what is "L6; ICONST_0; ISTORE 2" for?
Looks like it sets 0 to a local variable.
Compiler plugins are very exciting! Way easier using IR and very powerful
I have one scenario in mind that I would love for the new compiler front-end when it's finished but much of that idea hinges on one question I have. What language is the compiler front-end written in? I ask because I fear it is written in Java because of an ANTLR requirement, having seen a published ANTLR grammar for it which I think was the official one used by jetbrains. Also, I could understand it running on the VM because Kotlin is used as a DSL for gradle where the VM is already spun up and so invocation is fast and convenient. However, I hope it is written in Kotlin itself as might be possible since self-hosting compilers are a thing. But what would be REALLY COOL would be if the compiler could run quick in the VM but also run as a native executable and a self-hosting compiler would allow for it since Kotlin allows for multi-platform targets. And a native compiler would be excellent for quick startup time since the JAVA VM can be a real slug. And fast startup time would be VERY useful it the front-end were used to launch an interpreter for the purpose of Kotlin SCRIPTS, an area where a programmer may not want all the artifact juggling since often scripts allow for users to avoid it. Furthermore, scripts allow for a very easy in for learners and certainly people coming from Python and Javascript would love it since all the intermediate juggling can be a stumbling block for beginners. Copying files around and build automation is a task not to be taken on lightly for beginners because why overload someone who is new to loops and variables and types with all the stupid troublesome details right when they're first learning a language? Also, for people who want to do what might otherwise be a bash (barf) script or a python script to just do some log rotation or onsie-twosie admin scrript - you may as well offer THEN a genuinely good language for the task. Artifact juggling can be a real tedious nuisance and if you want to win over the data science crowd from python, making scripting very easy would be just about as important as database connectivity.
I assumed it was called K2 because it's Kotlin compiler version 2. :P
Can you explain why the original compiler frontend had the syntax tree and semantic table separate? Based on how you presented it, I assumed that it was the standard/only way to do it. Including the semantic info in the syntax tree seems like an obvious idea, so why wasn't it done that way from the start, if it was possible and such a good idea?
Thank you very much for explaining, Great job
Great explanation, thanks!
You're welcome!
This is great!!👍👍
When can we get to chat to the compiler developers face to face online in some video conference
hey my bad u already said it
still where's the link
Please re-make this video as K2 is being released soon!
Btw, is this content still accurate?
экселент))
Can you still use java with this new compiler?
Yes.
Kotlin/Jvm will always be compatible with Java as it will become Java Bytecode.
Where is kotlin island?
Saint Petersburg :)
Now we're getting to the important questions
8:17 "In programming languages, it's very much the same idea, grammar defines the rules. In English, you can make mistakes, and people will understand you. But in the programming world, it can't happen, you need to strictly follow the rules, otherwise, the compiler won't understand and accept your code." JavaScript,... hold my beer...
Hehehehe, at 30:37 ... JVM IR backend KEND! . Sounds like some en.wikipedia.org/wiki/Kiai :D.
🥋🥋🥋🥋🥋🥋🥋
Is there an equivalent analyzer for the java syntax tree?
I was wondering about that, too. As far as I know, kotlinc internally calls into javac somehow, but I don't know any details.
@@AlanDarkworld I don't think kotlinc calls javac at all, because javac is only responsible for compiling Java source files into JVM bytecode, and really contributes nothing more to other JVM compilers for other languages, because their compilers translate directly into JVM bytecode without touching Java source code at all. The Kotlin compiler does all of this on its own, and translates all the Kotlin code into the relevant JVM bytecode by itself.
Oh hi, future me here: kotlinc does indeed call javac internally when building for the JVM, because it needs to build some Java files that it relies on to allow you to use Java APIs (on Android, this happens a lot more because the whole SDK is in Java, also when using any Java libraries). But pure-Kotlin code files are built directly with kotlinc, which knows how to keep the two-way interop between Java and Kotlin code when it calls into javac.
Will the new frontend support nested destructuring?
\o
Are you single you're so smart and pretty lol.