Scala 2.13

scale.bythebay.io: Adriaan Moors, Scala 2.13

Recording: scale.bythebay.io: Adriaan Moors, Scala 2.13

you my name is John Morse I lead the Scala team at light Bend or type Bend or type safer typeface or whatever you want to do with the name we're not too fussy vanunu for about five years before that I was an academia doing time there with with Scala is the mic okay cuz I can't really hear whether it's coming out or not no it's not in the back I'll try to get a little bit closer is that better okay you haven't missed anything I just said hi all right so you know Scala is an open source language and to us that means being open to your input so I'll start with you know I have five minutes maybe at the end for questions but I'll be at our booth for the next hour after this talk if you have you know any thoughts to share on how we can do better if you have questions or whatever and you you know we don't have time for that right after the talk I'm just gonna run over to the booth and I hope I'll see you there for you know your thoughts on Scala in general and so a big part of what we do with our team at live band is to make sure that you have a good time using but also contributing to Scala and so thank you very much for using it in the first place and for contributing to it even better there's a long list of contributors and and it's always a thrill to see new faces on the on the pull request queue even though sometimes it's also a little overwhelming in terms of you know you versus us getting to your to review your pull request in time but we really we do our best and we're looking for ways to do better there too Seth is here on the skull team the rest of us are pretty distributed and so since this is the end of the year and people start making lists and new year's resolutions and I don't make those privately but I guess for for the project the main thing that I would want for next year is to double the people that are contributing on a regular basis to Scala that are not names that you would recognize so me BFL our life end and that you'll start recognizing from being contributors to Scala and that's an intent of being even more available spending more time making sure that you can be successful doing that documenting our process on how you become a committer being clear on the kind of stuff that we don't have time to work on but that we would love someone else to pick up and things that we think you know need a sip or need a lot more discussion or maybe we'll never land and Scala we're never taken away subtyping sorry guys it's not gonna happen so right now it's about two to one in terms of commits it's a very poor metric but it's about two to one and so the goal is to get that two to one to one when we can so like I said we want to do better in terms of highlighting the kind of work that we think is a good way to get into contributing to Scala we have that label but don't go to it right now because there's not a there's not a lot of stuff there but we're gonna work on on making a better selection of issues or features or improvements that we think we could help you with to get started so you know a compiler is just a piece of software right it's written in Scala you know Scala already it has its own vocabulary and it has its own way of doing things but once you get into it it really is just another piece of software and I think that's one of the one of the beauties actually of programming language theory is that it all kind of like it's also meta but that sounds crazy but it actually is kind of also beautiful because it used the same tools to write your programs that we use to write write the compiler right and like I said it just takes some time to get into it and and and we want to be there for you to help you with that and and both you know commit to spending some time on your Poe requests and getting it in as a more kind of official process so I mean we do that informally when you contact us we say sure yeah that sounds like a good idea let's work on this together but I want to be more clear that that's available to you and that we're there for you for that and I'm just you know also improving oh I'm going to the wrong way improving the response times for review employer requests so one of the the lower hanging fruit that we've some of the lower hanging fruit that we've been picking in terms of contributor friendliness or user friendliness as standardized on github for everything all the release notes are there we moved from dara to github we do have who repositories one is explicitly for bugs and is a one on-one import from Jerez as close as we could get to preserve all the numbers and stuff like that and then there's one that we used for planning and that will also be used for a kind of work planning with with all of you that that's why that's a public repository that's where we plan our work inside the team so you can see you know what we're working on what we think would be cool to work on so that it doesn't drown and the bug reports not that we have very many bugs but you know still it like nice to keep them separate okay we have a lot of books but we're you know we're a big project the Scylla Center is of course also a central party to being open to the community to helping the community they represent you on the on the community on the Scylla community center on the Scylla Center Advisory Board sorry it's somewhat the acronym isn't great but okay we moved from Google Groups to discourse I think that was a pretty successful move we're on get er try to be available on Gator it's it's hard to be on all those forums at the same time but we always try to have someone at least from the team around there Seth was sitting right there if you want your hi Seth if you want you to add your project to our community build yeah he's the one on the corner here can't get him to raise his hand okay so Seth is responsible for the community build he tripled the number of projects since April last year that we that we build to verify that we don't break anybody's code when we go and we change something in the compiler I think that's one of the great things that we've actually we've done over the last couple years which has given us more confidence to for example remove features from the language or tweak features before we would never know like is Scala test going to compile or shapel is going to compile after we do it is now we can know that you know before we even merge the poor request if we want it to so that that's a big enabler for changing the language more quickly our long-term support cadence is about 18 months between major releases and when you total all the small releases that we do we do about one every six weeks and we try to keep that pace or at least maybe even go faster to give you a sense of that for the 210 series which started December 2012 can't believe it's been five years you know we did about five updates and two and a half year so - a year four to eleven we did about two point six six six six six six six a year and and some more sixes - okay and now we've done already four in one year four to twelve I don't I don't think we're gonna manage to hockey stick we kind of you know updates that we can manage in a year but we're definitely trying to bring you more fine-grained updates - Scala in addition to sticking to a more or less 18-month cycle so that you don't have to like really upgrade your codebase all the time here's how that that shakes out in terms of colors and lines I don't know what to make of that you guys need to upgrade to 12 more who's on who's on to 10 okay that that's that's a good number of hands for - ten - eleven that's yeah spark well I heard they're getting close to 212 but I'd love to hear more about you know we've talked to them about Sam types and when we were working on - 12 do - to help with with the API design but it's a tricky one - 12 yeah you're ahead of the curve here or I'm sure that's that's you know also selection bias of being at this conference who saw no - 13 milestones what you don't have to be ashamed about that it's okay no that's okay that's okay that's I'm happy to see so many hands go up 4 to 12 who is not using Scala and but we'd like to I don't know if you don't want to use collar don't tell me I'm gonna be depressed for the rest of my talk there's one or two people there like I like to use color maybe but so most people who want to use Scala it sounds like they are using some version of Scala that's great so you know I asked that because we have an enterprise thing to plug for you Seth right there hi Seth he did the fortify plugin I don't know if you work in industry you may have heard of it it's a common thing on checklists that you need to you need to satisfy to ship stuff and so the Scala compiler actually has a plugin that omits to fortify intermediate representation so that you get pretty accurate analyses out of the analyzer that microfocus these days ship so it's a it's a security product that does some static analysis on your code it's kind of an industry standard thing and so Scala supports that now it's talk to our sales people I'm sure they'll be happy to hear from you so since it's talked about is about 2:13 I'm going to talk about 2:12 a little bit because we're still so happy about it you know and they're still people not using it it was all about it was a compiler release so we changed a lot of what the compiler does behind the scenes but also very visibly we're compiling to to Java 8 that was a big step for us I remember thinking about that a couple years ago and being like agonizing or people are going to be willing to upgrade to Java 8 it looks like that was not really something we needed to worry about now Oracle has kind of like given us a whole new thing to think about but I think the Java 8 upgrade actually worked out really well and I think 212 worked out really well so the two main things was that now finally we can compile traits straight to interfaces instead of to an interface and a class and a function matches really well with the single abstract method retrofit that they did for Java and functional programming or at least programming with functions and invoke dynamic of course our good friend Indy the bytecode macro so concretely what does this mean for even just the Scala compiler a significant reduction in bytecode and I've heard really really insane numbers of people who use a lot of land as of like shedding you wouldn't believe how much by code that that difference makes if your code is really heavy and lambdas so that was a big win of course we're always talking to the dottie team there especially the trait and lambda encoding there was a lot of fruitful collaboration between them coming up with some ideas as testing it into community build and saying that's not gonna work out looking at how the JIT deals with default methods and stuff like that so there's a lot of you know experimenting going on and dotty and then you know validation on our and an engineering to make this production ready and there's a bunch of other things that that that have made their way from from ideas and dotty to implementation and into twelve I'm not going to go into the details something I have to save something for questions at the booth right otherwise no one's going to show up there we we consider SBT an integral part of Scala and so when we work on for example compiler performance that also means build performance so honor we spend significant amount of time trying to use the Scala compiler well from SBT and and also be friendly to SBT from the compiler so that made some big improvements in compilation speeds also so long activator hello SBT new so SBT one is out it's not you know my credit today but yeah anyway party and you know they run Scala 212 or we're in scale to 12 that's BT so that's very exciting now you know I'm right after a really great functional programming talk so I'm not going to talk about this much and I'll just you know go through my slide so you can't see them but it so functional programming has to me just means programming with functions what Rob was talking about and I really really like to talk was what I would call like pure functional programming or like mathematical function mathematical functional programming but I think pure is a good way for it I mean you know that makes us impure right like there's a reasonable Scala I'm the unreasonable Scala guy so to me like all these things are our tools for you to be productive with and you know to to to communicate the intent of your code to your to your to your future selves or to your current colleague and functional programming has a lot to offer in terms of simplicity I think and the way that you can really express algorithms that code that have great cohesion and that let your reason about them so that's for example where purity comes in right but it's it's it's not functional programming because math is great even though it is it's you know we have this problem to solve our code is complicated how do we simplify it how do we express more directly or how do we write code that like a spark backend can optimize and and so one kind of the example but I think it does drive the point home or at least I hope it will and maybe you can tell me later if it didn't and I can tweak the slide but expression is like an algorithm that is really like much closer to what you would write you know on a math paper or how the way you would think about this in your head like I want to do this or that and then you know pass it on to a method like if you don't have expression first thinking you need to pull that out in statements and say hey computer first compute this condition then think and store that result somewhere and if that's the case put that in that variable otherwise put that in another variable and then you create distance between how you compute the argument to that method and where that argument is actually consumed and so the bottom version of that rewrite you could easily imagine more and more code kind of accumulating where that comment is and you know you're a fact or your factor and after a while you know there's no more connection between the input to that to that method or a function and and what you originally wrote and I think that's a really real thing that happens me so Java has the ternary operator but now you need to you know use a different syntax for something that is really conceptually the same I kind of get some people like stare at me and other people go like yeah that makes sense I and the room is too big for interaction but please let me know what you think about this I think the key thing here is that we know really well from lots of other programming paradigms how to compose data why not apply those same tools to your code and when you when you think in terms of statements like when you think about step 1 step 2 step 3 return something throw some exception mutate some something in a distance somewhere that I hope will still be what I put in there when I get to what I'm actually going to do with it later you're not really expressing yourself that's succinctly anymore and you're also not really able to reuse code that actually talks about how things flow there have been way better presentations on this then I can do at this kind of abstract level but a lot of this is about a lot of the cool stuff that you're seeing these days is is about thinking of code as data like staging the collections where iterators are just a reification of data processing steps that you want to the effect on your on your on your collection and then you know the the library can look at that and optimize it PACA streams for example you express this whole processing pipeline or graph that you want to do with the data that's flowing through the system and then the implementation actually looks at all your code and just manipulates it like it was data and optimizes the out of it so the way to think about it is you don't optimize framework framework will optimize you okay and I think that's that's a great thing to enable with thinking of and I think this is also kind of what Rob was talking about earlier is that once you have these these these Combinator's you can think of more efficient ways of doing these Combinator's or you can start thinking about doing you know fancier stuff than just saying this and then that and then that you could say well if I'm doing all that how about I just do this in one shot you know like fusion and deforestation and all that cool stuff that you can only do of course if you're managing your effects carefully and as explained very well before me when you when you have that kind of purity or when you when you when you know what which effects are happening you can just look at the types and and put stuff together and that's very powerful when you think about larger scale things like you know manipulating really big datasets are gonna be very expensive to run an experiment on and it turns out you thought that was a string but actually was a date or something like that you want to know that before and with that additional knowledge you know the the framework can do a better job of optimizing your code obviously so I'm assuming I'm kind of preaching to the choir here but you know these abstractions also have their limits they have a runtime cost they have a real really a very real runtime cost they have the buck time cost they have like of what the per second kind of cost you know abstraction should really be about I don't want this thing to go wrong it would be really bad if someone where I just tweak this abstraction is not oh I might want to change this later but right now I only have one of this let's just factor it out anyway and obscurity intent of this thing because maybe the intent was there actually is only one thing that you want to do here so use this with with with some compassion for your future selves or your colleagues or some trepidation you know abstractions don't necessarily make your code better but they definitely have very much potential to do so it's also about convenience and then we talk about things like type inference but don't take that too far public types are documentation you could say well we just generate the types well no that's a maintenance liability if they really are purely generated and then you might as well not write them right so that's kind of a dega java for those who anyway case classes and pattern matching are convenience if you deal with a lot of data you want to take it apart and you want to put it back together safely that's that's a great way to think about things and here you see again that it's about values and expressions and not I have this thing that I need to build up mutiply and hopefully at some point I'm done it's really about thinking about these things as mathematical ethereal objects that you can reason about later and it's also just about sometimes you can just feel okay and just throw your hands up in the air and sprinkle some plus and minuses and note it it'll be okay right and I mean I have had to slide in this deck for a long time and I keep it there because people laugh at me and I think they think I'm funny but it's I mean it's it's it's a good thing right it's not like you should feel bad for not thinking about this you also don't think about oh am I gonna get no such method errors or am I gonna get or this clause doesn't exist that you tried to extend or you know the type system can do a lot of good for you if you let it and I think variance is one of those examples that is a little bit more exotic but it's the same thing and we got your back with this you know we that that's part of our job is to make it easier for you to express your code to refactor without fear to actually evolve your code bases to know what they're doing but also we don't want to get in your way so there is just for us as well there is a limit in how far we we want to go with abstractions some things are just too complicated and have too much of a cognitive burden for us to impose on you and so for example effect tracking is one of those things be great to have we just don't know how to do that and not you know drive everybody away so to get back to variance what I mean is you don't have to know anything about variance you just have to have you know this this is intuition for functions that thanks flad I'll keep the slide too for the next version so you know functions are just as this this intuition that you say well if I have a function that actually takes more arguments that's totally fine if it imposes fewer restrictions on its input and actually provides a better output then I can use that function instead and that's covariance and contravariance contravariance for the arguments covariance for the result in java it's pretty gets pretty wild you have wildcards everywhere and the users of the function abstraction have to remember which way variance goes you know contravariance for the arguments covariance for the result type imagine having this sprinkled all over your code when you're just all you're doing is putting a function literal in a local variable I mean they're doing something about this and they were very well very well aware of it this is just to show that certain things in a language that you think wouldn't be related to being nice for functional programming actually are and having been designed from the start for this it makes a big difference in your day to day usage of that language for functional programming and you know there's many more examples like that so now that I got that off my chest I think I'm just gonna drink some water let you all go alright this is actually what we're here for Scala 213 so we're about I would say half way through through the timeframe for 213 it's due first half of next year and we're still talking in halves not quarters that's that's kind of I do need to do some hedging I hear myself a lot so 212 like I said was a compiler release 213 will be a library release so we're doing that because we don't want you to have to adapt to new language changes and new library changes at the same time on your upgrades and so we're kind of spacing those out there's a ticket on our Scala depth record that has the various themes that we think are important or we're important when we working on them excuse me and and so I invite you to participate and into liking or disliking of various ideas or adding new ones so the headlines as you are well aware working on simplifying to collections Stephan is leading that work our end and an EP found the scale Center are also involved in that of course we're currently bootstrapping the compiler on the new live on the new collections so that that's that's I think it's down to like the double digit compiler errors last time we talked and that's I'm gonna talk a lot more about that part modularizing the the the core library that's what we started doing in 211 and you know now that we have another library release we're continuing that work with Java 9 around it makes a lot more sense also I think to do that more modular ization and user-friendliness is a big theme for us that we care a lot about so I think you know there's a fun did a really good talk at Scala world and have wrote actually really nice blog about this too so I'm gonna mostly refer to that and so obviously upload the slides and you can click on those links I know that's kind of hard to to write down blog but you know there there's they're there and the links are in the in the slides that I'll distribute or tweet later so the old collections were pretty good but they definitely suffered from a little bit of over engineering and and so we're looking to simplify that both on the usage and an implementation side now you know I know people are using the collections or at least I assume you are so we don't want to you don't want to complicate your lives too much there there has to be some value in the upgrade right so we're definitely working on making sure that let's say 90% 95% of standard use cases you won't notice the difference if you're using breakout or you were defining your own can built from instances you might have to read up on the blogs and maybe pitch in and discussion if you're afraid you're going to be affected too there's still time to tweak certain things to make your life easier so can build from it's a beautiful thing it also caused a lot of grief it was it was it was the intent was pure but a lot of people felt that they were being lied to and so we've vastly simplified it and it's not called build from it's not on this slide anymore because this version of map doesn't need it and in fact most versions of map don't need it when you're just doing simple overloading we fixed a bug that had originally kind of driven us towards the can build from solution where you can have an overloaded play morphic higher order method I'd still get type inference for the argument types of the function literal there is a link there that you can read all about that but the idea is that now map is just overloaded like you would overload anything and not overload it by using implicit I think the signature it looks a lot cleaner we still do things like can build from so breakout like I said is gone but there's a much neater way to do it before the two method had a type parameter so you have to look pretty carefully I think I got the phone big enough that you can see the difference that these are pointy sharp danger Will Robinson and these are nice and round values are you know much safer to deal with and much more versatile so here you can pass in sets bits halves maps we don't care you can you can build to all of those and in combination with views that actually work you get a very nice alternative to what breakout and was originally for and with much less crazy magic so like I said views actually work they're a lot like Java eight streams in fact we like that idea and and so you jump into the view world you start reifying your operations this is all the code that you're passing in is date as data the the few hangs onto that and then when you ask for the actual result it'll run your pipeline that you've constructed they're lazy collections are also built on that so there's a lot of lessons learned in there and a lot of really nice cleanups and very pragmatic cleanups that have gone into the redesign and I'm excited I'm really excited about it and please take a look at Stefan's talk and his blog and let us know what you think we're finalizing the design and beginning of next year it's it's mostly done now already so you know hurry up and give us some feedback if you think there might be something in there that you that you don't like parallel collections are already out of the of the of the standard library there now extension methods to get into the parallel hierarchy one of the things that actually complicated the old design was that a try to abstract over being sequential and parallel and turns out people actually care whether something is parallel sequential so don't over abstract you know that that kind of goes back to what I'm saying before you don't really want to mix those things up so there's no point in having a common supertype for that the the mod realization that we've been doing since 211 has culminated in a standard library that fits into the compact one profile so for you're not familiar with Java 9 that's the difference between like a 20 Meg image and a 200 Meg image or something when you're when you're deploying to dock or whatever they call these hip things these days I'm just in my in my happy sheltered you know ivory tower and you know we we definitely want to continue making way for some of the older stuff that was in the standard library that a grad student wrote me for example thinking that would never be used you know like muds from now let alone a decade from now so some of that stuff just has to go and we're very thankful for for for everybody in the community you who's working on adding more modern implementations for those modules so I know faster compiler and made it to like past you know I don't know like at least have to talk it didn't talk about a faster compiler who like thinks that is like the major hurdle for adoption for Scala lets say like to break through to like the next level 1 2 3 4 5 6 so ok let's abandon this effort I don't see too much it'd be a lot easier to just run in your browser or something that'd be that'd be cool too okay so we're gonna work on that anyway I mean we have been you know for a long time now actually we've we've locked up Jason for a couple months and he comes back with like 20% improvements we feel like we've kind of tested his limits in terms of how long it cannot see his family so we're probably going to have to like rework or our strategy there and so talking to - to our SC R stands for a reasonable and Kentucky Mule that stands for a cocktail but we're definitely talking to those guys and looking at those ideas and pulling them back in to the compiler is is one of the the big projects that we're working on well now in terms of coming up with new ideas and fleshing them out and next year in terms of experimenting with them we have automated benchmarking and charting that you can use to illustrate how much faster we are so this it's this much faster like you know that much faster I mean that's that's pretty nice we do about 120,000 lines of code in 35 seconds it's what that says so you know if your code base is about the same size and you spend a lot more time and the compiler may be try staying in SBT shell or like you know figure out what's going on we'd love to know and that's definitely also something that we want to work on next year is to give you more tools to figure out how many lines a second your compiler is doing Josh how to how to open a bug about that recently and I think that's a great idea and also would be a great thing to to contribute like as an SBT plug-in or something like that but so you know it does like three thousand three hundred lines a second it's not exactly terrible but I agree it could be better okay user friendliness for to me that means better tooling and better Docs and of course that means a lot of things right so what do I mean so these are examples actually of stuff that we would love some help with because we just can't seem to get to them I did a big refraction of the way that errors are reported but we never got to designing the language for actually configuring it no language design it's kind of like search in Google Docs like they're they'll get to it eventually so maybe we'll eventually figure out how to design a language for to configure our error reporting suppress warnings I think yeah you know you need those things to to actually be used in practice I totally agree it's just one of those things that just keeps falling off the wagon when you have other things to do like like Java eight support and a small team so this is something that we'd love to work with you on if you if you're excited about working on things like that you know getting more features from the rat bowl I mean and by that I mean steal them from ammonite and portland to to our rabble so that's actually what I'm working on and I told I told Howie that you know he should be afraid we're I mean glad imitation flattery and so on so we've like that if this is what I've been doing in my copious coding time is is really look go take a hard look at the repple kind of apologize to my colleagues from ten years ago and say look sorry this is a little bit over designed here and there let's clean this up and and and drag it kicking and screaming into this millennium with you know stuff like syntax highlighting we also I think a really fun project to help with you you really get like feedback of oh look there's color and I say on my console now as I type you know or I can I don't have to remember how many times I have to press up to like do multi-line history or something like that and you know like things things like nice things like that would be great to have and that's something that I'm working on super glad to see Scala fix all of and a Scala Center we definitely intend to use this already now for upgrade to 2:13 for the collections and for other for other features that are going to change in in into 14 it recently acquired the ability to do also do checking and/or linting abide is no more a little sad about that but that's okay so in terms of what's coming after 2:13 so that's that would be you know somewhere mid 2019 faster I already talked about that that's gonna remain a theme for a while and not just a faster compiler faster tooling in general if like you're you don't care whether it's the compiler that's slow or whether it's SBT starting up or whether it's this or that you know we care about the experience from once you like you know install Scala for the first time and are compiling your project like what are all the hurdles in the way what is the slowness what is causing it and how can we get rid of it okay we're definitely interested in and and there's already support out there for the language server protocol so vs code who would have know who would have predicted that we're going to be targeting Visual Studio with Scala or some derivative of it we did have a dotnet back-end for those of you who've never had long enough to remember that so anyway we've been working on while you lien actually a former type safer it has been working on that in his spare time and we're definitely thinking of investing in helping that out there clear error messages has been proven and Dottie and and rust and other languages to be really nice and and it's possible I mean if they can explain the rust type system well I'm sure we could do a better job of explaining to Scala type system so that's something I'd like to work on not get me wrong rust sure is a great language simplify simplify simplify so I'm sure this is all super easy to read you know we want to get rid of a lot of stuff and I don't really want to tell you so I just kind of kind of made it hard for you to make pictures I guess maybe a picture would be okay so there's a lot of stuff in Scala that it's crapped in over the years that works me and that I would like to get rid of and once we get more confidence that we can do that with Scala fakes and with a community build we I think we will try some of these things so this is kind of spitballing a list of things that I would like to get rid of so maybe I'll just walk you through it early initializers who is using early initializers if you if you're using it and you want it raise your hand now there's one sorry to two of you I'll buy you both a coffee and we'll call it even okay we'll do trade parameters instead so the re okay with that yeah you're okay with it yeah you were okay with it to trade parameters okay yeah okay well so trade parameters hopefully instead procedure syntax who despise this procedure syntax all right good yeah you can all buy me a coffee that I'm still I'm still still come out ahead just not all in the same day okay I'm not gonna worry it's not gonna end well just crazy existential types who wants to admit using crazy essential types crazy excitable okay yeah well John I knew that about you but existential crisis ahead for all of you I think you know as kind of already in in Dottie you know we want to do kind of the equivalent of Java bounded wild cards like existential is not ones where you can do F bounded polymorphism and stuff like that which by the way doesn't work okay like existential subtyping depends on type inference for these things and I've been friends forever bandit stuff doesn't work doesn't work for type constructors very well either so it's just kind of being honest with you about the parts that actually kind of have been fudged for years now white box macros no one cares about those right next one fast implicit scope so I mean my stance on macros is there's a lot of good you can do with it then there's a lot of really terrible things you can do with it and really slow down compiles really obscure intent we don't want to take away all the power of macros but some of the craziness is gonna have to go okay I'm sorry you know you can you can you can just I don't know I don't know what you can do but not this and so some of the some of the features that we like like deriving something to generate type class instances I think we should just own up to it and say it just needs to be in the language we can't make everything so extensible that you can do all right I hear is that like cocktails or beer or what are you buying me now okay so that's kind of the thinking there the vast implicit scope that we have just imagine like David Adam bro saying the fast implicit scope where the implicit Slom and their natural habitat it's gonna get a lot more narrow okay I don't know how to do it yet but I I want to get rid of the craziness of where all the implicit scan come from okay implicit SAR never going to go away and that's one of the things that makes kala scholar I agree with Martin on that but I hanker for that simple days before we looked at all the parts of all the types and all the companion objects and all the super classes of those and all the packaged objects and you know all that craziness I would love to get rid of that okay I'm not gonna ask who likes that or not but you can come yell at me later even less controversial implicit conversions okay we have implicit classes that should be good enough package objects who needs them seriously who needs them what for yeah top level things okay maybe we can do top other things instead how do you feel about that okay let's do top-level things instead you know like that's I mean this is all just for you know we're not a public company so I don't have to say this but I will anyway this is you know a declaration of intent now I promise is there anything don't buy light bed stock yeah okay yeah so top level things in general I think we've talked about that and I think we have some ideas on how to do that value classes boo value glasses yeah your peg types so I mean for just for the record you know we're not gonna fight this out but I'm just gonna do it sorry next slide so ideas from dottie trade parameters improved lazy files and trade files there's a lot more that that is happening in the experimental side of scala that we're closely looking at I mean obviously we know these guys so we talked to them and we steal stuff from them and they don't mind implicit another thing where a lot of simplification still lies beyond the scope you know how to type them and more stuff like you know I'm running out of time luckily so I don't have to commit to more things to put in the language there's plenty of JVM shiny coming so to end the talk you know and hopefully not the language you know we want to avoid we want to avoid Python 3 right and so that's like sorry oh oh right yes I will I will a spark guys so yeah I mean the key thing here that I see for the key challenge ahead of us is that we want to keep the language moving I think I've shown you the direction that we're thinking about which is you know making people more productive finding a good balance with exciting new features but mostly emphasizing you know better tooling and friendlier you know more professional or even more professional grade tooling around us and just not repeat pythons mistakes so thank you very much for attending thanks to all the contributors communities calendars by Rhema body any questions give one minute [Applause]