Kotlin 1.4 Online Event, Day 1: General Overview

[Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] [Music] so [Music] [Music] so [Music] [Music] do [Music] [Music] [Music] [Music] hello everyone and welcome to this kotlin 1.4 online event my name is hari hariri and i'm joining you from sunny south of spain although it's not very sunny today even if it were i'm in a room with the blinds down so i wouldn't know if it's sunny and i have the pleasure to be a company today with my colleague sebastian hi everyone i'm sebastian uh developer advocate here at jetbrains as well in hadi's team and i'm joining you from munich which is mostly cloudy currently but you can see that because of all the artificial lighting around me you know back in the old days when i used to fly uh munich always used to have the sun i mean there was always sun in in the sky and then when you would reach munich you would see this layer of cloud and then you would go down and and you're like okay i've arrived to munich but um trust me said that there is sun somewhere okay i'll just have to take your word for it because at least for my position right here i can't see it oh there there is there definitely is but anyway let's talk about our wonderful uh event that's happening so we are here on day one of four of the koa koa okay i told you that we don't need a teleprompter what's koa it's the kotlin online event hardy you should know this i know yeah okay yes we're here on day one of four of the kotlin online event so tell us a little bit about this event what's happening seb well we have four days packed with uh calling content and today we have the pleasure of taking you through all the content that is about cotton in general so we'll have a keynote we'll have a community overview talks on language features tooling achievements and we'll even have a look into the further future of kotlin so yeah this is going to be probably a couple of good couple of hours of uh calling content so we're going to be here for a while grab some snacks or grab some beverages uh in preparation for all this content i know i have my calling cup with me oh okay i i don't um sorry uh can we can we restart i i don't have my kotlin swag with me uh but just for folks to know this isn't going to happen all at the same time is it i mean over the next four days we're going to have afternoon and morning events right so we're going to have this split over a couple of blocks essentially all that kind of have their their own little theme you can see the schedule both on the kotlin lang website um as well as uh yeah on on the links that are in the social media yeah and we've got an all-star cast for you cast with okay no no no never mind i'm not going to do that joke anymore but i feel like i feel like maybe this is a great point to congratulate our community to have kind of outgrown uh this this obsession with the letter k we see a lot of uh great libraries and community efforts out there that are that don't actually contain a k at all yeah that's very impressive i think that's a very good point and i think they should keep it up with a c okay anyway uh-huh yeah sure i think when you it's it's time to give uh you know enough of us blabbering and let's give way to uh the the keynote right who's it going to be so this is going to be by all of our colleagues from the kotlin team who have done great work to release call in 1.4 and which we're here to celebrate what hold on all of our colleagues there's like 100 plus people on the team like they're all going to take part well you know i would like to believe that they all had their part in this keynote as well but it's it's a selection of them uh which we'll present here but i think it's best if we'll just let them introduce themselves and kind of take over from here absolutely so let's enjoy the talk hello everyone welcome if you want to know the latest news of where kotlin stands today and what awaits us in the future you've tuned in to the right talk today i will be presenting with my colleagues from the collin team yugortelstoy head of product management stay islavirochen head of development cetlanes akova the lead developer advocate for kotlin roman yelazar head of the language research team and anastasia capanina the product manager for the kotlin multiplatform mobile team together we will give you an overview of all things kotlin today all we have today is 30 minutes and there is a lot to tell so we will be referring you to other talks that will cover in depth the topics that we're only touching upon note those links and we will be calling them out as you know column 1.4 was released on august 17th this year i hope most of you have already upgraded the feedback that we've been hearing so far is generally positive and where it is not i hope that our 1.4.10 and point 20 updates will be fixing your issues if you run into any problems please feel free to report them to us we'll be really happy to help meanwhile our team is working on the future of kotlin we're on the new six-month release cadence now so kotlin 1.5 is planned for the spring 2021. it makes the release cycle shorter so expect fewer features fewer changes but in exchange the release will come sooner it will be better for everyone for these upcoming months we'll keep our focus on quality and performance on the one hand and on making kotlin shine on the server side and multiply for mobile development on the other my colleagues will tell you more about it in just a minute but first let's look at the bigger picture as some of you heard me say before we think of cotton as more than just a language it's not only a spec a set of rules a compiler a tool chain an id or a set of libraries it's much more than that kotlin is an ecosystem that starts with people kotlin is us all of us you me my colleagues at jetbrains and everyone who reads and writes kotlin code for work as a learning project or as a hobby you can say it's everyone who can complain about the slow bales or the ternary operator by the way we're working on that i mean the builds uh the common ecosystem is all these people sharing the same ideas how we think about code what abstractions we use how we express our thoughts and of course we all use the same software libraries the compiler the id and so on and kotlin is us people connected by ideas and software igor will tell you more on how the golden ecosystem is doing and what trends we see there welcome igor as nj has said the kotlin ecosystem is all about the people those who escort him for solving their tasks and those who also give something back kotlin owes much of its success to the enthusiasts who visualize it in communities share their experience with teams and lead the effort to introduce it to the code base of industry projects and we are very proud to see that the number of people using kotlin is constantly increasing it means that both their enthusiasts and the people they are influencing love the language in the last 12 months nearly 6 million people have edited classroom code in their ide at least once which is one and a half times more than last year and six times more than the year before but there is one more metric which is important for kotlin the number of active users it shows us the number of developers who are using kotlin professionally an active user is a developer who writes kotlin coach regularly in our case it means that there are some codebots this month and in the previous month and this number is also very impressive we have more than 1.2 million active developers this year which is 50 higher than last year sounds great right but the core of kotlin community consists of developers who not only actively use kotlin but also give something back there are lots of types of contributions that make you a part of our community it can be making pull requests to the kotlin tool chain reporting issues in our issue tracker giving toxic conferences or even open sourcing your kotlin code these are just a few examples of the active members of our community they are awesome and we are happy to see that the community is growing together with our user base for example on stack overflow there are more and more equations and dancers about kotlin every year each new question posted on stack overflow helps not just the author but everyone who visits it and that can be hundreds of thousands of people nearly 200 000 view repositories were created on github this year with kotlin as a primary language which is twice as many as the year before over 30 thousand kotlin developers are now exchanging knowledge and supporting each other on slack and rated and more than 90 000 people now follow our official twitter account for tips tricks and announcements with over 200 user groups worldwide the cotton community is thriving and growing if you want to know more about how to become a part of the community and help the ecosystem visit my talk later today that is called staying in touch where i will provide some hints and tips about contributing to kotlin we are happy to be a part of the community ourselves and one of our recent investments is enhancing the performance and quality of kotlin we believe that a great developer experience is key to the happiness and productivity of both individual developers and their teams i'm sure each of you has at one time or another experience the perfect state of flow that wonderful stage of being fully immersed in solving a problem where you're deeply focused on the task and hand and actually enjoying the process i believe that the primary task of a great tooling is to help a developer get in the flow state and stay there for as long as possible the worst enemy of the flow state is sudden interruptions like exceptions or performance problems just imagine you're immersed in a complex task building a beautiful castle of abstractions in your mind when suddenly this syntax highlighting stops working and your code turns red the best case scenario is you'll spend some time fixing the problem and then get back to work but the worst case is your work day is ruined and you can't focus anymore that's one of the reasons why quality and performance are key priorities for kotlin and i'm very proud of the results we've been able to achieve in this area we've significantly reduced the time it takes for the code completion suggestions to appear based on the data from our recent releases the number of cases where the completion window appears really fast has reached 70 percent and the number of slower cases has been significantly reduced besides auto completion we have also worked on improving the highlighting speed the most impressive results were achieved for large calls and files when you open such a file for the first time you see its content highlighted up to three times faster than it was before and that's just the tip of the ice pack we fixed numerous ui freezes memory leaks and performance problems and launched new ide features to improve their developer experience there is actually a lot to cover on the recent idea improvements so we have a dedicated talk from antony galashev later today all about quality and performance in intellij ids it's a great talk you definitely don't want to miss it performance and quality isn't a one-time activity for the kotlin team we consider it key to the happiness and productivity of kotlin developers so we are committed to making it great we have lots of plans for the upcoming months that will improve the overall developer experience with both ide and build tools but in the long run we plan to drastically improve the performance of code completion and syntax highlighting by switching the cotton plug into a new compiler front end it's a complex project and we are currently in the early stages of implementing the first prototype but we believe that it will be a game changer i know that you're excited so now i will hand you over to stanislav erohin the head of development for kotlin who will tell you more about our new compiler build speed is one of the biggest concerns for our users and increasing it is really important to us we've delivered different incremental improvements over the years but as you know we've decided to address this issue fundamentally and rewrite the core of the coding compiler the obvious goal for the new compiler is for it to be really fast but we also wanted to unify all the supported platforms and be pluggable meaning it will provide the api for compiler extensions we started working on it some time ago and we are now ready to share some of our achievements the kotlin compiler consists of two parts the front end and the back ends the front end takes the source code analyze it finds the get functions property or class to be called in each case and calculate the types of all the variables expressions and so on then the backends generate executables for different target platforms in the current compiler the front end accounts for more than 70 of the compilation time in the new compiler you significantly optimize the front end and it's now 4.5 times faster than in the old compiler also as higher mentioned before the ide uses the same front-end for its work so the performance of the id will be drastically improved this year our goal is to get the new coding compiler to correctly compile itself this part is not ready for progression just yet and it still need a year or so to reach the alpha state in the meanwhile we are bringing you other parts of the new compiler the new hypnosis algorithm and new backends cartoon 1.4 comes with new type infinite algorithm it solves a lot of issues involving consistent behavior and make evolving the language easier in short this new object makes it possible to implement dual language features that we previously couldn't the new type inference implementations support complicated scenarios involved in code they exploit generic functions smart cast callable reference or delegated properties you can learn about it in more detail and see code examples in setonary circle talk due language features the second change we want to highlight is our move to unify coding backends historically the first two target platform for coaching were gm and js and the backends were implemented independently of each other and didn't share much logic because of that some language features required double the work to support as they had to be implemented in the jm backend and in the js backend with scotland native we started working on unified backend internal representation of the source code that nowadays is users in jm and jsi are based backends this way with a unified book infrastructure we can implement features that fix bugs only once but that isn't all the new infrastructure allows to significantly improve the size of the resulting binary in jsr backend by up to two times compare it with the old js backend and it allows google to make jetpack compose as a plugin for gmail backend right now both air back ends cotton glam and cotton.js are in alpha status and we want to take into account all your feedback before making them the new default so please try them out and that's all i had to tell you about our new compiler let's move further and discuss what's new in a variety of quarter feature areas and we'll start with ramani lizard who will talk about one of gotten most important applications coding for server side kotlin was worn as a gbm language had naturally encompassed android and then spread on to the other platforms all things gvm are still a big focus of the language and that means the domain were gvm shines server-side applications gvm is the largest server-side platform in the world employing millions of developers more than half of the gvm server developers use spring the most popular server-side gvm framework it nicely pairs with scotland concise syntax and various core costly features like properties thanks to interpretability cotton is not only used by new projects but it is also being gradually adopted by big projects working on a mixed java cotton project is a breeze as the java language evolves we are committed to providing support for the latest java language features that come out so rest assured that seamless integration with upcoming java records and sale classes is high on our kotlin language design priority list we are also keeping track of potential future developments like project valhalla and project loom to ensure that you'll be able to use cotton with the most recent versions of gbm and integrate with the modern java code in cotton 1.4 we've closed one big feature request that blocked a number of server-side java developers from cotton adoption it used to be a case that only interfaces defined in java could be subject to same conversion allowing for easy usage with hot and lambdas now calling functional interfaces marked with the fun keyword can enjoy the same benefits making it easier to convert your java code to kotlin many advanced sculpting features like coroutines and delegated properties were designed to simplify repeating hard to support patterns of code that often appear in the server side code coroutines in particular fit especially well to work with your active framework on the server making developers more productive producing code that has less programming language ceremony and more business domain substance the release of carotene's debugger in cotton 1.4 adds to this story there are a lot of major jvm server-side frameworks that you can naturally use with scotland we've recently released a dedicated web page to highlight the productive server-side development with scotland there you can find links to content tutorials and examples for all of them there is one server-side framework that is developed from ground up in cotton by the cotton team at jetbrains and it is being used by key judgments products like space this framework is called cater it fully embraces cotton design philosophy and is based entirely on cult encourages to achieve high scalability it provides an easy to use api and its features are pluggable and extensible caterer is also actively used outside of jetbrains so we get a lot of feedback one of the experts that people like about gator is how simple is to get up and running without any magic in pure cotton code we've recently increased the team size in cater and have a lot of plans in place for the framework not only in terms of features and functionality but also commitment to api stability and release cadence modern server side often means serverless yet setting up the corresponding infrastructure is far from easy when something is repetitive variables or hard to maintain that's where kotlin comes in in particular cutlass the experimental server less costly framework that focuses on reducing the routine of serverless deployment by generating straight from the code of the application itself whether you write your application with spring or cater i'm happy to announce that we are forming a separate team to work on the cutlass project expanding support for cloud platforms with the addition of google cloud platform and nd support for raw vm runtime how big is cotton server-side adoption it is big and growing i'll show just a few examples atlassian is using cotton for all its new services development adobe prefers scotland to java to streamlight a server-side code and get better developer experience eng bank is increasing its productivity with scotland and there are many more stories like that there are other talks to watch during this cotton online event focused on server side in general cater and catalyst please join them to learn more next svetlana sacco will tell you about colton multiplatform our vision is for kotlin to be a reliable companion for all your undertakings a default language choice for whatever project you decide to work on next with kotlin you can apply your knowledge of the language when you switch to a new platform like you an android developer and decide that you want to implement a web version of your app or you're interested in writing server side code you can reuse your skills and expertise by choosing the language that you're already familiar with kotlin multiplatform technology helps to achieve that here is how it works at its core there is common kotlin it consists of the language and the core libraries you can write the codelink advance and then compile it to different target platforms such as jvmjs or native file at them you can interact with different platforms using platform-specific versions of kotlin you can easily mix java and kotlin code together when it's compared to java use typescript definitions from kotlin js code or call kotlin native code from swift we are working on the set of core libraries and we encourage the community to join our effort and provide multi-platform versions of more domain-specific libraries during our event you can learn the details about each of the core libraries in the corresponding talks anonymous statistics shows us that ten percent of intelligent idea users including both ultimate and community versions built their projects for more than one platform that's very exciting news for us let's build the future together using the content multiplatform technology we're seeing more and more people using golden.js for sharing business logic between server and web clients or alongside mobile targets which is really exciting for us the web target for godly multiplatform is an important strategic investment for kotlin it's actively used inside the company to build and ship jetbrain space it's a big project with more than 70 developers working on it and its full stack kotlin we are working in close collaboration with the space team we analyze and improve their first-hand experience of using kotlin multi-platform for web with the goal of making it a mature technology in the future what's new to kotlin js in 1.4 you can try the new compiler backend which is currently in alpha it will become the new default in the near future and it considerably improves the size of generated binaries it also comes with a new more comfortable way of interoperating with the javascript and typescript ecosystem in addition to the new compiler 1.4 also introduces new features for managing stealth sheets and paint dependencies and more all of which are ready for you to use we warmly welcome the growing number of community libraries and frameworks for kotlin jazz like freeze do doodle ki vision or cology we are working on the webassembly target for kotlin webassembly is the new web standard supported by all the major browsers it exposes a virtual machine to the users of the browser and of course we would like for kotlin to run on it we are working on the compiler prototype that uses the webassembly proposal for garbage collection and collaborating with the webassembly by emvenders to make sure that kotlin will be a good fit in the ecosystem if you want to learn more about the current state of kotlin js and its future i'd suggest listening to the talk from my colleague sebastian wagner calls and jazz in 1.4 and beyond don't miss it next on a stage we will talk about another important application of cosmic multiplatform technology using it for mobile development since 2019 kotlin has been a recommended language for android development our team has put a lot of effort into making the lives of android developers easier and more enjoyable and the android community has been truly supportive but what if we can go further sharing code between android and ios is the holy grail of mobile development right here for one platform and get it running on the other one without having to redo your work you wouldn't like that right but there's a problem these platforms are really different especially when it comes to the ui layer they have different navigation logics different controls different best practices at the same time however the business logic such as network and data management or some internal calculations is often the same for both platforms this makes it natural to share only parts of app you really need to share and then leverage all android or ios platform-specific capabilities when you need to kotlin multi-platform technology gives you this flexibility over the last year we have concentrated on turning this technological possibility in trans smooth and enjoyable end-to-end user experience and with 1.4 we have released coldly multiplatform mobile and sdk for cross-platform mobile development with kmm you can write your multiplexing cooking code in android studio an idea you are already used to and run an ios application from the same tab you use to run your android app write cross platform tests in common code and launch them on both android and ios targets all from the same ide if you want to create a new multiplexion project from scratch there are comprehensive guides and an idea wizard to get you started and if you have an existing android application created in kotlin you don't have to throw your entire code base out of your window just to make it cross-platform you can reuse the code you have already written create a new multilateral module in your android tab using the special wizard we have created move your existing android card to this model and integrate it with the ios app integration with the ios ecosystem is seamless if objective-c interoperability a framework produced from kotlin code looks just like any other ios framework and we have improved support for the cocopus dependency manager to make this integration even easier now it takes just a bit of initial setup and a couple of strings in the build script join these developers who are already using kmm production enjoy its capabilities autodesk has introduced kotlin multiplatform mobile to their plan grid app to ship a single source of truth for offline sync logic and data models on three platforms android ios and windows quizlet migrated their business logic from a shared javascript approach to kmm and by doing that they drastically improved the performance of both their android and ios applications touchlab icefrog and mayago use kmm to deliver better apps for their clients on both platforms and to reduce the time these are spent in development even then up for an ambitious startup run by a single developer the here essentials app is powered by kmm and this is only the beginning codley multiplatform mobile is in alpha and we have a lot of exciting things planned for the future a better onboarding experience painless gradle configuration faster compilation of course ios ecosystem interoperability improvements new ide features and bug fixes and lots and lots of infrastructure and stability work take your existing application and make it multi-platform right now if you are interested in mobile development with kotlin android or multi-platform the third day of our online event has talks just for you florina montenesco will talk about the state of kotlin for android yakatorina petrova offer an introduction to quarterly multiplexer mobile for newcomers and if you are already familiar with kotlin multiplatform dmitry savinov will be there with his diving into multiple talk to expand the borders of your understanding stay tuned and now let me pass it over back to andre thank you anastasia thanks everyone ten years ago we started kotlin as a better language for the jvm but over time it became a lot more than that today kotlin is a community of back-end developers and front-end developers mobile developers and web developers we see more and more cloud users among us and even data science and kotlin is already a thing exciting as it is today we did a quick survey of the key parts of the colon ecosystem and outlined the primary direction we're taking right now to sum it up very very briefly one we're doubling down on the performance and bug fixing so we'll be making kotlin faster and smoother for you two the new compiler is underway making good progress it will bring really big speed ups and lots of flexibility in the future three we're investing a lot into the server-side use cases we'll keep improving in this area on all fronts from the language to the frameworks and four column multiply from mobile is our first step in productizing all the cool multiplatform technology we have developed all we presented today is a very high level picture if you want more details make sure to look at our roadmap that we published recently uh here's a link it's up on the website check it out what we didn't really talk much about today is the exciting new language features that may await us in the future i'm sure many of you will be curious to know more about them so there's dedicated talk by roman yelazar of named the future of kotlin this talk will give you a glimpse of the challenges that the language research team is working on now so roman will talk about what kinds of features scotland can have and what kinds it cannot have in the future you know how it goes no promises but lots of insight so check out this talk if you're interested in the future of the language as such well it's been a pack 30 minutes we're really excited to be talking to you sharing our plans and vision and hearing your feedback is always a thrilling experience we have four days of talks queuing days and discussions ahead of us lots of interactions this is the first time we're doing it online i feel a bit nervous but i'm sure it will all go very well i wish you to have a good one have fun and have a nice scotland well i hope that keynote gave you a small taste of all the wonders that caught in 1.4 has to offer but before we actually continue with our uh schedule program i think hadi has to make a little correction to the statement he made before yes um thank you seb before i was saying that we had actually scheduled this for some time for one day to be in the afternoon and another day to be in the morning and you instead of correcting me thank you for not correcting me just let it slide and now here i am making this apology but anyway folks everything's going to take place at 4 p.m central european summer time and by the way we don't know if it's the last summer i mean the last change of schedule not the actual literally last summer i hope it's not the last summer anyway so we're back on schedule and uh talking about schedule one thing that is important is that uh if folks haven't noticed uh the talks are recorded although then we're gonna have the speakers actually join us for q a what this means seb is that if we are off schedule you know what this means no what does it mean honey it doesn't mean that the speaker is going on more than they should it means it's your fault or my friend but i am always but yeah no talking about timing i mean this release has been quite a long time in the making right with multiple milestone releases and a wonderful release candidate and we're able to collect a lot of feedback from the community yeah i think it was it was really nice to kind of uh see this version of kotlin evolve and see how how everyone just kind of tried it out and how many people really kind of gave back to us and helped us make this a possibility and helped everyone developing this um make it a possibility simply by providing uh their feedback um and their issues and so on yeah a big thank you to the community and i know that every time every other time like we're we're writing these blog posts for the releases i say we you and sveta and a few other people are writing these blog posts for the releases there's a whole lot of people that we're thanking for not only for uh pull requests and code contributions but of course the bug tracking and feature requests and and finding those bugs and and logging right well there's so many things yeah thank you to everyone for making this uh release and in general kotlin uh be a language that is being enjoyed and loved by many people but uh talking about love what's the most exciting okay well not really love but what's the most exciting part for you from 1.4 what do you mean not really love i think kotlin is is the one true love in my life i'm not going to lie here um okay go ahead don't but but i need i need some support in the youtube chat please if you uh if you feel the same way uh please let us know in the chat um well i actually have a couple of features and usually uh when i've had a couple of people ask me this most recently in uh in london which unfortunately also only was online but uh i think one of the underdogs in the car in 1.4 release uh was the array deck as as a data structure right a double ended queue it might be kind of weird to to put this in the spotlight so much uh probably most people would say something like i don't know the trailing commas the the functional interfaces all these fan favorites but yeah what about you honey so you did you see a romance tweet the other day the one about arrays yes i did don't use arrays so just okay i'm not going to use arrays anymore so i'm not going to say anything about that but that's a smart move yeah that doesn't matter uh but what about me what what about me oh what are my my most exciting features well i don't i mean look i i gotta tell you like i really am excited about the work that's being done on the compiler and the performance uh because you know that is still one of the complaints that we get is you know how can you make this build faster how can you make it quicker how can it just make me be happier and i think that any work that we do in that direction uh is fantastic and of course you've got the back end uh the new backend that we're writing which is going to allow things to move much faster in the future right because we've got a common back end and and not each thing do it doing its own thing so for me this is like way more exciting than any specific feature right uh but then again i've always kind of been like that because when people ask me like what's the most exciting feature for you of kotlin i'm like there isn't one it's just like the whole thing together that that for me gives it a good experience right yeah it just uh moves along very nicely but i think the you you kind of hit it out of the park there the the kind of migration to this new ir compiler is going to be i think a very big step just in in the way that the language evolution also just kind of moves on of course uh me i'm in a bit of a special situation because i also very much am involved in promoting carl and js the javascript target and they're building a lot of features that are specific to the ir target as well right so that could be anything from typescript interoperability um to new support for incremental compilation there um just a whole bunch of of new things yeah and uh also you work quite a bit with react uh kotlin react right which is yes exactly so we add that yes and then then i i helped you add it and then i helped uh write the code which i added um okay i was just gonna say who helped me add it you don't have to take all the glory for it i'm sorry but anyway talking about the future let's talk about the past so beautiful segway there what a segway yeah exactly what is your background to jetbrain set yeah so when when i i first after you kind of were born i don't want the whole story kind of thing oh okay then let me let me fast forward one day i was at jetbrains and at that point uh i was i was working in uh marketing uh specifically targeted towards uh education so working together with universities um communicating with professors trying to um get them to use for example intellij idea but of course also uh kotlin which yeah is also becoming i would say more and more popular uh in kind of the whole education background i've kind of moved a little bit from this now but even as a developer advocate i would personally still say well i'm kind of a teacher i have the same i also need to communicate to people the different structures uh all these kind of things yeah and talking about education we have an awesome video that our colleague exxenia shinowais has been working on who's marketing manager for education let's watch it hi everyone welcome to this video about coughing in education let's take a closer look at the key reasons why professors choose kotlin i use kotlin for everything i teach i think it makes app development much faster and much easier i like teaching kotlin because it's so concise it helps reduce common programming mistakes the ui that you can build with collin is really crisp we also use kotlin for research projects content is a great choice for learning programming from scratch it's also easy to get started we point students to the kotlin playground so they can start coding in kotlin and trying it out right away it's just as comfortable as it can be i like teaching kotlin because students get just as excited about it as i do they quickly pick up on how safe concise well supported and enjoyable to use the languages and i think it's also really great to share that fun with the students especially when i get to see their faces and they go like oh what you can do that i'm on board 100 my students really enjoy it and i think kotlin is a really great tool for education so kotlin team great work thank you very much [Music] and we're back did you miss us well unfortunately yeah you miss me yeah you've been here the whole time oh yeah oh sorry i switch every time we go offline oh i was looking at twitter oh my god well um unfortunately uh we xenia couldn't actually join us for a live interview right now which we had initially planned however the good news is that uh if you are interested in in the topics of the video uh she currently is available in the youtube chat and is answering your questions over there i'm i'm just thinking seb you know if sensex and you're going to join us maybe we should discuss git i that seems like a dangerous thing to do hardy hawaii i mean it's not like uh i've been i've been i'm all rallied up right i've been i've been discussing git on twitter for a couple of days uh yeah but yeah yeah now let's let's let's let's forget that but uh folks if you want to learn more about education uh go to kotlinlang.org which xenia has been doing a lot of work in the area of education and getting folks in the at universities at colleges at schools interested in using kotlin as a first programming language and it's very impressive work uh she has probably one of the biggest google sheets i have ever seen and we all know that a good project starts with a big google sheet or an excel sheet or that we don't discriminate or numbers does linux yeah there's open office thing right yeah let's talk about linux no anyway talking about ways to interact i love the way how we just do segways without actually being related to what we're talking about right yeah but that's how that works exactly so let's talk about ways that people can actually reach us yeah because this is actually quite an interactive segment even though it's a live stream and it really feels like it's just us talking to you you can actually talk back um we have the chat right next to the stream here on youtube and on the event page you can of course ask us questions uh on twitter using the hashtag kotlin14ask and yeah after go ahead without the dot without the dot i don't think twitter supports dots in in hashtags oh okay well learn something new every day sorry go ahead someday you'll become a social media expert oh thank you thank you what i aspire to see i'm trying right i'm trying to start off controversy and yeah and you'll get there yeah but after each talk you're going to have short conversations with the questions that you folks are going to be asking right so make sure that you do start asking that and we've got something special lined up at the end of each day right seb what's that yeah so we'll have a larger discussion panel with all the speakers of the day um but we'll just try to get through as many of your questions which have been uh asked beforehand or which not could have been answered in the in the short q and a sessions and the best part about this because some people have also asked about this in chat already there are options for you to win small prizes here as well so you should definitely start submitting your questions apart from that on the event page we also have quiz quest so quiz quests are a set of questions for each talk that will follow throughout the whole event um on october the 26th we're gonna raffle off um a bunch of different uh kotlin swag to the best answers so especially the important part is make sure to register with the same email address for each quiz and you can win t-shirts you can win bottles you can win backpacks the exact ways of how this is determined i think will either be found on this page or will be explained by alina who will join the stream on day three awesome so let's give more way to kotlin content and the first talk is coming from igor tolstoy who's product marketing manager in kotlin and you've seen this question in the chat how can people contribute to kotlin and it's almost like we had anticipated this question igor's talk we'll talk exactly about this topic so let's enjoy the talk hey my name is igor i am the head of product management in kotlin today i want to talk about curtin community and its incredible power i joined the team about a year ago and i'm still amazed by it all in particular i've been amazed at how the development of the language is influenced so much by its users one of my favorite stories is about how the support for generics appeared in our objective-c interop last april kevin galligan sent in a huge pull request which added support for generics in kotlin native we didn't immediately include it in the release at the time though we'll have the option of enabling it with a flag as it turns out though the community loved the feature so in 1.4 m1 we officially released it when i was preparing for this talk i realized that kevin is the best person to tell us about his contribution story so the question is why do we contribute to kotlin at touchlab you know we're doing a fair bit of work with square to improve the kotlin multi-platform ecosystem and one of the first things we talked about was kotlin swift and objective-c all have generics in their language but you can't get uh the generics output when you make a kotlin frame into an xcode framework so i reached out to the native team we discussed the issues primarily you know they're very different languages so so there's going to be some problems implementing generics but we went ahead anyway put it in as an experimental flag and then people liked it enough that recently it became a default option so now you get generics in your output so we as an org spend a lot of time working in the field with companies actually doing stuff in production and that gives us kind of a unique perspective and very quick feedback that we're able to contribute and ultimately our goal is to make this platform as huge because that's we're we're basing our business around it and that's you know so that's why we're contributing back to the platform and kevin is not the only one who makes the kotlin ecosystem huge the community has been kotlin's main driving force from the very beginning 800 that is the number of pull requests made by tashiaki kumiyama our most active github contributor and that's a hell of a lot of pull requests every week he fixes a few more bugs than people from the community have reported and improved the lives of thousands of people by doing so but making pull requests isn't the only way to contribute to kotlin users can also actively help us to improve the quality of kotlin by submitting feedback and bug reports for example here are the top 5 bug report authors in our utec issue tech since 1.3 release thanks to them we've caught and fixed a huge number of issues my personal focus in our team is to make kotlin shine on the platforms you work with it i want your developer experience to be great while using kotlin i am a developer myself like literally anyone in kotlin team so i know that there are some challenges that no one can solve besides you and this is where i desperately need your help so today we will talk about how you can contribute to kotlin help the ecosystem and solve your own challenges i think that those of you who have been working with kotlin for a long time have all faced situations where new features say in objective c interop are not working as you might expect just imagine you update to a new version of kotlin but instead of enjoying performance improvements or playing with the shiny new features you spend a lot of time setting dirty hacks to fit your specific scenario i am sure that it can be very annoying i know that feeling all the features that we make go through detailed analysis and design meetings are tested on non-users scenarios and are discussed with the community but each project is unique in its own way which means that we may miss some cases that are crucial for you the best way to avoid this is to give your feedback to our team as early as possible to make it easier for you to do so we release early access preview versions of kotlin called eaps this allows you to install it try it in your own project look out for bugs and report them to our team one recent example is a problem found by jake walton in 1.3.60 when he found out that there would be many changes related to captain the next release he decided to run a set of tests on his project which uses capped heavily as a result he discovered that the changes caused that built to hang for an indefinite period of time the problem was quickly reproduced and explored by our technical support team they found out that the bug appeared because of the new type inference system and was specific for very large maps the problem was fixed in just three days which is you know pretty fast for a programming language and the next scotland release was working correctly it is very easy to install ap versions in your ide just go to tools kotlin configure content plugin updates and select a proper update channel type and from now on all of uni features will be scotland ap versions if you want to use aps in an existing project you should also modify your gradle files we have described the algorithm on a special page so feel free to check it out it is available in the description of the video if you encounter any bugs or other problems in an eep post them to our utec issue tracker all the new tickets are carefully reviewed by our technical support team they will reproduce the problem asking for additional information if needed reduce it to its essence and pass it on to our development team we try to fix bugs in eap versions as quickly as possible because at this stage changes in the code base are all still relatively easy for us to implement if you want to simplify migrating to new versions of kotlin use eaps it's that simple but i also want to share with you another life hack that gives you the opportunity to influence the language priorities at an early stage each of you has unique experiences from developing your own projects with disparate trials and challenges and the experience is very different from what our team has the job of a product manager is to learn about your experience and take it into account when designing and prioritizing new features and plans user interviews help us learn this information and that's how they work someone from the product team calls you and asks a number of questions about your development experience your approach to solving web tasks and the specific details of your projects the result of these interviews is a list of insights about about your pains and needs and sometimes even a cool case study that you can share on our social media channels let's look at an example recently we conducted a series of interviews with developers that are working on large coding gbm projects many of them still have a relatively huge java code base we've learned a lot of interesting things from these 30 interviews particularly about how development productivity is affected by the quality of some ide reflecting features in a multi-language environment for example inline and change signature refactorings this knowledge led us to increase the priority of improving these refactorings and moving them up on the roadmap the experience is important to us if you are interested in sharing it with us please leave your contact information in the form by clicking on the link in the description of the video when the time comes to investigate a problem relevant to you we'll get in touch and conduct an interview the more experience you gain the more unique problem-solving knowledge you have at your disposal which library to choose for working with websockets in android how to properly organize bulk requests in spring what part of the code base to move in the actual declaration including multiplatform mobile at some point or another you may have had the desire to share this experience and knowledge you've gained with the community to help other people with similar problems let's see how developers usually solve their challenges at the moment when a developer faces a problem they usually start looking for a solution directly in the tool or in the code base if the ide or compiler doesn't have any suggestions the developer goes to google where they end up either in the documentation or in some third-party content for example in articles or maybe on stack overflow if they can't find the answer there they proceed to the next level and ask questions in the community channels for example in slack on telegram or somewhere else if no one from the community can help our support team come in dive deep into the problem advisor workaround and pass the problem on to the development team at the second and third stages of this process most developers start to look for help on stack overflow so when you want to act on your desire to help other members of the community the most effective way is just to go there by answering questions on stack overflow you help not only their original author but also all the people who will open this page afterwards and there are lots of them i'm very glad that we already have so many active contributors on stack overflow here is just a few of them they're awesome but there are still a lot of areas where you can help with where you can share your knowledge 36 percent of stack overflow questions are not marked as solved and 20 percent have no answers at all so head over to stack overflow select the text that reflect your experience like kotlin spring gpa or maybe multiplatform and help other people benefit from your expertise by giving them helpful answers it is really cool to be a programmer unlike many other engineering professions we can increase our productivity not just by using professional tools but by improving them ourselves there is a famous voice code rule leave your code better than how you found it the same approach can be applied to your work environment leave your tools better than how you found them these contributions may vary in complexity from sharing new usage statistics to developing new libraries or creating a video course each contribution makes your tooling and community better which in turn helps future you it is very easy to cross off the first item on this checklist let's see together how to do it about eight percent of kotlin developers share anonymous usage statistics with our team increasing this number is very important for us as it helps us make more correct product decisions let's return to the topic of tooling quality in mixed calls in java code there are lots of various refactoring features in idea so it's not completely obvious where to start we answered this question with the help of feature usage analytics which showed us the frequency with which developers perform actions we combine this data with our knowledge of specific problems and their importance and as a result we were able to create a good balanced list of priorities to help us improve the accuracy of our priorities list just follow a couple of simple steps it should take no more than 20 seconds of your time so just put the video on pose open idea go to settings appearance and behavior system settings data sharing and click the checkbox there done okay well maybe we can't call something that requires four clicks easier but i believe that you were able to handle it thanks and that's it and i hope that after it you'll cause some other items from this list as well when we started working on kotlin our main goal was to create a tool that would increase jetbrain's own productivity and enable it to make its products more efficiently than with java koslin's development process was open source even before the official release and we got lots of feedback from outside the company this included feedback from android developers who tried kotlin but struggled with the fact that it didn't work in their projects we iterated on that feedback fixed some of the problems and made sure that kotlin worked for them as well and the community saw this they started to use coursing for their tasks they migrated their unit tests to cortland as well as individual product features and even entire applications i also worked in a mobile development team that adopted kotlin even before its official release and i saw how much better our developer experience was because of it besides apps the community started to create lots of useful coding content from inspiring blog posts to video tutorials great earlier the folks at google started to receive more and more questions from the community when will we support kotlin officially how can i use cotton in production look how great kotlin is and many more the number of questions coming from the community and kotlin's adoption in the industry both got to such a level that google decided to add kotlin to the list of officially supported android languages but there was more the community began to develop so actively that in the first year after the announcement the number of professional developers on kotlin increased six-fold and another year later google officially recommended the kotlin first approach for android application development and it's all thanks to you the developers my role on the team is to listen to our users learn about their usage scenarios and paints that are important and help to make the developer experience great i am committed to this so feel free to save this email which i check out daily if you ever want to complain about something or tell me your story but you don't want to use our other feedback channels i will be happy to handle a request myself the evolution of kotlin would be impossible without community participation and feedback you are what made kotlin first the preferred language for android development and now the general purpose solution for so many platforms i am looking forward to seeing what wonderful things we can do next together stay in touch and heaviness scotland [Music] it's almost like we invented local teleportation because he was just on stage and now he's here in the studio with aseagor thank you so much for joining us uh thanks for watching my talk so it was really inspiring to just kind of see all the stories of the community giving back through so many channels which we kind of mentioned a little bit before and as well from issues to to pull requests right to trying out eap versions [Music] um can you please repeat the question no i i was just saying it's it's very nice to see how many different ways the community finds to to give back to us in in the form of yeah different types of feedback yeah that's really the thing that fascinates me in working on kotlin it's um [Music] you you really can feel how many people use the product and uh you can get their feedback anytime you want so it's really great for a product manager it simplifies my work very much i have to say that actually as someone who sat in on a couple of the user interviews it's always very refreshing also to see how open uh people and also different companies are in sharing their pains and sharing the ideas that they have and having this kind of exchange with the community i think is is something that's super productive [Music] yeah yes because we use uh we use user interviews as a well as a primary source of insights on what is good and what is bad in the language so yes the openness of our community it's really great well as someone actually commented on youtube they said to think about the fact that even a code language has a product manager uh it is just awesome which it is and as product manager you've conducted a lot of user interviews right what is the general feeling that people have in regards to the language um well you know a good product manager habit is to ignore all the compliments that you may have but instead focus on user paints problems and frustrations so uh i often see not only good things but when you fix such a pain point you got so much love and great feedback that it becomes impossible to ignore it and sometimes i ask users a special question like what do you feel when you write kotlin code and my favorite answer here was that kotlin gives you well a feeling of ripeness you know when everything isn't is in its place and you feel uh the childish joy when everything goes as you intended it uh to be so i often hear such answers and i can i can say that developers well love kotlin and as i already told you it's a great personal motivation for me to work on a product that people love and value so much so just for the record is it also correct to say that from now on i will never ever give you compliments i could just tell you the pains like are you okay with that well uh i think that you did it from the first day we met you see i know how product manager should work there you go that's that's the thing right yeah because i knew you're going to ignore all the compliments uh nobody go you're doing an awesome job now don't ever say i don't compliment you oh thanks you too well i think the the childish joy that that you you brought up there is is a really good point and this probably also how i would describe the feeling you know i i said beforehand that that call it is my one true love and it is it is this childish joy of just seeing things fall into place and work out nicely and just being happy with the solution that i haven't found anywhere besides uh kotlin but you you mentioned how much the community is is giving back now maybe some of our viewers at home uh are inspired by this as well now i really hope they are so for people who have not given back to the community before who've maybe only experimented themselves or built their own uh projects how would you recommend that people start uh giving back or helping in the kotlin community well i am a fan of quick reinforcements so i would suggest to start with the most simple thing to enable anonymous usage statistics sharing open idea go to preferences appearance and behavior systems settings all the data sharing and click the check box there wow well you can see that very subtle i'm not very good as a product manager in you know building uh user journeys well uh it's a simple but uh very important thing that will help our team the second step is to help other people just go to kotlin slack or stack overflow with cotton tech and help people in things that you're really good at and i believe that anyone even if you are not an experienced programmer and you started recently you already have something to share because you already have solved some tough challenges so i think you can help many people by doing so and uh the last thing is to participate in oktoberfest but not by you know making pull requests to kotlin telling us that scotland is an awesome language but there are really so many libraries out there with so many issues that you can go and solve that you will easily beat those five pull requests uh get your t-shirt or plant a tree and help many people by doing so there's also if i'm not mistaken uh we have the up for grabs tag on youtrack which is kind of issues uh mostly bugs that are simpler for folks that aren't familiar with the code bases and and a good starting point for them to actually contribute code right yes uh and most of them are consolidated around id problems so when you fix such a thing you will you will see the immediate feedback so it's you can help your yourself it's great and we have a question from mido that says since the kotlin roadmap is now public can someone contribute externally to one of your upcoming features in the plan and and what would be the process for this um well there is no some established process here i think that you can follow the general rule with up for grabs tickets and some of them may may help one of those tasks in the roadmap probably in one of the next iterations of roadmap we will also add some kind of community help section where we will highlight major things that community can help with but it's an upcoming class okay maybe one kind of small question to still round it out we've heard how people can uh contribute if they're just getting started but if you had a way that people should contribute the most what area do you think is maybe underserved uh well i i still believe that it's an area of helping other people because um there are if you saw the beginning of the keynote i show the usage numbers of kotlin you see that our user base is uh it really grows with uh with many people joining us in the last year so more people more questions more problems and we really need the help of community to to help them and to answer all of their questions because our support team is only six people and we can't well we can't solve all the requests so i think it's a very big area when where anyone can contribute well uh you've you've heard it here probably not for the first time and not for the last time if you want to contribute answering questions is probably the right way to go about this well thank you so much diego for joining we'll see you later in the big q a as well um yeah see ya take care igor so uh coming up next uh is a talk from sled lana izakova uh who's the developer advocacy team lead for kotlin which means she's actually both hadis and my boss right honey oh yes so uh we're going to yeah we're going to get into this in just a second uh just a short reminder again to put your questions in the chat for our discussion afterwards and of course to pay close attention uh so that you'll get a lot of questions correct for the quiz where you can win a bunch of cotton swag for now let's enjoy the talk hello everyone my name is ilani sakama and i'm a developer advocate in kotlin today we are going to talk about new language features in the kotlin 1.4 release this release was mainly focused on quality and performance the there are many tooling improvements and as you know we're actively working on the new compiler one of the important part of the new compiler the new type inference algorithm we are going to discuss a bit today we are adding a bunch of new features to the language that we hope you are going to like and use some of them were expected by the community for quite a while like same conversions others like trailing commas are small but really useful let's start with time conversions for kotlin interfaces sam is an abbreviation for a single abstract method if you define an interface with only one abstract method that is called sam interface you often want to pass a lambda or callable reference when an object of same interface is expected the ability of doing that is called sam conversion starting from the very first content version it works this way with java interface if you have a method run action that takes the action interface as a parameter in kotlin you can pass a lambda instead if you try to convert this java code to kotlin however you'll get an error an official recommendation recommendation says please try to use function types instead conceptually you should have taken a function type as a parameter not an interface we had a request to fix that which was created five years ago it says that okay we understand that sam conversion only works for java interfaces that is by design that everyone should use function types instead but that is inconvenient this issue got loads of votes and comments and we've often had a request to fix it in cotton 1.4 we're introducing the concept of functional interfaces to address this be aware that we're introducing a new combination of keywords fun interface you need to add the fun keyword before an interface to make some conversions possible for it then you can pass a lambda instead of this interface but this trick only works with functional interfaces you may be asking why have we introduced this special extra keyword and not simply allowed using in all interfaces with one method by default for some conversions a part of cotton philosophy is that we want your intentions to be explicit if you have an interface that is intended to be used for some conversions to pass lambdas instead make it explicit imagine you define an interface with one method and someone uses it for some conversion but it wasn't your intention now you're adding another method and the usages no longer compile with the functional interface you see the error immediately when you try to add a new method but most importantly you decided to make it a fun interface and you can't change that and break usages accidentally now it's time to finally get rid of java interfaces in your code preserved only for same conversions now i want to discuss another topic related to the philosophy of being explicit we are introducing an explicit mode for library authors the kotlin style guide contains special recommendations for library authors an additional set of rules to help to ensure api stability the first recommendation is to specify member visibility explicitly that prevents accidentally exposing an internal or private declaration as a part of the public api imagine you define a function in your library and it's obvious from its name that it's a private function and you don't want to expose it to external code however you forgot to add a private modifier and now it's a part of the public api and it's impossible to revert it without breaking someone's code if you follow the rule that you always specify visibility you are protected from such mistakes you can't forget a modifier and expose something unintentionally another recommendation is to specify function return types and property return type sorry property types explicitly for a similar reason to prevent breaking the code by accident for example you define the get answer function and allow the coding compiler to infer its type it's string maybe then you decide to change a minor thing in the implementation to replace the string 42 with the number 42 and with this change you break the user code the usages assume that the type is string but now it's any and you only learn about this breaking change from the complaints of the users later on for libraries this is unacceptable nothing should break unexpectedly without proper warnings and immigration support to prevent such problems we recommend always specifying return and property types and that is exactly what explicit api mode is doing before 1.4 these recommendations were only written in the style guide we assumed that it's a good idea to follow them but now both these recommendations can be enforced by the compiler you compile your code in explicit pay mode and the compiler forces you to specify visibility and return types for these functions you can decide what's more useful to you when these rules are violated to get errors or warnings you can see different settings for kotlin and groovy gradle scripts you can also specify it as a compiler option explicit api mode is mostly intended for library authors however if you find it useful for your project for example for some of the modules please use this functionality now let's move on to the next topic which is extremely useful following many other languages codliner supports trailing commas imagine you see a list of elements in the code and you want to swap the last two elements you try to use intellij idea functionality to swap the lines but you get a compiler error because the last line doesn't have a comma trailing comma solves this you can now put a comma after the last element in the list then swapping works fine as the code compiles when you type the argument you don't need to decide straight away whether it's the last one or whether you'll need more if you don't like how it looks you don't have to use it it's optional we don't force you to start using shelling commas everywhere you can also put a telling comma after the last parameter of a function or class declaration note however that you want that if you want to refactor a function or a class declaration we recommend not swapping the lines but rather using the change signature automatic refactoring provided by intellij ideo android studio when you use change signature all the usages are correctly modified for you you are protected from forgetting to swap the actual arguments especially if the types are the same so please use automatic refactorings kotlin 1.3 for bids using break or continue inside when if you try it you see that the compiler suggests using labels a workaround exists you can label the outer loop and then append this label to break or continue but that's inconvenient we wanted to reserve break and continue inside when probably for some logic related to the one expression but it turned out that usage with relation to auto loop is expected by everyone so now these usages are allowed you can use continue or break inside of an expression is then bound to the outer loop the next topic i want to cover is mixing named and positional arguments in kotlin you can specify names for the arguments and that's sometimes really helpful if the argument is the number or another basic type or the expression type is not obvious specify the name in some cases however it's kind of redundant in this case you see that it's a color and you don't need to add the name kotlin 1.3 doesn't allow you to mix named and positional arguments formally you can mix them but only add named arguments after the all positional ones and in some cases it's not enough so we fixed it in quantum 1.4 if you use every argument in the correct position you can give names only to those arguments that needed them for clarification the next topic i want to discuss a bit is the new type inference algorithm you already know that we are rewriting the kotlin compiler and many of you have already used the new top inference algorithm that was available for you to try it's a more powerful algorithm we've written from scratch that fixes more than 300 existing issues it supports functional interfaces in first type and more use cases and brings benefits to more complicated scenarios i will show you a couple of cases to illustrate that mostly you'll notice by yourself that some of the code that didn't compile before now compiles you can avoid extra type costs and so on let's look at the first example here we define a map in cotton 1.3 the compiler doesn't infer the type of the lambda argument but if you look closely at this code this type becomes kind of obvious for you string is key in this map and the type of lambda is a function type that takes an elbow string as an argument and returns boolean that means that the type of the lambda argument is a nullable string if it is obvious for you then why is it not obvious for the compiler it wasn't supported but now it works the kotlin compiler infers types correctly in this and similar more complicated scenarios another case when kotlin starts to infer types in a tricky cases is when the last expression in the lambda is smartcast in this example the string value is smartcast the coding compiler understands that it's not now however before that the type of result was a nullable string now it's an ordinary string also you can use callable references in more complicated cases you can use reference to a function with the default argument value as of different types for instance you see this function 4 that takes an integer parameter and returns string and you use it as a function reference that takes in and return string but you see here that the foo function defines the zero default value for the parameter now we can also interpret this function as a function that takes no arguments and returns string in cotton 1.4 you can pass such a function reference to the apply function that expects a function without parameters then the coding compiler correctly uses the default value you pass a function reference and the codelink compiler understands that you wanted to use 0 as the default value that's really helpful in many scenarios there are many other similar examples when the type inference algorithm infers more powerful types i've just picked several to illustrate the concept that this algorithm is smarter now the next feature that i want to cover is unified exception type for null checks it's not a new language feature that you can use somehow in your code however i want to mention it and explain it so that you won't be surprised if you see another exception type for nullability issues different operations in kotlin such as two exclamation marks typecast platform type expressional checks parameter tab checks they all related on to nullability currently they throw different types of exceptions like codelineal pointer exception or in some cases legal state exception with helpful messages and cotton 1.4 replaces all these types with the regular null pointer exception note that only the type of the exception changes everything else remains the same all the all the exceptions are thrown in all the same places they were thrown before no new exceptions are added no old exceptions are removed only the type has changed for instance in cotton 1.3 after additional nobility texts you could get an illegal stat exception with a message like this expression must not be null in coding 1.4 it automatically becomes nullpointerexception but with the same message as before you shouldn't normally get these exceptions in correctly working applications so the behavior of your program program shouldn't change why did we make this change it makes possible future optimizations right now we don't do any optimizations it's something to be implemented in the future by the coding compiler or by the android or 8 optimizer this optimization is especially important for android the goal of this optimization is to decrease the number of checks in the cases when they are repetitive it turns out that very often the checks are generated on several levels and they all check whether the same expression is not null when you check the same condition several times it's possible to merge the checks and to check it only once instead if the type of the exception is the same it's null point reception everywhere that can be done because it doesn't change the program behavior of course after this optimization some messages can be lost but that's the price to pay for to for making this optimization and to and for eliminating some of the null checks note that it is something to be done in the future but i wanted to emphasize that we've changed the exception types i want to talk about generating default methods in interfaces it's still experimental and we've had support for it before but we've made some changes and i want to highlight what exactly has changed in kotlin from the very first version you've been able to define default methods and interfaces this even works with the java 6 target but as you know only starting from the java 8 target methods with implementations and interfaces are supported in the jvm bytecode kotlin has a special trick to make it work for older java targets it generates an additional static class inside this interface that contains the implementation as a static method then when you extend this interface the kotlin compiler automatically inserts the average method that only delegates to that static method defined in an additional class and that works for java 6. but for java 8 when you already have the jvm support for default methods most probably you don't want this overhead of an additional default impulse class starting with kotlin 1.2 we provided an option not to generate default impulse implementation but rather use the jvm support for this method you could use a special option set jvm default to enable and annotate each method of an interface with the dvm default annotation then no default impulse class is generated the default methods are used in the bytecode in fact you could use one of the two modes for the java 8 target the first one which i've shown you generates only default methods alternatively you could instruct the kotlin compiler to generate both default methods and default impulse classes you might have needed that for compatibility reasons the second mode is often used by library authors that evolve their library and shouldn't break the code that depends on their library you had to annotate each method with this duvet default annotation now we've we're changing this approach a bit and we don't require you to annotate each method with animation because it's kind of a brush you need only to specify one of the two modes when you compile the code but no additional addition is needed in kotlin 1.4 there are two new modes for generating default methods in interfaces for the jvma target the old ones are deprecated the new modes are very similar to the previous ones there is a mode for generating only default methods and another mode for generating both default methods and default impulse classes for compatibility reasons the only difference is that the dvm default annotation is no longer required you can compile the code in jvm default all mode and then no default impulse classes are generated under the hood and you don't need to use the previous dvm default animation currently these two modes are in an experimental state but they will be used by default in future major content versions first the compatibility mode then the mode that generates only default methods you can read more about generating default methods in interfaces in the kotlin block it explains the topic in more detail including an additional geovamp default without compatibility annotation which i haven't mentioned check the documentation page what's new in kotlin 1.4 it contains many details about the features in the release including the topics that i've covered in this talk thank you for your attention and have a nice cotton thank you everyone for joining us on this kotlin 1.4 event and we are continuing after this wonderful talk of new language features in kotlin 1.4 we are joined live now with not only sveta sakawa but also star serokin who is development lead for kotlin hello stars hi sveta hi honey how are you both doing today we are fine watching the costume 1.4 event you know how it's going how good it is all this pre-recorded talks don't look at me don't look at me as they say so we've got a whole bunch of questions for you and uh i think seb you're going to start it off right because there's some very interesting questions sure um we're going to start off with a question from uh tam i hope i pronounced that correct um i wonder how the kotlin compiler plugin will evolve uh do we have an estimation for compiler plugins for all platforms yeah i see well basically the story behind that is uh it's at even earlier stage of our back entire project when we rewrite all the compilers from the scratch we thought about compiler apis so you could just create a plugin and plug into the whole process and this plugin would be available for all saved platforms and so on and so forth but right now we are in the process finish our ir backends and we are focused on that firstly so after that work we will continue work on compiler plugins for okay that makes sense so another question will suspend work with functional interfaces uh single with functional interfaces single abstract methods it's better it's coming yeah this question like if someone uh doesn't get it we invited starts to actually answer all the questions about the team plus and how it's all doing but some things i can share and with this thing i think stars can provide more details but uh surely it's uh it's on the way yeah basically for some platforms it already works but for jvm in some cases it do not work in 1.4 release and we are going to support it in the future uses but unfortunately we cannot enable it by default until 1.45 because it's the language change but basically it is going to be released 1.5 so it'd be available under the flag a bit earlier yeah under the flag it would be available earlier but i'm not sure that it's good practice just enable some compiler flex okay um well we have one more well less of a question more of a comment by alexander who says trailing commas don't work in a build gradle kts file though have anything to say to that yeah i have like feeling why is like that it's basically i guess because uh gradle uh have well have some cotton embedded into that and it could be not 1.4 so for example if gradle uses 1.3 then australian common do not work there because they are not supported in that version of quartz so the advice here for people is to just keep updating their gradle version in the hopes that gradle will also provide support for 1.4 soon start by writing gradle forks with comes down please update cotton version very good yeah you got to find the product manager for gradle and start attacking them just like we can um ping your on twitter and say that yes this doesn't work fix it kotlinlang.org exactly so i know that you covered this in the talks better uh but for folks that maybe have missed it or didn't uh fully understand why would you use functional interfaces instead of lambdas directly so this i've covered in the talk that you why you would use uh this fun keyboard for interface and that's for compatibility reasons and uh uh with the functional interface with the uh lambdas the whole idea of functional diffuse is being able to use lambdas so it's like this question is not uh like it's better to talk to the person who asked it uh to to to to get what they were asking okay fair enough but i've got another question for you and this one is extremely extremely difficult okay so you're gonna have to take the time to respond to this right uh john moore asks sveta when can we expect a second edition of the kotlin book kotlin in action uh i respect real time uh it's complicated yeah i think that uh most of the folks uh who ask this question they uh they want to uh know what uh one will be the addition around core routines and uh the corrupting content is huge content uh to cover that we have some plans about it but most probably we don't wanna add it to this book and updating it everything except qualities does really make sense because we can just read content action and then read all this what's new in 1.2 what's new 1.3 what's new in 1.4 pages and it will be enough so we're working on it we're working on the some new materials but most probably they won't be uh what to say uh owned by uh other companies and we'll we'll try to produce the content and own it ourselves so that to make it free and available for everyone yeah and also i mean you know uh roman does seem to write a book every day on encore routines and serialization and everything else anyway so like there's so much documentation uh out there already uh but you know kotlin in action was an excellent book but it still is so i i'm not surprised that people want the second edition is like kotlin action part two done i'm done okay yeah my job's good i think i think that's a good point though um thanks everybody uh for yes go ahead and there is the another question is sorry i also have this access to our spreadsheet with questions what's the benefit of financial physical type dev and i think that uh initially there was the idea that uh type aliases actually cover all the our use cases and we don't need these fun interfaces at all but uh in the end uh it turned out that we're still uh there with the language and mostly you can't inherent it's like you can't define your functional with typedef you can't encourage the functional interface so there is uh there is just another name for type for functional type or some other uh other but it's uh it can't be specific and you can't encourage from it so do you want to join or do we want to add something stashes like that it's all good who submitted this question uh you got lucky that one got almost squeezed in but of course if there are any other questions remaining we will do our best to tackle those at the end of day q a for now i want to say uh bye and thank you to uh stars and sveta right yeah thank you everybody take care everyone bye-bye and go ahead my friend and we are going to move on to our next talk which comes from uh anton jalichev who is the product manager product manager for intellij's kotlin plugin just a short reminder once more if you have questions put them in the chat and pay close attention as usual so you'll get a lot of questions correct in the in the quiz for now let's jump right in and here's the talk hi my name is anton i'm the product manager for the intellij kotlin plugin my task is simple to make our products bring joy to its users today i want to tell you about some of the most interesting changes that have occurred over the past few months and what our plans are for the future once i met with a colleague to talk about the ux of one of the code editor's features and while working with the id he opened a relatively large file i'll show you how it looked he opened the file invoke the copy action for all the text and the idea hung for like seven seconds we didn't really pay too much attention to this at that time as our heads were occupied by other things and it just remained at the back of my mind but wait a moment how often do you experience seven second lags when working with desktop software i can recall other products doing this and so at some point we decided to research how much people how much time people are wasting while waiting for the id to do something the following events were considered indexing build vcs actions a file system refresh as intellij idea has its own virtual file system project import and ui lags we collected and processed data from animal statistics and this is what we got we found that the amount of wasted time was only about five percent of the total session time so don't panic but this five percent was distributed as follows indexing got 28 build 16 pcs and file system got three and four percent respectively project import got 18. ui freezes accounted for 31 it turned out that the small and not so small hang ups were some of the biggest time sinks along with this we already had a pretty good picture of how it was from our back tracker our own experience and from communication with users when it's due that we need to move our attention and focus more on things related to the performance and stability of the ide as at this point we can greatly change the situation and make the developer development experience significantly better to start with let's figure out what id features performance most affects the quality of the dev experience here we can say that there are smooth typing whatever happens the typing should be instant idea responsiveness it should be always give an immediate response to your actions code completion and highlighting speed should never make you wait for its results navigation and find usages as intentionally involved actions can be allowed a bit more time to be done but still they shouldn't break your development flow indexing well it depends on the situation i will talk about two interesting approaches how we work with indexing times let me walk you through our results step by step consider the code completion speed last year we were focused on algorithms and based on the anonymous statistics this situation looked like this only seven and a half percent of cases went beyond an interval of half a second we didn't stop there and continued to optimize it by the time of 1.370 it was already a different picture as you can see the response time has shifted into the instant execution category some of you might ask why did i choose this categories well performance is a rather vast and complex area the scientific world contains a lot of research about people people's perception of response time let me give you some average overall findings if you have to wait for 100 to 200 milliseconds then it's perceived as instantaneous if you have to wait for 500 to 1000 milliseconds then this is an immediate response and you completely keep your attention on the object the next interval is between two and five seconds it's called a continuous reaction and you perceive it as a series of events but still in a single process and if you have to wait for seven to ten seconds this is the last border where you can still keep the context of the task in your mind after that you gradually begin to lose it in reality these intervals are used for more complex calculations but here i will keep it simple and use them only for grouping in addition to speeding up the code completion we organized incremental cash management this means that in some cases id the id understands better what indexes need to be reject and does less work it reduces latency when typing and speeds up code completion and highlighting this is what happens for example when you write inside a function with an explicitly declared return type the outer cache remains the same also the module responsible for java and katlin interoperability has been partially rewarded this has accelerated many performance components in case of cross-language code interaction by the way it's worth noting that performance is generally perceived relatively it means that there is some kind of baseline that a person considers as a standard let's take for example code completion in gradle.gts files sometimes to give you proper suggestion the id needs to interact with gradle and sometimes even get data from the internet it takes time and you would be ready to wait if you interact directly with the gradle through say command line but in code completion the same work is expected to be done faster generally we agree with that in releases 1372 and 1.4 we work together with the grail team and our intellij idea colleagues and rework the mechanism of interaction from all sides so now code completion in gradle.kts files looks much better in terms of speed and yet we still need to improve a lot a significant part of users goes beyond one second another example people who have come to kotlin from say c plus plus or who have learned it as their first programming language they perceived the performance differently than people who have just come from java or who periodically work in a java code base here our colleagues have set the bar high and what we are going to do about this i'll tell you in a few moments together with the intelligent platform team we worked we worked on the code highlighting algorithm and in this case we did not increase the processing speed by much but we made its appearance more consistent and meaningful we actually can affect the user's perception of time passing while they wait for something in the beginning we show only the most basic syntax information so you receive it much earlier than before the calculation of less important data occurs right after take for example our benchmark tests that we run on space a relatively big multi-platform project space is an integrated team environment that we use inside jetbrains and is going to be released this autumn so the benchmark test showed that the basic highlighting time for files opened for the first time in the session was halfed another representation of the data is a chart that shows us how the highlighting time has shifted towards the desired group this improvement came with intellij idea 2020.1 also this benchmark test framework is available in the cotton plugin repository you can use it say if you still feel that code highlighting doesn't work quickly enough this framing framework will show you what files have their longest highlighting time and you can collect additional diagnostic information from them and send it to us it will help us a lot with the future optimization well once i saw a meme from the movie interstellar where the two main characters go to a planet with a different gravitation field and one of them says one hour here equals seven years on earth the other replies great then i will wait here for intellij idea indexing to finish yes our community has a good sense of humor as we recall from the study i mentioned above indexing turned out to be a big-time thing how can this be solved the procedure is really heavy and long in the intelligent idea 2020.2 we introduced shared indexes which promised to reduce the time spent on project indexing by up to 75 percent the bottom line here is that you don't need every computer to process and index the same external project dependencies or all of your common project if you are only working on a small part of it the system gives you the ability to create local storage for the indexes as well as to connect to global storage where for example jetbrains keeps indexes for ddks to set up this feature for your project read the instructions on the documentation site it should be easy in release 1.4 we have fixed about 50 different problems registered in our issue tracker related to id freezing or excessive cpu or memory consumption this as you can see improved the performance in almost all the main points such a track reports are very helpful for us to improve id performance please create them if you have any such problems and help us handle them better please follow a couple of recommendations the ticket should contain diagnostic information about the state of the cpu or memory it can be easily obtained from the description here also it's good to describe what you were doing at what place in the file and how exactly the problem arises and of course it's important that the diagnostic information was taken from the latest version of the plugin by the way the previous case of freezing on copy paste now looks like this we opened the file for the first time copy the text and immediately pasted it where needed this improvement is also not about speeding up the algorithm it's about separating the ui and calculations if you have experienced performance issues i can't wait to see what you think after the update don't forget to update intellij idea itself as well as improvements have been made both in the plugin and in the platform therefore if you work with android studio some updates may talk may take a little longer to reach you and we are copywriting with our friends at google to shorten this delivery cycle so performance isn't the only thing our users want from us in the beginning i talked about the stability and quality of the ide i have been focusing on fixing the exception reports you sent from the id according to the anonymous statistics with each release the number of exception reports decreases by one and a half to two times in compared to the previous release in addition to this based on the same source of statistics and our issue tracker we improve the quality of the debugger formatter refactorings and other things the quality of the id can have a big impact on how easy it is to work with technologies when you are working with one of the most popular libraries carotenes sometimes questions may arise for example during debugging what variables what state what call stack a specific car routine has and the id should help you with this here we have a lot of new interesting things my colleague seva will tell you more about this in his talk yeah don't miss it also in 1.4 we introduced a new project wizard which you can use not only select a predefined template like before but also configure the project yourself you set the structure of modules and execution targets that you are interested in and the two generates the project and all the necessary code itself we kept all of the existing templates and even added a few more light editing we know quite a few cases when you just want to quickly look into some file correct one line or read a small piece of code you don't want to load the id and all its features for this your time is precious so you use third party lightweight editors this is actually a crazy story why if the ide provides so many capabilities can it now provide the simplest solution starting this year intellege idea now provides the ability to open files in a lightweight version of the editor that loads very quickly and has just a very limited set of basic features now you can use the same product in both use cases we have all the above in the cotton plugin 1.4 and intellij idea 2020.2 please update to them and tell us what you think but you are probably wondering what's next and here let me share with you our immediate plans first we are continuing to explore the possibilities of speeding up the code completion highlighting and navigation second we will also improve the responsiveness of the id by eliminating deadlocks freezes and optimizing memory consumption as well as stability of our plugin and its features third many of us work in a mixed java and kotlin code bases and the ide should not lose in its capabilities due to these circumstances probably promising problems usually don't arise but sometimes they do and require additional work here we have almost finished developing and will soon release complete cross language support for inline and change signature refactorings you will have the same live experience working in a mixed java and kotlin language base as you do when working with one language you have probably already heard about the development of the new compiler plugin new compiler front-end one of its advantages is significantly faster compilation now the content plugin uses the old front end everywhere and we are sure that by moving to the new one the speed of many operations in the ide will increase this task itself is not so fast it will be not it will not be completed before the new compiler itself is released but we are already prototyping and have some very good results generally our focus remains the same it's mostly on performance and quality the id kotlin team intellij card and team did some really nice work but i feel it's still not enough for instance the new type inference algorithm does more precise calculations so code completion gives you more accurate suggestions but in some cases it takes a bit more time so we're continuing on in this in the same direction our plans are reflected in the general roadmap of their cotton project they will be updated over time come and take a look read them and share your those with us oh yeah have something more what else can be important for improving the product besides working on the quality of features performance and new tools we analyzed our workflow evaluated our future plans and realize that the current infrastructure of our intelligent coding plug-in is causing more overhead than it could than it should perhaps someone found it's strange that i was talking about the new things in their plugin first and in the platform after all we often hear after intellij updates people ask when it will be supported in kotlin will be available in kotlin we came to the conclusion that being a plugin in the kotlin repository makes us less efficient over time so we have set a course to get closer to the intelligent platform what does it mean well originally kotlin was an independent project it determined its own path and having the intellij plugin in the language repository was the right way to go too strong a connection to the platform could hinder its development now the situation is totally different both their language and their plugin are mature enough recording plugin is moving to the intellij repo it will be done in two steps the first step which we have almost completed is a kind of joint report that contains just two of these projects the second step is to have a mono wrapper of the intelligent platform and the coding plugin how does this benefit everyone intelligent idea developers will be able to support their features for coding right away together with this the quantum plugin gets aligned with the intellij platform release cycle at the time at the same time releases of cotton language releases of kotlin language will also come out together with intelligence with id support for the new language features it becomes better for contributors you have more options for working with the platform and the intellij idea contributors can now do more for kotlin as well finally this will amplify the development of the cotton plugin previously in the cotton project i mean in the cutting code base a concrete version of the intelligent platform was treated as an external dependency where is now code and plugin and intellij platform start to be in the mana weapon and the developer is working in a single code base in such a collaboration we will achieve good results faster as it will be easier for us to promote changes such as log free copy paste or proper code highlighting order often such improvements require modification for both their plugin and their platform it kind of turns out that the improvement of id performance is determined by the development team performance and the developer performance is determined by id performance and i think our performance for today is coming to an end i hope you found this presentation interesting keep up with the latest versions of our products and share your feedback thank you on behalf of our entire team for being with us have a nice evening have a nice kotlin well we hope you enjoyed that talk on boosting quality and performance for the intellij based ides with kotlin uh joining us now again in a very virtual studio is antonio chef welcome hi so how are you how are you feeling now that uh the whole process of the 1.4 release is done yeah it looks very great yeah feeling good that's that's great to hear so anton i have a question for you uh you kind of like you've been in software development tools for for quite a while now right all right yeah so what is your background oh yeah primarily my background was in quality assurance of that software development tooling but which tools uh tools that delphi uh c plus builder nowhere delphi delphi there was a whole debate about whether it's delphi or delphi wow i come from delphi as well delphi yeah yeah do you remember intro web yes and internet direct indie components that was me as well one of the people my claim to fame anyway enough about me so let me tell you about me no sorry you were saying yeah so that was two very nice ideas yeah but uh during time you know the legacy part of that ide uh became were becoming harder to support and uh when i came to jetbrains as started to work with intellij idea you know look like quite more flexible and easy to use is to work with id so it was very nice nice feeling to feel an update great and we have a couple of questions that are actually coming in from the chat rahul asks if you have an old project how do you convert that into kotlin well you have all projects written in java probably one min then in our id we have a converter from java to kotlin that you can call and it will automatically convert java files to kotlin and uh no it's not perfect probably you need some you need to do some corrections but it uh reduces uh amount of uh routine manual work to do and uh if there is a you know if that means that there are old version of kotlin in that project then uh after you change a version in uh version of language in build file i do suggest to run some migration inspections that change code and change it to the new style so those are automatic migrations that are then just keeping your code up to date at that point yeah that's right yeah i know much in terms of migration i mean that much in terms of migration went from an old kotlin project so if you are referring to an old kotlin project that is in kotlin well an old product old kotlin project would always be in kotlin um there isn't that much of a yeah exactly right said like that it's a good point right um okay but uh anyway next question uh let's see uh oh oh this is a tough one anton this is a tough one be careful what you say here does the eap break intelligent idea i i don't know i'm assuming he's further they're referring yeah raw heater he's referring to the uh kotlin eap ah so it shouldn't because uh with uh every eip uh we provide uh id support for that new things so it shouldn't if it is if it does please provide us your feedback let us know as soon as uh as soon as possible about that exactly and that's why it's called the aap right not because it breaks but it's like we need the feedback early access program for those people that aren't familiar with what eap stands for you know we've been through this time and time again and we haven't said what eap stands for and said you were correcting me on what co it stands for and and and hears me saying you're saying eap and me not saying anything so you mentioned that early access program seb give us a question i'll give you a question from gabriel who asks why the performance on the gradle kotlin dsl or in general cotton scripting is kind of slow compared to a standard kotlin project that's easy to answer because uh just imagine the very fundamental very low level that in id interact with in case of uh teleporting files uh i did interact with the its indexing system uh which is very optimized for the quick completion showing for instance uh but in case of scripting in case of rel script id interacts with the gradle and there are some places that we cannot affect much and we still work together with the grail team to speed up them but in some places yeah i i need to run some real things and even somewhere even need to go to the internet to download something it's quite rare but there's still a couple of cases so yeah it's just a different background to work with i deal with okay that makes sense okay and uh one more question i think we have time for uh you said you've talked only about uh the improvements in intelligent idea does this apply also to android studio yes yes because as android studio is based on intelligent platform uh almost all new things that uh happen in intellij idea go to android studio it's also yeah it uh it's supplied to both products to intelligence yeah essentially the same plug-in right yes yep cool well it was great of you to join us anton and uh thank you for all the work that you're doing and uh seb it's time to give way to our next talk which if i'm not mistaken is from seb it's from roman ilizarov who's our team lead in kotlin language research once again a small reminder uh to put your questions in the chat uh for the discussion afterwards and as always there's also quiz questions for this one uh so pay close attention so let's enjoy the talk [Music] welcome to the future of cotton talk but first let's talk a bit about the history of kotlin kotlin 1.0 was released as pragmatic language for gvm and android and golden 1.1 it was javascript support was added with cartoons and more features initially you could only share code by copying it but the change in content 1.2 with multi-platform concept where you can share code and also make it platform specific with expect and actual in content 1.3 carotenes were stabilized and co-sharing entered the new dimension with scotland native opening way more platforms to cutling code and the recent release coding 1.4 was focused on quality and performance while also adding a bunch of new features of course um having a look at the history we can now talk a bit about the future the new future is easy it's our nurturant plan that's where we have a lot of uh clear picture of what we're going to work on uh as you can see from the history uh multi-platform is a big part of uh team support and we're continuing to work in this direction specifically into kotlin multi-platform mobile where we're focused on bringing sharing between android and ios uh making it easier and we need to production quality but kotlin's home where it started with gvm is still an important focus for the team we're really committed to improve culture and gvm uh which specifically means that we're committed to to kotlin's interoperability not with the existing java features but also with the upcoming features of the java language it means that for all the new java apis that are going out you can use them out of the box and all the java platform features that are library only for example like project loom will be readily available uh to the content users however uh their java is a language is also evolving and adding new features in particular javascript new records and java is adding still classes and we will be making sure that content code can interpret with those as seamlessly as with all the existing features of the java language that's that was near future now when we talk about a future feather part uh let's talk first and what drives us how do we figure out which features to work i wish this is not work what what we're looking at and the main thing we're looking at is our community because see kotlin team we're not a very big team i mean they're far more uh of you using cotton than us you know working on cotton and it's not our language it's your language it's you are the users of the language so we look at uh our slack and form charts to see what people are interested in we communicate with our big users directly to see what problems they experience with needs they have we look at you track see what issues you vote for what issues you create what problems you have and we also have key prerequisites for you for uh language enhancement and design proposals and this next that brings you interesting topic on uh how do we use utrecht versus key what's the best way uh to use them for and over time we figured out that keep uh representative works better as a storage for design documents that are worked out they're prototyped and ready to be included in the language and keep issues work best for corrections suggestions and improvements to those while for problems ideas for puzzles the best place uh to track them is through utrecht we have a special tag there called language design and whenever we encounter proposal or problem that people raise with respect to the language we attack uh it that way and uh that's how we keep track on how many people interested what's our uh ideas how that can be solved and specifically if you look at the uh languages and tech at the utrecht you'll see lots of success stories where different cultural releases we've solved problems that were really high voted and were important for many users for example in coding 1.1 we've allowed callable references with expression on the length head side and by that time that's 70 volts that's that was a big number uh for closing 1.1 in cotton 1.2 uh we've uh solved the long-standing problem at that time of our service at gvm users where it was quite verbose with annotations uh to write multiple values so we've added a syntax where you could uh do it in a more concise way um uh in colton 1.3 uh another syntactic improvement that's culturally specific will allow you to assign a variable and use it as a win subject in the same line and that was a very popular uh feature and of course uh in the most recent 1.4 release was also uh we're looking at what you you're interested in and and we've heard you and we've closed the problem with single abstract methods for culturing classes uh cotton 1.4 we've introduced functional interfaces and that was really really high-voltage issue it's actually not the only issue uh with 200 weather a group of several linked issues that were all quite big and uh we've heard you and we've closed uh this problem with kotlin so that kind of gives you a glimpse at how we work with community how you look at you know problems that he posed for us and vote for and uh how we close them so now we can take a look at a more decent future and of course disclaimer here is uh everything that i'll be saying after that it's just a pure speculation you know it's the ideas we're looking at it's not something we worked out uh in detail uh so i'm telling you just because we are as a team we're looking for your feedback what's what interests you what you like what you don't what's more important what less but you know what exactly is going to turn out will uh time will show uh to see you know we don't have to go far let's see it the most wooded language is through right now at utrecht what is that uh that's that's an issue uh which uh this title adding static accessible members to an existing java class where extension and if we just look at the title of this issue it's really tricky to decipher because it has uh in short basically it asks for statically accessible extensions which is kind of weird in cotton because if you look at the cotton documentation you'll see that all extensions in kotlin are resolved statically so what exactly is are statically accessible extensions if all of them are statically resolved um if we actually read the issue itself we'll see that the uh the issue itself stuff starts with the proposal uh let's allow this kind of syntax and it's it's uh what is that what's been asked here uh there is some third-party type like intent that the person wanting this syntax doesn't control it is coming from android in this case and we want but it doesn't have a companion so we want a synthesis where you can say but i still want to have a name and companion of this type and add an extension to this companion the problem is not only intent the instructor doesn't have a companion object the code on the right if you write an extension for a companion has to receive an instance of this companion as is receivers uh this variable but but you know we can't make this work for third party library because if different people would will be adding these extensions they will get up with a different instance so when we see a request like that when it's uh you know at least an idea but it's not clear how to get this idea implemented the question we always ask is what are you trying to achieve why why do you want this and in this particular case the answer is easy the person who asked this wants to write a type name dot extension name that's what uh they're trying to achieve they want uh this kind of usage uh they want on you side to be able to say uh use a name of serpenti type with their own extension name the syntax they proposed it was just one of ideas not they wanted to achieve is this by understanding what you want to achieve actually opens a drawer for us to to to better figure out uh how it can be solved to start we'll look at similar or related problems in the language and in this particular case we don't have to look far let's take a look at the standard library standard library has this declaration it declares object delegates with not null functions and we can ask why it's declared as an object why it's not just a top level uh not null function or the same question so what are you trying to achieve what standard library designers writing this code were trying to achieve and they were trying to achieve this kind of uh use uh site syntax they wanted on use sites to read delegates dot not know that was the intent of this code you see it's very similar to this question about aesthetically accessible extensions but uh the designers of synthetic library had to use an object to reach this goal well what is an object in kotlin an object is called him creates an instance you can assign it to a variable an object in kotlin creates a type you can do type checks for it you can declare variables of this type and also an object in cotton creates a kind of a namespace so to enable this kind of delegates dot not know usage but but see among all that we really in this case wanted just a namespace everything else an instance of type is just a library maintenance burden uh we had to add them into standard library in this case or uh the sim card uh third party libraries phase two but it just creates now burden because we now have to support this instance we have to support this type even though we never intended to have them in the first place all we wanted is namespace so what if instead of creating a namespace creating an object we can devise a syntax that would create just a namespace for example add a new keyword namespace and say now you can declare namespace delegates and it gives you just any space it only enables you to write delegates.not null and nothing else no type no instance now we take this a relatively simple idea and take it further we can see that it enables the concept of companion spaces instead of companion objects and this brings actually solves long-standing problems of making the way cotton classes compile closer to the way they're compounded on gvm makes it easier to breach java apis with static numbers because we don't introduce an instance we don't introduce a companion type here it also enables us to think about extending namespaces so instead of extending a companion instance which has a type and an instance and we are writing extension on an instance we can devise a syntax for namespace extension it might look something like this uh some pseudo syntax uh where it says i i want to write extension of this namespace to distinguish it uh with writing extension on an instance and with this kind of syntax uh the code at the right hand side doesn't have to receive any receiver it uh is just like top level function code it just and this way you get what you want you can write uh your surprise type with uh fold by dot followed by uh whatever extension you want it to have without introducing extra stuff like instances and all this complexity so it gives you exactly what we wanted and also solved all the other problems in a consistent way now let's take a look at the other big issue that also comes a lot in utrecht and actually comes out in keep there are several key issues related to multiple receivers uh now receivers is uh and functions with extension functions the unique content feature and no surprise that uh you know through evolution uh people have discovered that they often run into a situation where they they want a few of them how this happens you see and this actually the issue multiple receivers on extension function property is just one issue and there are lots of related ones it happens because content has a feature called member extensions and with member extensions you can have a class view and you can define a member extension in this class for example extension dp on the floor that's actually use case taken from the issue uh and you see in this code you have two receivers one receiver comes from the class uh from the from the extension you're right it's like an instance of a floor the other comes from the class view in our example so this extension being a member extension has two receivers one of type view yeah the other of that float the challenge in that uh you can write those member extensions in uh in uh a class but you cannot write them as an extension to this clause and this particular issue asks for this kind of syntax let's uh comma give a comma separated list of receivers and write an extension that's uh that's what this particular issue suggests uh if we also look around we'll see that people uh ask for a syntax like this where they want to separate receivers or syntax like this where additional receivers are given a simplicity parameter there have been lots of over time lots of suggestions of what syntax might look like but none of those syntaxes look specifically kotlin because they don't resonate with any existing syntactic tradition in cotton they just you know take it from other languages or just invent it on spot and uh so let's try to find what could be a better looking content syntax for this feature let's look for syntactic analogy and here syntactic technology is how we bring a receiver into scope and content and we bring with a standard library function with when we write with view uh in the curly braces we have now additional receiver uh that is view and we can use these extensions so that would be our best syntactic technology for multiple receivers in kotlin so by taking this idea we can devise a syntax looking like this where you have a function that could be an extension function and you add additional receivers by saying that it should be called with a view and scope and starting with the simple idea that you can add receivers with with modifier we can actually take it further in a completely new dimension uh which interacts well with other calls and features like inline functions how is relatively like online functions let's let's take a look uh to this uh typical problem on on server side where you have some context for example transaction context and you want to wrap a block of code uh into transaction context you want to start transaction do some block of code and commit transaction and in kotlin you write this as a line function you take a it's higher audio function takes a block of code and it wraps it into whatever scaffolding you need with this uh high order function uh how you use it you write function uh and inside of it you say with transaction and that's your code inside it that is wrapped uh the great thing about this usage it's it has no magic like any person who sees this code immediately understand that there is some function called here and they can click the code uh see what this function does see the stats transaction ends transaction uh contrast this with uh how it's usually uh done with annotations you annotate you know function with uh with the uh some annotation and that's magically performs disrupting in non-transparent way so but but here's also a downside of it the downside of this is uh now your code is nested to the right uh and it's more of those things you add the more code becomes nested to the site so so what if instead of this kind of usage syntax we've introduced the concept of decorator what we could say that uh you mark a function with a decorator modifier and when this function becomes a decorator instead of nesting your code inside of it you can now use it as if it was an annotation you can just write with transaction and write nah write your function this way your own code is not nested is not moved to the right and uh it gives you the best of two worlds it gives you concise syntax and it gives you complete transparency what it does because you can always click on this function and see how it's implemented and of course the concept of the creator is not new it's it's used in many languages extensively but for quality in particular it can be implemented statically by combination of line functions uh you know and uh the the ability of kotlin uh to inline them during compilation now you ask how the idea of decorators related to multiple receivers you see in fact that if we start thinking about decorators we immediately come into a situation where to wrap some code we might need some outside context for example our with transaction decorator might need an external transactional context that it would use uh to begin and commit transaction and if a decorator needs additional receiver it means any code that is decorated with it requires this additional receiver so by applying this decorative function we see that now this function requires transactional context to be called in because it is decorated with something that requires transactional context and by taking this idea we can instead of bringing a special syntax to add additional receivers to functions we can instead start with the creators and then just have a standard library decorator for example called with that the only thing it does is brings additional receiver to the code without doing anything else fancy like closing researchers or committing transactions so now it's just a standard decoration a standard decorator and it's a part of a bigger feature that enables uh very powerful meta programming in pure costly code without having to do a magic uh bicone engineer and post process you know things like that but you see not all features has to go this far it doesn't mean like every feature that you ask for has to be become a part of a very some some very big picture they're they're quite straightforward ask that we can find in our utrecht for example support for public and private types for property it's again it's pretty costly problem and it's highly voted because it arises a lot in in in content code uh you see if you look again the issue you'll see that it gives you a syntax proposal and in this case the syntax but also quite straightforward and i hope just by reading the code on this slide that it's you know value of items which is mutable list of items with public getter that returns a list like every content user community realize what it does it declares that the public type of this property is list while its private type is mutable list and that's one good side of this sentence that it's you can understand what it's doing and the other good side and it's actually solves an important um piece of boilerplate in kotlin because without this feature in cotton you'll have to create you know use this underscore convention um you have to create a private property with a different name and then create a public property that uh just to expose it with a different type so it doesn't mean that like the feature is really straightforward like we just take this issue and you know next day implement it uh even for a simple feature like this we'll need to do some design we'll need to figure out corner cases we'll need to figure out compilation stages and interaction without with other features but indeed this particular example is a feature that is pretty straightforward to implement it requires minimal design um the other very popular and thorny question is a ternary operator it's a pretty high in the uh list of highest voted issues it has 80 votes at the time i've looked at it and uh you mean right at the subject it says uh what people want uh they want gender operator from java and c where you use question mark as and if but here's the problem with this issue cotton only has an f expression you can write the same thing as you write in java with full question mark a column b by if expression kotlin so if we add turner operator to kotlin it makes it hard for existing code to decide like if the if you write an expression which one should you use should you use journal operator or should you use if expression uh so this creates like insurmountable you know code style connector or what do you do how do you recommend people how do you solve all the battles that will appear and which which is the right in this place the other problem is that causing consistently consistently uses question mark in the context of nullability so whenever you see a question mark in kotlin code uh you know is related to annuity somehow for example foo question mark column b checks full for no so by reusing them for boolean expression it will make it harder for novices to figure out what's going on uh because it becomes inconsistent they will have to learn uh in what context question mark does what i mean arguably for uh uh developers who come from java or cc plus background that's not a problem they already know turnout right but for novices that's going to be additional barrier in learning the language so they have to like recognize uh what it really does and you see if you look at the if you look at the uh ternary and compare it to if expression uh you notice that turn operator is shorter but this conciseness and less characters you type uh really plays out for really short and small expressions um for example when you have like this small boolean variable like foo in uh this uh issue that's where you can immediately see that writing journal operator is shorter than writing if expression uh well in real code it's not something we work with often in real code you know we we don't uh uh promote using of a lot of booleans in our apis we kotlin strives to enable type save api in your code so you're not using booleans you're using type safety numbers and other more richer types to describe your api surface so in real code if it's well structured you will get a lot of booleans or if you have boolean expressions they will be not just a single variable but some long ones and the longer expressions the difference between if expression and ternary writer is not that apparent moreover if expression rules complex expressions is clearer and easier to read so so all in all if we take this all together i mean it means that we'll have to decline this particular issue so we want uh have ternary operator as it is not came to us from java and c plus plus uh because you know because no they have an infraspection for that all the other problems it would bring if we had but it doesn't mean we're not hearing that uh you want to write sometimes you want to write boolean expressions like this maybe in a shorter way so maybe the future will figure something else out but that would not look like a ternary operator not all we think about during language design or plan for the future comes from new track issues there are some things that are part of larger trends and one of those trends is immutability it's not like we have a specific uh issue or keep give us more immutability it's uh what people work with you see uh and i'll show an example how it appears in practice so assume uh we have a some subsystem and we keep it state and we start with keeping a state in a simple mutable class it's easy to declare in cotton you just write a number of wars and by being readable class it's easy to update you just assigned its properties and that's done you've changed it but now here's the problem if you're writing more applications now we often use asynchronous data communication even inside the application uh uh we send our data over or our states or asynchronous pipelines reactive pipelines so when we do that and our state is mutable we cannot just send it because while it's being transferred over the pipeline it can change so we have to copy it and send a copy that's called a defensive copy and this defensive copy that you have to do on immutable data is easy to forget and it's a big source of errors in our modern asynchronous applications the solution to this that people often employ is to use immutable data and with kotlin this is straightforward you know you just change war to wall and your data class becomes immutable you cannot change anymore so now when you send it even asynchronously you don't need to copy it because it wouldn't change having done so though you've made it harder to change your state because content syntax for updating uh individual class like this is quite more verbose than a single update of a mutable class you have to do copy you have to list all your variables updates in one place you cannot use concise operators like uh plus equals anymore it's way less convenient than working with immutable data it creates an impression that immutable dating content is kind of not second class so the question we ask ourselves here is can we have kkk needed to can we get a safety of immutability with convenience immutable state and i mean surely we can i mean we can introduce a new concept on uh of a value-based class now what is a value-based class developers class is a class uh whose sole state in its values a class that explicitly disavows its identity i mean we say that because uh the only thing we care about it's it's the value of a class the contents of its properties and it's not new concept in kotlin if you think about all the so what what we call primitives in java they're actually not primitives in content but they're built-in types like int long and even class-like string and actually most of the classes including standard library are value based and for uh like building classes like interlock a compiler even enforces this like if you try to compare by identity to ian's uh you you get an error that you know those classes do not have a stable identity they have an identity when they need to uh to be transferred uh for example into a collection but it's a transcendent it's not uh it's not something you can rely on and because of that uh you know every time you perform operation on this you get some new value and identity is just something image material you don't use it and so it's not a new concept and it's natural to extend this concept onto a user-defined classes instead of just limiting it to built-in content classes and by declaring that class doesn't have a stable identity up front uh we can now add syntactic sugar to make updating of these classes easier because farmer said that i'm not going to rely on the identity of the state instance uh uh and compiler can check that uh you don't accidentally use this identity in say identity composition or other identity sensitive operations we can bring syntactic sugar there with you create a copy of this class without writing all this explicit copying code but just writing as if you're changing immutable class so in this sugar makes it this class is easy to update as immutable class but it brings all the safety benefits of immutability so here we go we can have a cake and eat it too so by itself this idea is just an interesting direction in a future cultural evolution but it also lets us solve some shorter problem that we have now and the shorter problem we have now is we need uh to do something with cotton experimental online classes and right now called experimental like classes are implemented with the inline modifier before class uh in just this modifier in line is is a problem because it it would be confusing as soon as java project valhalla comes out and as i told you at the beginning interoperability with various java features is very important for cotton so we're looking to the future where valhalla becomes available and starting to see how you know how you write content code in this world and project welcome will interviews a concept of job online classes that related but very different concept by naming another different custom feature in line class will create a lot of confusion when you can line class you'll be it will be hard to figure out what's going on whether it's one class or cosine in line class you'll need to clarify it all the time uh we don't want to have this confusion when valhalla comes out so we need to think of some different name for that and the whole idea of value-based class gives us a way out instead of having an inline class modifier we can say that entire class is just a value-based class which is true because inline classes as they're implemented now they they don't have a stable identity they're boxed only when needed and so their identity changes and you can do identity comparisons of them so they are a value based class so so we can use this well modifier to say that this class doesn't have a stable identity it's only relies on its value but we also compile them in some special fashion uh we uh flatten those classes into uh the other classes we pass them without boxing to the methods we return them from methods without boxing and we can express this with some kind of annotation that basically says optimize away boxes whenever possible and i don't know how we name this annotation and i actually don't want even to speculate right now because i want to avoid the same problems we had with inline so we'd rather announce this name as uh late as possible so avoid any future conflict with any other uh features uh that will be coming in java so we want the same to be unique so when you see it you clearly understand there's a kotlin specifically confident feature on how uh coughing classes are compiled it also opens us a road in the future when volcano comes out to uh have something like at gvm inline annotation that would compile your class s volcano class if you're running on gvm that supports it so that's that's the plan so what else uh you see i've been talking a lot about features that we and cosmetim look how we're going to change compiler for this and that's but that's that's not really a scalable thing we can do everything you want you know there are lots of domain specific needs um and each they made that costing is unique you know service type developer has their own needs from developers and other needs etc etc uh and for that we've been working hard in the last few years to really re-architect the whole cotton compiler so it's uh works since a consistent and more important plugable set of stages so compiler when the sources uh analyzes them uh they come through a front end and if you can write front-end plug-ins there affecting you know how declarations are resolved you can introduce scientific declarations there and again in the past year or more we've been working hard to unify all the cult in back-ends into a common backend that then later goes to generate code for gbmgs and lvm so this way you can write a single back-end plug-in that affects code generation for the specific piece of code and it works in all the kotlin back-ends on all the platforms with this architecture that's worst working on right now it is possible to introduce new language features not as a hardcoded building feature not as a plugin and take a look at our friends and google who work on jpeg compose you know with jetpack compose they have this annotation composable that you can add to function to do nice things uh for reactive and uh interactive uis make no mistakes this composable is actually a language feature it's very much like suspending function but the only difference from system function is not hardcoded into the core kotlin compiler it's implemented as a compiler plugin but it's a longer fusion nonetheless and we specifically reacted according to such way to make this possible to enable those domain specific features to be added as plugins and it's not the only example our friends at facebook work on differentiable programming for kotlin where you can annotate your mathematical function with annotation differentiable and it creates a code to do automatic differentiation of this code it's also an language feature just uh done as a plug-in you know you as it always comes with issues like that of course it comes with the whole library of mathematical primitives you know mattresses tensors etc but at the core of it is this uh language extension that allows you to automatically derive all the differentials for the code mathematical code you write and there is a growing community of people who experiment with scotland and writing their own plugin you know eric kt community writing really cool stuff uh based on uh clothing new kotlin compiler architecture uh there is brianal who writes power source uh library that you can google which is really cool and you know you can have your own projects that uh uh are written on top of that it's all experimental right now but we are really committed to bringing it to stability in the future so for conclusion let's recap what we've managed to talk about i mean it's been a long talk i know and uh i definitely could not cover everything um so we've talked about uh our commitment to jvm interval ability uh we've talked about namespace and extensions in kotlin multiple receivers and decorators we've talked about public property type turner operator immutability and like classes and other contributions to cotton languages but it's it's not all we're looking at what else we're looking at we're looking at how we can make syntax for algebraic types and culture more concise we're looking at various data literals collection tuples et cetera whether they can be brought to cod and in consistent way we're looking even more flexible property syntax because properties are core differentiation in cost and feature uh we're looking at our library authors and how we can enable them uh give them features to enable more expressive easier to maintain and easier to evolve apis while looking at constant evaluation and folding which is also really popular in utrecht if you look at it and more i mean we're really exploring different routes uh and how we can evolve culture in the future and we'll look into our community and what interests you what problems you face which are more important for your use cases so please contribute tell us what you need and thanks for listening to the talk and have a nice catlin all right and we are back everyone uh that was a small look into the future of kotlin together with roman who is also joining us in the studio now hi roman hello everybody hello roman so thanks for joining us and before we have actually we've got a few minutes like four minutes or so to ask you some questions uh before we give way to the big uh q a with everyone else and uh we've got a whole bunch of questions that people have been asking in response to your talk so let's try and see how many we can go through first one is from alexandra that says don't you think that making public the default visibility modifier was a mistake shouldn't the default visibility be internal no it's actually uh it's actually very good decision on on part of the original content design i mean time and time shows that most people when writing code want to have uh public custody or that that's what you have in your actual real life code most of the time and the default the i mean for defaults it's simple i mean defaults should be what people use most okay the next question comes from nikola can we get some more updates on the status of the keep process i've actually written this about the talk i mean the key process uh is uh is a great process in itself the only problem with that that uh we'll be we'll try to make sure that we have like workout designs in the keep and we'll try to move uh like ideas and stuff like into the utrecht direction uh so we'll be doing some a bit of cleaning maybe some close still ones or move uh the issues that are not actual or finished proposals which are some ideas uh to you track where we can continue discussing until you know some finished and worked out design emerges and then we'll have it but in essence you could kind of say that you're still keeping it yeah we're still keeping it it's definitely going to say a suppository that tracks all the language enhancements so you'll find the history it was changed what new stuff was added when and how it's designed documentation for all that stuff okay okay and i'll stop making jokes anyway why not i mean you i mean do you make more jokes i mean otherwise just like worrying you know important technical stuff okay dimitri says do you have any plans in new future to improve exception handling in kotlin like multiple catch block or something else we actually plan to steer people away from using exceptions as a way to writing them code i mean something but we also understand that people have also legacy java code that sometimes abuses exceptions so we're thinking how uh a ways to improve interop with this legacy java code on one side but on the other side we don't want to encourage writing exception heavy coding coupling i mean when people use exception for exceptional cases or for errors but then they're good but not for it's a way to sneak multiple return wellness out of their functions okay let's try to sneak one more in here suresh asks now java getting fully featured pattern matching in a couple of releases uh the color went block feels a bit inferior compared to java are there any plans to bring better pattern matching to kotlin uh so that's kind of a bit of a stretch i'd say uh so right now uh kotlin's one expression is way more superior to whatever you have in match or even what's in prototype in java so whatever whenever or if ever java will have pattern matching let's say though we're definitely keeping track on those uh discussions in java but the um uh really uh advanced battery machine java is far from being uh uh designed at all i mean it's definitely not coming in the like real close future because there's like only some ideas not not even a side of the worked out design of how it's all going to work and job we're keeping track of that if java goes this way we'll be definitely uh be looking at how to enjoy with it too and you've got a couple of questions that have come in through in response to your talk and i'm gonna try and combine two into one okay the first one is kind of saying how can we extend vowel class and the second one is how would val classes be used from java code uh so the wildcats itself uh is first of all it's just an idea now so i mean uh i mean uh it's actually how you would extend vault class is why would you need it so i mean we'll have our issue tracker for all classes uh we'll create why so uh you're welcome to come here and like write your use case like here's my use case for example class and they will figure out what to do with that uh and uh for java i mean like grow of all classes all classes uh basically give you uh they will look at regular classes from java for now until the project called hall is out uh of course in line of all classes that's the one that we call inline classes now are not visible as java because it will have to do special compilation trick before because java doesn't support this kind of anything now i mean java's actually working a project called hala and will ultimately support the concept of uh value based in line or primitive classes whatever the the ultimate thing they pick and um at that point will kathleen will interrupt with the switch at this point kotlin will be able to compile each classes to java's uh primitive classes audio would be the name and then you will work but until java supports it there is no way you will be able to use it from java okay now before we move on let's try to get one more question in front of stefan he asks would you like to introduce something like refi generics but for some kind of inline classes uh i mean the i'm looking for your use cases please i mean don't keep us in the dark tell us why would you need this okay so in essence we need more information on that one yeah in essence it's all we work i mean actually we ask i mean if if if if i were to condense my talk into like one uh sentence or two like uh this is please please when you write uh when you want language to be improved please uh don't tell us why you need it what's use what the way you're working give us your use case what problem you're trying to achieve that's all we need because we're working on our own limited use case like we're writing compilers and libraries and stuff like that the only way for us to see the world around like the problems you're solving is when you tell us what problem you're stuck with and then we can together try to figure out a solution that that works for you your skillset for all the other use cases so that's a good point so in essence if i'm understanding you correctly instead of like saying okay i want you to introduce this language feature instead say look i'm trying to do this and i think that with this language feature is the best but maybe it's not do you have any other way to to try and accomplish this right exactly it depends on the what you're trying to do exactly emphasize what because by combining this multiple watt from this all the small domains all of our community working it then we can come up with a single feature that instead of being narrowly targeted we widely address as many of those use cases that you tell us and then we can validate that we actually solve your use case because otherwise we don't know use case we designed something and how do we validate we solved somebody's problems and nobody told us what their problem was in the first place okay well um thanks for that roman we actually have a bunch of other folks here who are waiting backstage uh eager to uh answer all of your questions um so we're gonna bring those folks online and we are going to uh move over segway very smoothly unlike the previous segments uh into our big q a so i think that my segways are not good said i don't know let's ask sweater let's ask stars let's ask anton jaegor and also andre hi everybody hi there hey how's everyone feeling on the on the transition so far in the moderation my transition has been smooth very good okay um we're gonna start off with a small question here um how do you want to take us in yes um thanks for everyone joining um seb i know that you've been online with me from the very four four hours now or so yeah um it's been tiring i know uh but uh so i'm gonna let you off the hook and let you start by answering a question uh what should be chosen to learn uh should i start learning kotlin or should i start learning java as a new comer oh it's very good that you specified as a newcomer yes yeah because if i if you were just asking me how do you whether you should learn java or kotlin um that would be a tough question to answer um i mean we we really see kotlin being taught as as a first language more and more uh in university courses we see people uh starting out with this as as low as like eighth or ninth grade and i think that the language has shown very nicely uh that it's a a great first language and i think that the language design also makes it very much possible uh to get started with with kotlin a lot easier than some other languages which might have certain quirks um yeah just just out of curiosity so that everyone is on the same page when you say eighth to ninth grade because i know that varies from country to country what age are you talking about uh like 13 14 year olds okay cool okay yeah so go on next question what do we have for who do we have it great we are moving on with a question for sveta um will the kotlin documents be localized officially in the future development roadmap wrote map and would there be any kind of jargon list also will there be more samples added to the documents because some syntax explanations are intricate such as function receivers sweater you wanna say something to that yeah uh this idea of localizing the documentation uh exists for a very long time and uh so far there are some ideas but nothing uh in the clearest uh the nearest road map uh promised for uh this year or the nearest time but of course uh we are working on it and now we have even more folks working on other documentation they're amazing so uh it's working progress improving the documentation is always working for us by the way if you want to contribute to something feel free to do so there is this edit button on the top of the dock so you can uh add your suggestions there yeah so in the spirit of jaeger's talk uh i guess you can give back and contribute to the community here as well if you uh think you can explain something better than the official docs for example that's a great way uh to do that absolutely it's all open source right not just the code but also the website and the document okay igor are you there yeah yes you are so igor question for you how will kotlin in the futures help engineers to solve future problems mainly in science do jet brains have plans on a kotlin core library for engineering well we don't plan to implement any new libraries in the near nearest future uh not only engine core engineering library but any other libraries as well uh and we plan to focus on stabilizing what we already have it's really hard to maintain numerous libraries when you have a team of affinity size so we believe that the best library ecosystem is the one created and maintained by the larger community so we'll also appreciate appreciate your effort in this direction so feel free to contribute well maybe on on that topic continuing i'll throw that question into the room and whoever wants to answer it can go for it which markets would you like to see kotlin expand into someone has to go all of them all of them good that's a good answer yeah we can list a few markets you know it's it's pretty easy i really want carbon to expand a lot with the with the cloud market right cloud development is on the rise and colon should expand together with it uh data science is on the rise and we should expand together with it and uh machine learning as well is on the rise we should stand together with it so once a fourth and i i can't really imagine a programming related market that kotlin shouldn't expand together with it definitely should be everywhere i mean it also is in line with the actual premise of kotlin right when we first started working on it which is an industrial multi-purpose language right i mean there's there's no reason for it to not be in any specific field yeah i should say industrial has been largely redefined since 10 years ago but still like the the actual premise works yeah i'll just go with the flow there and just say yeah absolutely i love it industry it now works for us industry okay next question okay first of all thank you for the excellent work um igor this isn't for you remember you don't want compliments but anyway thank you for all the excellent work evolving along the cons kotlin alongside the community i have a question that could be considered a feature request this is not for unicorn i would love to see something like cargo in the kotlin ecosystem and a package manager okay now this turns out it's for me [Laughter] it's called package and it already lists a bunch of uh libraries that are available not only for kotlin but also for cotton multi-platform and there's a tool inside intellij idea that allows you to uh add your dependencies add your libraries easily and there's more features coming there and most likely we're going to have something around the command line interface too so yeah that's already in the works um you didn't even need to ping you go for that one next very smooth uh i don't think i can answer this next one but we'll we'll see uh how are you tracking build system stability okay i'm out when the for example when the complex configuration fails in gradle due to coupling compiler concurrency or memory issues how do you get that tracked i would throw that to anton maybe um i think usually we rely on real world use cases and when some our users tell us about that it doesn't work we look on it and fix it so yes i think we mostly rely on our community and feedback from you okay yeah i can probably add be a bit here uh currently we are working on improving uh the statistics uh that we collect from our build tooling and yes now if you experience some problems feel free to post a ticket in utrecht and add all the corresponding logs here because we look through all of these issues and process this information and i hope that later we will enhance our analytics system to also see such failures there cool which is another reason why we need more feedback and you want that data analytics enabled right uh system settings appearance and behavior data sharing and chat you actually memorize this like i should make a tutorial oh there's a poster asks uh two questions one related says why is attorney operator not a kotlin first feature at all what made kotlin's architecture not want to support this and he adds it's not the absence that bothers me that much but it's the why that really still bothers me so can we roman can we get kasich to stop being bothered just about her use the if expression i mean and you'll be fine that's my great advice that's it i'm not ready for this easily just stop worrying about it that's it be happy yeah yeah that's very good advice in life okay you might as well go with the whole chinese proverb right you're not going to be able to change it so why worry right i mean like okay it's fine short and sweet um next question comes from a kesha i am new to carl and i'm learning kotlin from its documentation and there is a lightning documentation stating in kotlin everything is an object in the sense that we can call member functions and properties on any variable i could not wrap my head around this statement so can you shed some light on it i'm going to throw this one over to sweater yeah it's just a basic premise of objective programming like everything is an object and you can call members in it i feel like that was the exact same phrasing that i just read by the way if you want to learn more basics about kotlin there is this book which is called atomic kotlin which covers all these uh things in a explanatory from scratch way because we in the docs we kind of assume that you're already familiar with such with general positive object-oriented programming what a class is what an object is and so forth so if you want to really learn it from scratch there are many different resources including atomically but there we go that's a great answer great do you need to know get to work with a tommy kotlin let's start with that again okay um andre i got a question for you can big corporations like google or oracle influence the future of kotlin or the only driving force of kotlin is the community yes to both uh because big corporations are also part of the community so uh like as any member of the community they can influence kotlin and and also well they i don't know if this is what what's intended in the question but uh big players can influence us in other ways than just you know asking for features or something when somebody creates a new platform for example or backs a new library or advocates for a new way of programming or something it definitely influences the the entire ecosystem of programming global and kotlin as well so in this way the like more let's say the more resources you have the more you can influence uh such things and kotlin will be influenced in turn but yeah we are uh we're closely working with uh folks over at google uh on things like uh jetpack compose where you know the team at google is working on the uh ui engine and all this stuff but it's based on a plug-in for the cutling compiler so on our end we are providing them the api and this way we are communicating all the time we are you know negotiating apis and so on and so forth so they're uh it's sort of an influence so we stabilize part of the api to make sure the components works we also understand how impactful this kind of initiative is and we want uh it to be delivered to the well as soon as possible so we're helping uh yeah so it's definitely an influence and uh if somebody else it doesn't really matter whether you are a big corporation somebody else is going to change the world by some groundbreaking technology and uh well we will be able to help oh we'll be happy to that was a very thorough good answer thank you yeah i i think i think there's no follow-up questions coming to that one um i have a question from york thank god i got that question because i don't actually know how to pronounce umlauts um the question goes to stars and it is what is your perspective for the excellent arrow arrow meta lips and extensions are you considering adopting keeps from the emerging arrow meta ecosystem and how close is japan's engagement with 47 degrees the developers of arrow and arrow meta yeah yes there's two parts about keep and about well infrastructure of compiler but if i guess later ramon could uh answer and i will answer about uh infrastructure and yes so um basically arrow is affecting our compiler a lot and well we look deep into it and talk with them and uh well collect all these cases that they have and so on and so forth and in the future maybe we will uh create a good api for coding compilers so arrow could be created on top of that just as the normal plugin without any hiking so basically our collaboration right now is regarding plans about such uh api extension plans and so on okay roman you want to add anything here actually stasis beautifully i mean our goal at the end is to to to finish this new compiler architecture so that we don't have to implement every feature like every uh different people need with the new compile architecture uh uh i mean we'll we'll be able to have different compiler plugins for different cases and that's why it's important that we have those early adopters early carburetors like google jpeg compose uh arrow kt community that we can work with and figure out what they need from stands from compiler apis and uh figure out what's missing uh so that's our actually it's much better than just taking you know keeping bringing to the language it's much better to make language extensible so like you can just add plug-in and have the feature you want all right okay next question from warner uh roman why to introduce namespaces when we already have the package concept yeah it's actually uh just a difference of size you know pictures usually something big you wouldn't create i mean creating a package maybe for 3d collations just feels heavy uh and sometimes you just you know three are a few things that you want to be grouped and also the difference is like package usually import it all so you don't see the name like i imported uh at least off uh from cotton collections package so i can just use list of but uh for some declarations like like i've given exam delegates or for example in content cartoons uh dispatchers i i want people to always mention the name i want to quote read like dot something dispatcher still something that's that's the idea of namespace something you would you will always mention and something that contains a few articulations a different scope conceptually the same as package actually and we're still thinking about naming so maybe we'll figure out a different name uh to highlight that's it's essentially the same as package just really small micro package that you're just declaring the file oh god so so service and microservice yeah no so uh i have a follow-up question to that uh you know if you're saying that well it's just a matter of the the size of of what it is you know folks are going to probably want to have some rule of thumb there and say okay so where is the borderline i mean what why when i when should i decide on a namespace when should i decide on a package um i mean in this particular case now it will be simple i'll look at how you want your users to use it like if you wanted to use a plain name like the name itself of the things you do is long and pretty explainable self explainable use the package because people will import it from the package and we'll just see a short name if it's something you want to be qualified like a delegate.now dispatchers.default something dot something like enums for example have actually an emmy space is any of them actually coughlin compiler already knows how to deal with it it's just not exposed it's just used in limited circumstances like for enumentaries uh and uh so in this case if you want people to use it in qualified form you will use a namespace that's it okay well we're gonna completely shift topics 180 degrees again here and i'm going to ask sveta are you planning a call and certification we already have all the certification for training companies which does mean that we can we have some partners who we collaborate uh with uh who can provide some training on requests so so like if you're a team uh who wants to learn kotlin and you have like i you have specific uh requests like whether it's android or whether you're instantly multiplatform you can uh get in touch with us and we'll recommend some of specific our training partners and for general certification for developers we know we don't plan to do it if you want a certificate i don't know you can finish the coffin photo developers of course and then the coursera will generate you a certificate which you can show somewhere but we don't plan any to do anything special from outside yeah if you want a certificate just print it out you know yep yeah but of course of course you still need to do the assignment so it's like it's not that easy to get it okay anton i got a question for you uh archie dave asks hey folks thanks a lot for the incredible talks are you folks planning to create a groovy to kotlin code transformation plugin for gradle similar to the one you have for java to kotlin integrated inside intellij uh yes and i even could say that this work is in progress it's quite a huge task and it's not easy task so i think we will would probably announce it if uh after some experiments and tests uh it will show the good results oh yes it's implants it's in under development but we can say that it will be done soon yeah it's under progress all right just love it when the answer is simple and just like yes it's coming okay nothing better than a straightforward answer right ternary operators are they coming no there we go yes but very very slowly like they're not coming in your lifetime well i have i have an interesting question for stars and the question begins with happy comma so i'm not entirely sure about this one but okay will will the ir back end replace the java compiler stars i'll let you answer that one okay i'm not sure that i get the answer correctly because well ier beckons is about scotland compiler and um we are not compile java at all i mean we do some java source code emulations and analyzes uh mostly declarations but it's a front-end part so basically the answer is no because we do not compile java even now okay so what i'm hearing here is the kotlin ir compiler will replace the java compiler when kotlin replaces java well yes which won't happen all right i mean there's always going to be java but yeah you can do j2k convert if you call it and then compile with new ir so investment to replace this you know oh okay i felt in the world okay never mind um that's right so question from a question for roman and this one you're going to answer not me will the new kotlin native multi-threading model be available in kotlin 1.5 also in the same question another one question for roman will the new kotlin multi oh it's they've written the same question twice okay so okay i mean uh we're working it so right now uh customization team is prototyping the new garbage collector so they can um leave restrictions of the old member management scheme and uh we'll see how it goes i mean it's surely to tell when we'll need to have a prototype ready play with it and see how it goes and we'll wait for our roadmap updates and uh i mean we'll as soon as we know the answer ourselves we'll definitely announce it okay so this one is for andre so are there any plans to implement kkkt11488 which of course we all know what that is apparently that is gonna open that all right apparently the ability to call super extension functions in descendant classes super extension functions oh man i have no answer oh i guess i get it yeah so uh that's a difficult one i think we might have something when we figure out the multiple receivers problem but i'm not sure uh because the the current proposals for multiple receivers are unrelated to that and if if you if you really need something like that uh you have a couple of workarounds i hope you know what they are and you're probably stuck with those workarounds for a while okay okay okay this is a general question i don't know anyone can answer this one uh you're all from the kotlin team ultimately uh colin running on the jvm for android and server side i want to know if there's any kotlin vm on which the team is working which may be faster and better than the jvm well well honestly speaking it's it's you know the definition of what vm is uh is the question so uh but the the easier part is the faster and and all together better it very much depends on the use case right so uh like kotlin native is going to be probably faster at startup than to the stock jvm right it's and it will compete with growl on this and so on so forth and it's it has some attributes of ivm it has a runtime that manages objects collects garbage so and so forth it's it doesn't have a byte code it's aot compiled but you know whether uh java native image is still java vm is a question for anybody to answer so the answer is yes if your use case fits okay um i'm just gonna take my turn very quickly with a quick fire question for roman will there be a pipe operator in kotlin i mean yeah you can always create an extension called pipe and use it like why would you operate i mean constantly confidence is extensible language so wonderful on creative for you wonderful so if you need it just build it also convert your plugin okay next question uh and this is i guess related this has been asked a couple of times actually what is the state with kotlin scripting anyone wants to take that well i could try to answer it well basically right now they have different focus areas so scripting do not have a lot of attention right now so it is it's mostly the same as was in 1.3 and well yeah that's it i guess yeah we have a dedicated person working on kotlin scripting uh he's working on maintaining it but we don't have any huge plans right now okay um cool let's see here what else we have um this question goes out to andre and it is did you ever cancel a new feature because the community was against it oh my do i do i even remember that there was i think uh i i remember off the top of my head i remember a case when we changed priorities because of that and uh uh there was at some point there was a very heated discussion around uh collection literals like whether we need uh square brackets for lists or something like that or not and uh then uh there was like a lot of controversy that there were some people in favor of it some people against it and uh we looked at it and looked at other things and just went to other things and we will be getting back to this question pretty soon i think uh but at that point of time we changed priorities because of uh the heated discussion like not not the arguments from either side but just okay it's controversial let's do something else okay i'm going to rephrase that question is there any feature that you wish the community had asked for given pushback so that you wouldn't have oh yeah there are many features that unfortunately uh when they were created the community wasn't that huge and like there were too few people to push in in any direction but yeah there are many features i regret okay well i think this concludes our huge q a and now here is a uh quick fire round of uh some questions around um yeah just just kind of everybody may be sharing what their favorite part about the 1.4 release was uh we're starting in the top left here with anton and you can't answer that it's over [Laughter] okay [Laughter] i can say that the programming language is barely imaginable with the tooling that people development language and as we focused and uh performance and we already provided some improvements in this performance and we saw uh some pretty impressive feedback that he actually started to work better and faster so for me personally for me it is the best and most possible not smooth thing that we had in 124 okay we're gonna continue to my right with sweater i would say that uh in this release uh i'm happy that uh i've influenced the hotep and first functionality finally got uh into the stable version of the language i know i think stars can elaborate on how much effort it requires the team to uh to get there and uh it wasn't an easy process and it's not a feature that you like or i can use it but it uh but it influences the whole story the whole language uh will the choice with the choices that you can you can get with the yeah with the things that you just uh get by by default with this new uh algorithm the whole list of uh features that was fixed with this is like it's quite impressive so and at some point there was like this will be fixed in uniforms and now it's finally there so i'm really happy that it happened okay then next middle left is stars yeah it's let us say [Music] for me personally it's type influence definitely because well i started realizing type influence after one point zero release so after that a lot of people join me and it was like three or four years now so it's like a lot of work since then i think i was writing the documents of how the japanese would be written before that yeah so i think it's not your whole career in kotlin uh is paralleled with type inference right because you were basically ascending and uh getting more and more responsibility the type of inference was closer and closer to stable yes exactly all the more reason to celebrate uh let's continue with roman i mean i there's not much i can add i mean i'm so happy to type in friends in my voice finally out of the door and it fixes so many bugs important cases including just incredible amount of work and just great engineering achievement can someone tell channeling commerce no one has said creating a minor feature i mean on functional interfaces it's nice but also by the way if not for new inference we couldn't have functional interfaces i mean the i mean it's not coincidence that 1.4 has new inference stable and functional interfaces because we couldn't have implemented them other way but do not underestimate the love the community has for trailing commerce it blows my mind every time as well i mean i mean this case where it shows the power of community like like uh it was not a single person in custody myself who would like care much about them i i i don't care much about i can write it away code but we saw the like how much passion uh people from community how much people care about training comments from community that we we looked at it and so like i mean it's not much work for us it doesn't break anything it brings people happiness like let's do it let's make it feel happy well also was a couple of very enjoyable design meetings yeah nothing really nasty i think that's on the spot it was great wonderful okay let's continue with the igor okay i liked two things the first one was how we celebrated the relief just imagine hardy and seb hosted a private radio show called kotlin fm just for our team they streamed our favorite songs uh they read some jokes etc etc it was great and the second thing is what we did with kotlin multiplatform for mobile we already had some early adopters at that moment but what we did he was the simplification of the onboarding process for new people we launched a new web a new developer portal a huge web page with a number of case studies with lots of documentation guides etc we created a new plugin that well simplifies the setup process and the new project creation process so yes i'm very proud of what we achieved in this area and well i suggest you to visit kate petrova talk on the third day she will tell more about it yeah i can also just said that uh if you're uh wondering where all your questions about multiplayer mobile that you're asking the chat and everywhere is like they are all targeted in the third day so please come there and we'll answer everyone yeah i said forget it no no that was there are a lot of questions that are being put off for the for the other days that they're more relevant andrei yeah so uh actually i think one of the very important results we got in 1.4 is somewhat of a negative result we finally invalidated the hypothesis of the uh caller native memory manager being designed the way it was so we now are pretty sure that the approach we took before didn't work and we are working on a new garbage collector so i think it's it's a very important result although it's not a feature in the release it was uh it was a lot of work put into invalidating this hypothesis and i'm very happy that we're done there and we're moving on so well thank you everyone for uh for your presentations today uh i did that uh i was gonna say that it's been a long day but of course they were all pre-recorded but uh it's been a very very long day that you've come afterwards and you've been answering our questions um appreciate you being here so thanks again for also taking part in this qa session and we'll see some of you in the near future yeah thank you very much thanks for having me everyone so it's just you and me again sep it's just the two of us just the two i missed them already we can no exactly right that's why i don't sing because we're going to get banned from youtube okay so that was good uh it was uh just over four hours um and uh and i haven't actually left my seat actually i have but my dog is extremely pissed off at me because i kicked her out of the room so she keeps coming and going all the time so i'm like well you're staying out so she really wants to get back in needs the freedom yeah yep exactly but uh i think it's been more or less good uh well we don't know folks what do you think has it been good give us some feedback let us know tweet us tell us it's been awesome we need to hear it's been awesome if it's been bad tell igor if it's been good tell us exactly and of course uh don't forget for all the talks that you have heard today um we have quiz quest questions uh so if you haven't answered them uh go back have another look at the talks and yeah try to win some awesome prizes um we're also going to declare a best question for the whole q a session by the panelists we're going to do that offline and we'll be in touch with the folks who submitted questions who we can reach absolutely and sep as usual it's been a pleasure and uh i will maybe see you at some point it's been an absolute delight uh check out the agenda for tomorrow everybody uh make sure you submit some questions for the experts that we're gonna see tomorrow uh yeah and apart from that i think that's it for today take care everybody thank you everyone bye-bye bye everyone [Music] you

Channel: JetBrainsTV

Views: 25,240

Keywords: kotlin, intellij, ide

Id: xJawa3C6pss

Length: 222min 50sec (13370 seconds)

Published: Mon Oct 12 2020