Scale By The Bay 2020: Martin Odersky, Countdown to 3

Scale By The Bay 2020: Martin Odersky, Countdown to 3

Recording: Scale By The Bay 2020: Martin Odersky, Countdown to 3

[Music] we are at the final stretch of a marathon i would say that was uh scalar three and i'm essentially gonna report on uh the the finishing touches that we put on it and where we are and we're really very very close to the finish line here so here's the timeline of the countdown the work on dotty which is essentially the project that led to scholar 3 started a long time ago it was about almost 8 years ago so in the end of 2012 which i started personally to work on essentially a successive version of scala a version of scala that would be uh essentially where we could start with a clean sheet of paper and said well if we could redesign everything what would we do and there were some things that were already quite clear then and other things we were hypotheses that were tried out and in the end abandoned so it essentially was a typical research project you try out many things and some of them stick some of them are successes others you decide are not worth it to to to be included so those were the early years until maybe about 2016 when uh and by this by this time i had assembled a group mostly at epfl to work on dottie and we had a regular release schedule uh starting with d01 and then you got a new release every six weeks after that so we started to be serious about actually releasing this stuff and in 2018 at the scala days in berlin uh the we made and communicated that the decision that dottie will be schuyler iii so that was a discussion between the stakeholders of the community of flight band it's kind of two people that we said okay so the current research project dottie will be the next version of scala and of course then there was also uh still a lot of work to be done uh uh bugs to be fixed uh features to be tried out to be fleshed out uh quite a few things have have changed still between 2018 and now but now we're reaching the the finish so what uh the last story release was uh happened in august 2020 and that was 3027 and now the next release after that that was at the beginning of this month is the first scada 3 milestone so we have scada 3.0 m1 so the main difference or one of the big differences between the two is that previously the artifacts were called essentially dotties as hyphen something and now the artifacts are called scala and the tools are called scala c and things like that so it's basically the same tooling experience and or the same tooling setup that you know from scala too so we're we're getting serious now it's really the the successor this kind of successor that is being readied uh we expect that there will be a second m2 in in a couple of weeks from now and we plan before the end of the year to go into the final release candidate so scala 3.0 rc1 is due in december 2020 and then it's a typical release schedule so after the release candidate is out uh the only things that are still allowed to be done are critical bug fixes and as early as possible afterwards we'll go into the final release so uh the um critical but fixes here uh would be security bugs or if something doesn't work at all but normally that would be it so we expect that that their final release could be out uh well for something as big a jump as kind of three you don't really know uh too much but maybe january or february next year should we should be done so uh it's not just the um just the uh this the scatter uh two uh tool it's got a tooling that has moved and the the core i'm also very happy that a lot of libraries already exist for scanner 3. so the ecosystem has done a big effort already to move as of october we had more than 100 libraries i think right now the count is 150 libraries that have already been ported to three so you can expect when three comes out that not only you will have the bare bones tooling but the the most of the ecosystem or large part of the ecosystem will already have migrated so uh the libraries include well here with the tongue-in-cheek they do not include a standard library and that's actually one of the strengths of the scala 3 effort is that scalar 3 will run with scalar 2 13 as the standard library it will be binary compatible with scalar 213 and that means that essentially you do not have to change both the language and the library and that's a big help importing you could say well why would libraries have to move then at all i mean what does change well first is some some of the language changes so there are some rewrites there and then the big one is macros have changed so that's that's the main difficulty right now for libraries to move but they are serious about it about moving so there's a large list of libraries that have already been ported in particular uh some some a lot of the big frameworks have ported to three zio existence in three cats effect exists in three scala z exists uh most of the how e libraries have been ported that was an effort where scala center was was involved a lot i'm actually committed to did a lot of that work with the help of others uh so we by the time three is out or soon after we hope to have essentially the complete howie stack including including ammonite ported as well so there's a lot of eff reporting efforts still going on and a lot of people really have done uh very very hard work doing that so here's just a tweet from november 7 last who said a lot of people myself included are currently hard at work making this kind of open source ecosystem migration to the upcoming w300 happen and here a bit earlier says tissue wipe sweat from bro and shows what has to be had to be done to port these parallel collections to dottie so uh one core of the potting effort is the so-called community build there's a scalar three community build which collects a number of projects that are recompiled and tested on each scholars report request so essentially that's for the continuous integration every time we do a pull request the whole community build gets re-tested and you as you can see that community built on already includes quite a lot of heavy hitters from scala test is in there uh shapeless is in there zyo is in there uh you pickle uh fancy quite a lot of uh stuff from the singaporean stack out there and if you want your library to be part of it then please make a pull request so essentially help porting it to scholar 3 and make a pull request and we will be we would generally be very happy of including more libraries in this community built because that's essentially the thing that keeps everything going forward and that makes sure that we don't include breakage as as we change the the implementation and as we fix bugs so what about the tooling what exists uh so there's a new uh scalar three compiler that's uh rewritten from scratch let me just try with whether i can go into yeah so okay so there's a new scatter free compiler uh that that one is uh came from the dotted compiler and it's to a large degree a new implementation so a lot of the internal structure of the scholarly compiler has been rewritten and it the other big thing is the ides where the compiler implements a language server with the microsoft language server protocols and that's in turn used by the metals ide and metal system term used for vs code and many others and that i understand will also be used by the upcoming intellij support for scala 3. the other big thing is the documentation tool so there's a brand new scatter 3 doc tool that's based on our tasty format so tasty is essentially our internal format that contains everything that you essentially all aspects of a scalar 3 file of a scanner 3 top level class are contained in the tasty file and that includes documentation and that is essentially rendered and made and organized and made visible by a documentation tool built on docker so both the metals and docker are efforts of virtuslab who has helping our effort of tooling a lot recently with essentially many very valuable additions and contributions build tools we have support for both spp and mill and uh there's support for others through bloop which is essentially the sort of universal build service and so both spd mill and bloop already run on scalar three and the other important part in particular for the next period are migration helpers so tools that help you migrate this those are still in the works there will be one based on scala fix uh there where miriam lachter is the project lead and some help is already already built into the dirty compiler so in the new scala 3 compiler that already contains some suggestions for rewrites and some and offers to do some automatic rewrites so you could ask well what's new in in scala 3 if you haven't really followed it i'll give you a quick rundown um so um i'm sorry that that that was actually i apologize that was actually a slide that should that should come later so uh let me skip that and go go on and talk a little bit more about the new compiler so why a new compiler well one thing was that since we wanted to experiment with the language and in particular also with the foundations of the language that means that essentially the type theory and the calculus underlying the language it seemed that it would be too much friction to always essentially change the existing code base so that's why we why i decided uh to essentially start from scratch and redo it all from scratch at the time at the time it was not really a project that was used by many people so velocity was more important than essentially battle testedness but the other thing that as it we developed it further i believe we have some advantages already in the new compiler compared to the old one in particular i think it's a lot more correct in hairy type checking things such as variance checking or gi dts or type class or implicit resolution so all these things i have been essentially re-thought redesigned from the ground up and uh i believe they are much more on we are here on much more solid ground than we were in the scala 2 compiler the other thing that um should be a bonus is that in many cases the uh the new compiler infers better than the old one so the inferencing precision has been increased quite a bit uh of course if you port code now then the the issue is that it could be that essentially some of the things don't work out uh the same way and that that means you need an additional type annotation or something like that and in fact the purpose of the rewrite tools that are in the works is exactly to essentially automate that process and add type annotations as necessary to help you over the over the pump but one should also see that essentially the status quo is typically code that has been people have wrestled with the scalar 2 compiler in order to essentially get their stuff through type checking so if there's a tiny amount of breakage now that's only natural on the other hand a lot of the wrestling for new code will not be necessary anymore because the scala 3 compiler is essentially in in many areas a lot better at inferring the correct types so it's it might seem a bit difficult right now when you migrate but i promise that in the long run it will be a much more pleasant experience the other thing that i believe greatly improves the imperial experience is the error messages i believe that the new compiler has a much better error messages it starts with sort of syntax highlighting and stuff like that so your error messages now come in colors but it doesn't end there by a long shot so i believe the most important part for instance is if you miss an implicit import or something like that then now the compiler will actually tell you it will make you suggestions what to import to to to make this program work and that was something that previously was uh was was really sorely missing because when uh there was uh some some implicit missing then you were basically on your own i believe actually that the people at jetbrains have also made quite a lot of progress and some of that is already in this kind of plugin for intellij right now so in that sense we have a parallel improvement in two and three which is great too great to see and the final thing is a lot of people ask well what about compilation speed and uh i would say it's it's a it's it's a race uh in a sense so uh in some of it but scala 3 is definitely competitive so i have a tweet here from eugene who said that kenji yoshida he reported 45 speed improvement for i think scada z integration uh so that that's uh very very nice to see so with clearly in some large code bases color three is uh significantly faster than scalar two but i wouldn't bet it would be that for all code bases i think it might be somewhat slower for others and it might be head-to-head on others it's a continuous improvement definitely so we're not at the end of the road yet we uh we decided to essentially concentrate on functionality and correctness first and uh but we will also definitely watch performance and hopefully improve performance in the future so learning and teaching there's also a lot happening so this uh the uh scalar three book in the works uh there are many people contributing to that uh alvin alexander eric lotz from lunatec julian richard four from scala center noel welsh from underscore and and others so it's a collective effort to get essentially something a reference on the web which gives you a comprehensive and indexable view of the whole of scada 3. then if you don't like to read so much but prefer videos then a lot of moocs have been converted or are being written from scratch so um i have over the summer converted my two moocs on principles of functional programming and function program design to scholar three that was a big effort took me about three months or so to do that but it's all in the box now and it will be released uh probably at the same time as the scala 3 final release we plan to switch the moocs also to support it there's also a new uh massive open online course uh called effective scala that's done by julian richard four and others so that aims to be a more hands-on and less academic introduction to scala so something less for university students and more for programmers who wanted their whole package essentially what what built tools to use how to set up your system and so on so that will all be effective scala and it's coming along very nicely i will also teach scala 3 from the start and finally i should mention the lunatec online courses which lunatic has been very early on in scatter free teaching and they they have been great in essentially tracking the final changes of the language and being out there and teaching others to use it the besides lunar attack there's also a new effort which is very exciting that is called scala zone where the scala zone is a free online learning platform for scholar 3 with lessons videos and so on and that's a collective effort of john pretty and registered so now what's new in scholar 3 the maybe instead of looking at slides i just take you directly to the web page because i think that that webpage actually is is a good starting point so let me just change the share there we go so if you look at the dotty documentation that's redox so that's essentially gives you a comprehensive overview of everything that is that is new in in the language uh it's still called dot e we will change it to scalar three uh uh once the essentially it gets merged with the books so the scala 3 book is all about essentially the language as as as it will be as a whole and the dirty documentation is basically about the delta so if i take you to the reference so that's essentially the language reference and that tells you first what the goals were for for our language so the main importance things is we wanted to strengthen the foundations and we want to make scala easier and safer to use in particular that means staining powerful constructs such as implicits and remove warts and puzzlers so those were the the main two goals number three goal was to improve consistency and expressiveness of scholars language constructs but the the so the main focus is make it sort of clearer what the language is and make the language itself easier and safer to use and according to these things we have essentially classified the changes that happen there so you see here the essential foundations i'm just going to pick one of each one so one thing that is fundamentally new in scholar three is union types so where we have types a or b which have all the values of type a and also the all the values of type b so it's an untagged union what you can what you do is not have an left or right as with either but you if you have a union like that let's say an id which is a username or a password then you can then match on it and you can say well if it's a username here on this case so you do just a normal pattern match then do something and if it's a pass password then do the other thing so that was one of the essential additions that we had and quite a few others as well simplifications uh so there have quite have been quite a few uh simplifications that you see here and some of them replace more complicated stuff so for instance straight parameters that replace early initializers extension methods opaque type aliases that replace most uses of value classes and so on i'll just pick one again i'll pick extension methods that's the one that essentially is slated to replace implicit classes where the idea of both extension methods and implicit classes is you want to add some methods to an existing class so for instance here you have the very simple example that you say my existing class is a case class circle and i have an extension that adds a circumference method to the circle so you write that now as follows you say extension and then what you extend so that would be a parameter a value called c of type circle and then that's the method that you add here and that can also work for operators so here you see that you can essentially add operators less than to two strings so here a cons operator two elements and sequence of elements or here a min element to numbers you can all can do all these things they can be generic and they can be collective so what collective means is that we can have one extension syntax in here in this case we extend sequences of strings and we can add several methods to do the same thing without having to repeat the thing we extend and possibly type parameters and counts of type parameters and so on for all of that so extension methods took a long time to settle i remember i was here a couple of years back and gave a talk on what eisen thought was the definite design of extension methods uh it's it's still changed quite a bit but i'm really happy with what we have now so i use that extensively both in my own code and in my teaching and it really works well so it's something that is comes quite naturally and in particular i like this i this notion that extension method syntax is is lightweight enough to do to be able to uh you have single extension methods but it's also powerful enough that you can go to multiple methods and and have something that that that works well for that use case as well originally we concentrated on the single method case only but that turned out then in when we started to use this heavily in the compiler and then other tools that turned out to lead to a lot of annoying repetition and so we went back to the drawing board and came up with this and i think that that is really something that that works well okay so let me go on then we have quite a few restrictions as well where we found that the the previous ways of doing things uh was unnecessarily dangerous or unsound so certain things have been dropped like type projection has been dropped certain things have been restricted like implicit conversions and certain things aim to give you a more consistent user experience because i um if you look at scada then the complexity of the language is not really in the language itself scala is a fairly small language it's smaller than other languages in the jvm space including java so there are fewer constructs in scada than java but it's essentially a an add-on effect that you say people don't just use the language they use libraries on top of the language so if libraries have widely differing conventions then it's a problem and if furthermore the applications using this these libraries have widely different conventions then that's even more a problem so infix annotations are a way to essentially tame this general a little bit so the the the big question here is uh if you have a um call a a a call method like union do you call it like this as one dot union s2 or do you call it like this previously you called you could call it both ways and people did and including in the same source file so you you would find both syntaxes because maybe it was it was written by several people and they had different preferences and that was all okay from the language perspective that actually leads to a simpler language it's more orthogonal because all we have to say in scala is to say well there are methods methods can be alphanumeric or symbolic and they can be called with a dot or infix we didn't have to make any further distinctions so that was a simplification on the language level but it was not a simplification on the user experience because the user experience was while you saw these in the inconsistent usages so infix helps there because in fixed with infix the rule now is you use by default the second syntax only so that's essentially the the prescribed view the recommended thing so write methods in the traditional method called syntax and not in fix but sometimes you might want to you might want to overwrite that well one thing to override that of course would be for operators so there of course operators you write in fix always so you can use the method name syntax but nobody really does because it's just a lot more ugly than the operators but what about normal alphanumeric names so there the uh the answer is well if you as a library designer is a library author you think there should be written infix you can make that choice by adding an infix annotation and if you add that annotation then essentially your users are encouraged to write it in fix they can write it with normal method syntax but again i would i would assume that in this case you have you have thought hard why it should be infix so you will make that case case and your users will follow you but for all other methods so normal methods all other methods will be written in the normal method called syntax if you write them in fix in then you will get a warning uh you won't get the warning in 3-0 uh because essentially we have to take some time to take take the code base but it will come in three one okay so that was the uh the restrictions uh dropped constructs there have been quite a few delayed existential types xml literals will be dropped they're still there but they're on the way out simple literals uh auto application weak conformance compound types so what we tried here really is to not just add features but really to essentially also to get rid of features if we now think that the feature is inessential uh can be encoded easily by other means and has or has been replaced by something that makes more sense changes of the language i believe the most important changes uh and the most important cleanup is really the cleanups to implicit resolution where there has been a lot of essential polishing in details and i think that avoids a lot of surprises that you had before so not all of them but i think it's a definite improvement and then there are the new constructs so a big new construct is enums which provide a concise syntax for enumerations and algebraic data types so i jump to the data type immediately so what you can write to essentially make this make a concise option you can write enum option and it has a some case or it has a number case and that's essentially a uh a special case case of those uh enum syntax are the classical enumerations like color case red green blue that essentially gives you three cases that do not have any parameters so enums are a nice way if you have a lot of data to define if you have a lot of classes adt's algebraic data types to define then enums are a nice shorthand for those things because you don't need to write a lot of classes and objects that extends classes and so on so for that they're actually quite quite quite good but they in fact they map into uh class hierarchies so they're not something that is essentially a radically new construct they're just nice syntactic sugar on top of the class hierarchies here's another one that is a very recent edition and i am i am quite pleased with it it's the target name annotation so target name used to be called alpha and it's another thing to essentially get more usability this time the original motivation for target name was that it addresses the the problem of overuse of symbolic operators i think that the peak of that is definitely behind us people are more careful with symbolic operators but it sort of lingers that people say oh scala is unreasonable because of all these symbolic operators and it's true that if you have a symbolic operator then uh it's hard to google for one so how how should i even and it's even hard to pronounce how should i call plus plus equals well plus plus equals is fine but if it's something with a percent dollar or whatever so how do i call this thing so now you know how to call it because it's recommended that you add a target name annotation to anything that is symbolic so here we have this plus equals with the target name and that means that the plus plus equals method now is should be called append and that's essentially something that you can google for but it's also something that you can use for interrupt because when the method gets compiled it will be called append so previously it would have been called dollar plus dollar plus dollar eq or something yeah i think that was the encoding so essentially every uh operator symbol got had its own encoding and then we concatenated them that's of course completely unusable if you want to call this thing from java say so now the the plus plus equals has the name appended by code so it's very easy to call it from java you just use a pen also uh it's it will be the append thing that will show up in stack traces or things like that so that should also make it more easier on the on that side okay so that's essentially already two benefits uh it explains what a symbolic operator is and it helps with interrupt but it still it even has a third one and that third benefit is that it avoids the dreaded has the same name after erasure errors so what are these errors so the issue is that scala has a much richer type system than the jvm bytecode by now every jvm language has a much richer type system than the jvm byte code the jvm byte code corresponds to java java 1.4 so pre-generics and that means that sometimes things that look different in the source have actually the same type in the bytecode so for instance if you have here these two definitions of vf then what would happen is these are call by name parameters they get both mapped to a type which is called function zero so the uh bytecode type of f would be in both cases it takes a function zero and returns an end and of course that would be a double definition in the byte code so you can't do that the compiler will refuse it and saying well essentially these two versions of f have the same name and signature after erasure but the question is what can you do with that if you have that so there's not much you can do previously the best thing that you could do was that to add a dummy parameter to one of them which is kinda ugly so now you can just give one of them or both of them if you so choose a target name and that will resolve the conflict because now you don't have two versions of f in the bytecode you have f underscore string and f so that takes care of the problem so in the future whenever you get these erasure conflicts which i know can be very very annoying uh target name can can essentially save you uh there every time just have to to add the proper target names that you done okay cool so that was that and let me go back to the to the normal slides now okay good so i'll just skip these yeah so here's a list of replacements which i think is also important to see what we what we where we migrate so uh instead of package objects uh there's a new uh idea too that you can write every definition top level you don't you can have a top-level def you can have a top-level valve and if you uh want to model something like inheritance of package objects and you have a thing called exports that essentially give you aggregation uh so proper com composition instead of inheritance then implicits on many of these things deaths valves objects conversions have been replaced by givens instead of implicit classes you have extension methods those i was showing instead of macros you have a new macro microsystem that is based on inline staging and match types so that gives you a new foundation for meta programming which is a lot cleaner than what we had so far so um so far what we have for macros which are as you know still experimental even eight years after they were first released is essentially a spilling the guts of the old scala 2 compiler let me say it this way so essentially it opened up quite a lot of things that i believe should have stayed internal for the macro user for the macro library user uh plus side it's super powerful uh you get access to essentially lots and lots of details of the compiler so you can do lots of lots and lots of things quite quite advanced miners it's super dangerous so what you do here it wasn't really meant to be used for for public consumption and the the other thing is it's super unprincipled because uh what you what you do is basically a snapshot of a particular compiler codebase and no matter how well that code base is designed it's still a snapshot so the new system is a lot more uh fundamental so it uses things that are quite well known and it uses things that essentially compose so there's one axis which is just inlining and there's another which is called staging which uses quotes and spices uh if you merge the two then you get already quite powerful macros uh the uh the macros that you get that way have been explored first in meta or camo so metal camera is a predecessor that does things quite similarly to what we do here if you need to do go further then we have a second layer that is based on reflection on our tasty so that is essentially a more implementation oriented view but it's a view that essentially is opt in and hopefully in many many parts of macro implementations never have to touch that and even if it's off opt-in then as you'll see the tasty format is actually one thing that we will standardize and we will keep stable so we will guarantee that this is kept stable over a very very long time okay and then there are essentially two big big ones one is the replacement of implicits and the other is indentation so that's essentially uh two uh monumental changes from two to three and so let me say a couple of words for each so um the replacement of implicit is essentially a re-thinking of inference the term inference means that given a type t generate a canonical value of that type generate some value that has that type so that's essentially what happens in implicit search and also happens in type classes and happens in a lot of code synthesis tasks which are essentially more advanced and more research oriented so the core is always i have a type or some other description and the compiler will actually make up a value that has that type so the previous thing that is kind of used for that was implicits which where i have argued in previous talks scala's most distinguished features but also the most controversial one and the givens are essentially a complete redesign from scratch that i believe are a lot simpler and safer they emphasize intent what you want to achieve over the mechanism how you achieve it and i believe they make the idea of inference more accessible and they avoid quite a lot of abuses right now so hopefully i know that turning friends and implicits are both always very powerful they will stay that way and always therefore an advanced feature feature that essentially is is a bit hard to grapple with but i think that we sort of have avoided as much as we could accidental complexity that got added by the previous implicit implementation which in its defense one should say that is something that was pioneering a lot of the things that didn't exist before and it was something that grew over time uh so uh in that sense if something sort of if the original spec for implicits was something that uh was not what the final uh implementation was and it had it it grew then there's some some unfortunate things that that happen over time with that so givens are sort of the opportunity for a restart there so here's uh the uh uh intro for givens uh the it's sort of the standard type class control uh where you say uh with if you do type classes then uh what you have is a trait uh ordered of t as an example and ordering so order of t that would be sort of the correspondence to ordering in the standard library so here it has two extension methods as it happens uh compare two and uh oops there's actually a mistake here it's uh it's uh yeah let me just fix this i can do that okay the real real time slide amelioration so the extension method has uh the two extension methods one is called compare two and the other is called glass and it calls compare two so that's my trait uh it's parameter is traits like that we often call type classes and then i have an implementation of the trait that i said well i want to have ordering implemented for ins and here's how i do that all i need to do is i have to give you the implementation of this abstract compare to method and here's what the implementation is so if x is less than one yeah well you see the implementation here now i have an instance of this or type class so now how do i use that so the most fun fundamental way i can use that is with a using clause so using clause is uh what used to be called an implicit parameter clause so you just write it with other parameters it can be mixed it can also come first now but here it comes last so you say using order of t so that says well it you it needs a evidence that t is ordered using order of t that's what it says and then i can essentially just use it and i will use it not by name not by referring to it but by just passing it on to the less than method here basically so what's important here is is that uh to make this all work what does not matter so i think it does not matter are the names of these things so what is the given instance for ordered for for order in called you can name it if you want but you don't have it likewise what is the evidence that i t is ordered called you can give it a name but again you don't need to and typically you don't in particular if you just pass this on to others then the name is actually something that is irrelevant and therefore should be left out so that's a big change compared to the previous implicits where you often have to name these things and that led that often leads to just more obscure code another thing that the combination of extension methods and givens provides you is really nice support for type classes so here you have a standard example of again semi group mono8 so so here you have the combined method and the mono8 is a semi group with unit and then you have a type class instance monoid of string where essentially we give you both an instance for the combine method we implement combine and we implement unit and here we have a usage of of the monorail in the sum method which uses a context bound so context bounds work of course also for this new givens so if you try to do this before in scatter 2 then it would have been quite complicated in particular with infix methods so if you want combined to be used in fix then so as i know so as just as a method not as a binary function uh then you have to jump to quite a lot of hoops with implicit classes and so on so by the time you're done uh you you probably don't recognize the structure of your solution anymore because of all the accidental complexities to actually get these methods to be callable with the right dots and so on so that has all gone away and i think now the solution is as clear as it could be another thing that has changed is implicit conversions so implicit conversions the more we use them the more we are convinced that they really have to be tamed and restricted a lot and one good start of this is that now implicit conversions are not essentially a feature by themselves anymore but they are a instance of a standard implicit class conversion so to do a conversion from string to token you write given conversion and then you write the you have to implement an apply method that essentially does the conversion of string to token you can also make this shorter by using a so-called alias given so you can say the given conversion from string to token is the keyword method that essentially takes a string here and returns a token so that's it was a very quick i don't have more time overview of uh what happens in the uh implicits if you look at the doc pages again there's a whole sub chapter on that whole sub-menu tab on contextual so contextual abstractions collect everything that actually happens in that area the other big one and very controversial one are optional braces so what uh scalar 3 does is it makes curly braces and parenthesis also i should say option more places so instead of braces one can use indented blocks now it's worthwhile to say that the braces are actually optional now so some would write a program that you see here like this with the braces here and here but the braces here the second braces here they are not needed because the else part of the if then else is actually a single expression so some people actually leave out the braces sorry some people leave it out like that also there's any there's the issue which i personally don't don't really like aesthetically that the else hides between behind the closing brace uh in in the line so it really should be if and else on the same level but no with this style you write closing brace and then the else so some people write it differently again the right closing brace here and then the else on the new line so there's also quite a lot of variation in in formatting and finally even with the parents of the conditions there's variations uh the where sometimes you write a space and some sometimes you don't so i said there's actually quite a lot of radiation already in writing these things so in the future what will happen is that you can now also write it like this so you can also leave out the braces here completely as long as these two things are indented that's okay and that avoids a lot of essentially busy work going back and forth with the braces and it also frankly avoids a lot of errors because i i don't know about you but i often made the error before that i just added the thing and then i forgot to add the braces and then the program behaved in mysterious ways that often were easy to to find out but sometimes we're not and while we're at that to remove the braces we we are actually also now removing the parents so you can also write it like this with an explicit then afterwards and that means you don't have to write the condition in parents anymore and once we did that there were actually also quite a lot of other uses where we got rid of braces and parents so these are all really now sorry legal syntax so you can write fours without parents or braces around the generators you have do for a while you don't need braces in the optional in the match statement anymore nor do you need them in the try before we discuss that and i think the discussion would be endless what i want to do is just show you what it looks like so this is just some real world scalar code it's part of the compiler uh was written the whole thing after the uh the change to to the thing so so that's just one thing that essentially it does a flow analysis for nullability uh in in the compiler so when something can be null and when it comes in now so what you see is you have a case class and here you have is empty you have sequence you have art so i just want to give you an overview what that looks like so i think what the the conclusion or the what we take back is it looks actually very quiet so it looks uh sort of quite powerhouse and not so much baroque so it's powerhouse instead of baroque i would say it's it's a very clean uh visual aspect that doesn't really use a lot of sort of spurious elements we got rid of semicolons a long time ago so now getting rid of braces adds to that the other thing i believe it shows is that it's it's this it's more condensed uh vertically so closing braces in particular long sequences of closing braces they tend to to to take up a lot of vertical space which is no longer an issue so uh that helps uh by itself uh what we have seen in our code we get at least a ten percent reduction in line line count uh by going to this essentially uh bracelets uh syntax um so another thing that i haven't mentioned but that i believe also is huge by itself is that now you can write operators in front and i believe that's really where there should have been all along because it makes things just so much clearer to visually to to to actually parse to say i have this is track condition and i say well i have one condition here and then or and then now i do have to write braces but here the conditions here they actually line up with and ampersands in the front so i know immediately that this is a a conjunction of several conditions whereas otherwise i would always have to look at the right at the line ends which are much much harder to spot so the the braces here are still needed there could be some extensions in the future where they will be optional as well but that will not appear in three zero so that will that that's left for for future once the ecosystem has migrated here okay let me just go back to the to the palm okay so one second i just have to get my just noted i was not on power so okay good so let's um quickly uh go go on so option braces were very controversial so in they were added initially as an experimental feature they are now used quite heavily by myself and some of some people in the core team for more than a year and i've taught them in class twice and i must say the experience has been positive beyond all expectations it's for me it's it's it sounds weird i know but it's the single most important way how scalar 3 has improved my productivity you could say well how how is a trivial syntactic feature like that more important than let's say all the new contextual abstraction designs or extension methods or uh inline and staging and all these things but for me that's that that wasn't the one the one thing because it's just makes code cleaner easier to read easier to write and and avoids the the busy work of adding and removing these braces programs become shorter like i said already and you stay in top sorry and you stay in the flow so there's no need to go back and forth in sending the inserting these braces so if i should put it in a single sentence then i would say writing code based on indentation is really like lego bricks you have statements you put them together at the right point uh you click together and that's it whereas bracing the braces there's like bailing wires so you have something and now you have more than one thing i said oh my god it falls all apart we have to wrap things around it some bailing wire and braces indeed they look like bailing wires so so it's a much less pleasant experience there were a lot of doom sails before that would say this is going to be terrible for refactoring and so on in my experience nothing so program changes were more reliable than with braces of course details matter so i i don't want to advocate any indentation design and in fact we took some time quite some time in several trials but i think now we got it mostly right so all this has been looked after in the sip process this kind of improvement committee was reviewing the complete language all features were discussed some features were changed or dropped as a result of discussions and we have also invited community feedback on scala contributors for almost all of those features by now good so to quickly uh finish uh escada 3 then a new language and you could you could say yes it has so many language changes it has some things that got removed uh the new constructs that improve user experience and onboarding uh all the books all the teaching materials all the courses will have to be read with them on the other hand you could say no it's still scalar uh all core constructs remain in place um sometimes they have a new syntactic uh form but essentially they're mapped to basically the same thing and there's a large and very practical common subset between scalar 2 and scalar 3 so a lot of the libraries cross-built between scalar 2 and scalar 3. many of the of the programs in the community built crossbow so i think the real the the the final answer there is it's it's a process so scatter 3 0 is not the end of the 3 scalar 3 development so far it keeps most constructs of 213 alongside the new ones but the some of the old constructs will be deprecated and phased out in future 3.3.x releases and that will essentially make them the language evolve naturally into into a new direction so that means that right now we do have some temporary duplication for instance old implicits and new givens but i believe the end result is a more compact and regular language so here's joshua to quote him he said it's very much a new experience and very much still scanner so people have criticized and said well why do so many things at once and really the answer is it's the it's the books it's or courses or videos because uh it's such a big change that they will have to be rewritten and they are rewritten there are lots of people who essentially already get uh get on track to change the books so my own book that i co-authored programming in gala will be rewritten programming scala by dean oneplay he's very busy rewriting it and so on so you expect essentially a new set of uh documentation and materials come up and because that is the case that as a book author if you want to do that then you don't want to do it again a year from now or two years from now something like that so that means that we had to get it into three zero if it affects the foundations if it simplifies life so it's something that you want to have in the book because it simplifies life particularly for beginners and if it replaces an existing feature because you don't want to essentially build in obsolescence into your books so that's why essentially it is in fact a big bang release it's not it's not a continuous improvement so that means we prioritized foundations simplifications for developers and restrictions and other features that essentially aim for added power and expressiveness got delayed and some of them will be added in future releases okay so will this be a python two to three situations i don't think so we don't need to migrate everything since we can use the 213 binaries that i think is huge because it means that really we don't have a split in the ecosystem we can use the same binaries from both of them that's in a sense the situation is even better 3 0 to 13 then let's say 213 versus 212 where you had to use either the 212 or 213 version of a library and if you still uh depended on a 212 one then you could not migrate to 213. that's not an issue now you can reuse all 213 libraries in scala 3 with the exception i should say of macros macros is the big [Music] game changer here that you say the scanner 3 compiler cannot expand a scalar 2 macro on the other hand you can have dual macro definitions in a single project so you can have a project that is cross-compiled for 213 and 3 and that can that has uh macro implementations for both of them so alternative micro implementation for 3 and 213 some projects have started doing that the other big improvement of course is strong static typing which means that yes there will be problems migrating but the errors that will be detected are type errors so you don't need to essentially wait until time to see whether something some things break we have been quite careful uh in actually not changing the runtime behavior of things including some things where we wanted uh to change it but then we backpedaled because we said it's just too risky so one thing where i would have wanted to change the runtime behavior is in the synchronization behavior of lazy vowels which makes them essentially less fast than they could be and then we said well no we can't really introduce new race conditions and scalar three programs uh that for porting code that would be really bad and number three i think there are actually lots of benefits of migrating to scholar three unlike with python 3 when it came out so if you look at the situation of scala 2 and 3 what's the relationship between the two so the current situation until very recently was we can read scala 213 binaries and we actually do that by reusing the scala 213 standard library so that's essentially so called scala pickles format that can that is understood by this color 3 compiler and that means you can have a scalar 2 module and it's got a 3 module that depends on it no problem so what we now also have and that will be in 2 13 4 the upcoming 213 release is going the other way so that's called the tasty reader tasty is this color three internal format and we can read it and understand it now in this color 2 compiler so so that means you can actually write a library module in scholar 3 and have it understood uh by scala 2. so you can write your library and you can have a scalar 2 module that imports the scala 3 definitions and makes use of them so that means we now have true 2-way compatibility between 2 and 3 and you can write modules in either one of the language and have it and have it be understood by the others big caveat to macros of course so that brings me to say well how is the ecosystem going to evolve so right now we have scalar 3 it comes with the 213 library there will be some versions in scanner 3 3 1 3 2 maybe that will essentially refine the language so they will drop some of the features that we still support for migration purposes so we will essentially tighten the language and we might also introduce some new things that essentially have been left out because we wanted to restrict the set as much as possible for three and then there will be another big shift uh sometime down the road let's call it three dot x that will be the time when the phrase tasty so taste so so that means that by then essentially the whole thing will be its own platform uh scalar three uh files will can be published in tasty and can then essentially automatically cross compile to multiple platforms and multiple versions so by then i believe that this will by by and large solve the binary compatibility problem that will sort of be the end of times when you can stick to one version and stay staying on that version forever because tasty is a format that we control and that we can evolve and make sure we evolve that in backwards compatible ways and that will also be the point when we finally won't need that scalar 213 library anymore and we can make the next big jump in the in the standard library and that will be also the point where then any futures color two versions that that still exist will essentially consume the the standard library and and the rest of it from scala 3 through the tasty reader so that's the plan uh how to migrate i'm out of time but i just want to say there is a migration guide you should look it up it's it's fantastic it gives you a lot of details how to uh get started today to migrate a lot of tips a lot of points here to a lot of help for you to do that so that's definitely if you google for scala migration guide then that's that's that's the place to start okay so that's the end of the talk thank you for uh for listenings and staying with me so far and i'm happy to take some questions you