Scala 2.12 and Beyond

scala.bythebay.io: Adriaan Moors, Scala 2.12 and Beyond

Recording: scala.bythebay.io: Adriaan Moors, Scala 2.12 and Beyond

thanks Mike thanks for an introduction yeah so I I have been working on scholar like it feels like forever probably um because it is been forever about 10 years now I think um started as an intern at epfl and um been working on the compiler basically ever since um so right now I I lead the the scy team at at lightbend and um there's a lot of links into talk um um so you know you can kind of dig in later if you feel like it um there's a link on on on my GitHub um to follow along now or kind of follow up later so you know um you might know us as typ safe and we still are at heart um but right now that's that's the name of my employer lightbend um and I mean first off you know as Mike said 2120 I'm super happy to have this out finally thanks I'm sure you are too after a long wait um thank you all for for contributing and for making this happen um we're I think this is going to be a really cool release and we're very excited about running on Java 8 and um you know making use of all the shiny in there so um you know we we started with a keynote that was basically about contributing to Scala um and I I want to start my presentation to again thank everybody and and you know to point out like the large percentage of the work that goes into Scola that you know is done by by a lot of people in this room and and you know around the world so thank you very much um and I didn't make these round numbers up by the way they come from GitHub um I'm just pleased to say it's all powers of two um and and so you know we're a small team at at um at light B sadly not a power of two um and you know like in reverse first chronological order of joining the team um uh you know we're we're very happy to do all that compiler hacking and and and to work with you um you know from now on to 213 and the next 212x releases um we're also very happy to collaborate with the scholar Center um and and to really let them um be the stewards of the community that I don't think a private company can can really can really do um we were very happy to have that you know Swiss neutral partner um um to to you know Channel all the efforts of everybody that that's working at Scola and of course um you know we're we're a member of the board and and we contribute to the center and and and you know we aim to be the you know really upstanding uh members of the community um and I don't say that as a form of like we're detaching I'm saying that as a form of you know respect for the process and and for the for the organization um that is behind that Foundation um so we definitely want to do everything we can to to contribute to that to enable that and to kind of maybe sit back a little bit and make sure that the community organizes um around that um and so disal Center plays a very important role on those three missions um and so it's a process you know and those things are hard uh to get right and certainly won't be you know gotten right from the start and that's why there's two Community representatives there that you should talk to or me obviously um if you have any thoughts on on how to do this better um you know we're we're definitely here to learn um from everybody's experience in the community um you know I I hear a lot of people you know say wow you know scolar 22 took two years but we do a scholar release every six weeks which isn't exactly you know the the um the rate at which companies that that own the whole uh stack can can deploy at but I I think it's pretty good for for a language um and um for the small team that we are and just to kind of give you those data points um in 25 2015 we did those quar early milestones for 2120 we got a little bit of a later start than we anticipated because we we extended the lifetime of 211 Development A lot of the stuff that landed in 212 actually landed in 211 first some of as some of it as experimental features because we're cognizing that not everybody can immediately upgrade to Java 8 most likely everybody in this room um will soon um or has already um maybe we can do a quick show hands who's still in Java 6 or below yeah great but not everybody is as lucky as you guys um so you know 211 has had a good life it'll it the end of life of its development is coming up this year um but you know 212 got started a little bit later because because of that commitment to Java 6 that we still have and then very happy of course to to have um released the 2120 final um this quarter um and there will be another umt one release as always shortly after the zero released to fix a couple of bugs um that will happen this month if all goes well and um the last 211 release 2119 um is is also uh scheduled for this year um that's not to say we won't ever do another 211 release um it's just to say that we haven't planned to do another one um 2017 will be focusing on 213 um and you know obviously 21x minor releases so let me give you a quick overview of of um you know the the headline features and some of maybe the the kind of cooler sneaky ones that that that got in there um that you might not be aware of um of Scala 212 after that I I'll dig a little bit into how those are implemented in terms of java 8 features and um of course conclude with a quick um kind of heads up of what's coming in 213 but as I said you know that that's part of of what the scolar center is for and what the process is for to determine what exactly 2113 will be so I'm I'm going to give you our intentions and our commitments um but I I'm not speaking for you know what exactly um the scol center will approve and and what we as a community will decide to do so the shiny of course is is Java 8 there's a lot of really exciting stuff on the Java a platform um that that we're very that we have been for years eager to to make use of and these these two features go hand in hand um so the being finally being able to compile a trait to J just one interface instead of an interface with a class that has all the implementations for those methods is is a huge Boon for you know from simplifying to compiler internals to Binary compatibility um sadly it's kind of proven to be taxing for the VM so we had to do a lot of work to make sure that we don't kill startup performance for example and um I I'll talk a little bit about that um but I I I'm not going to go too technical in this talk um so but the first thing is that a trait now compiles to an interface with default meth methods and that enables the next point which is a function which is just a trait in Scala um with one abstract method the apply method can now also compile to a functional interface on Java and we basically use the same Machinery as Java 8 does to spin up those Anonymous sub classes that we used to have to generate at compile time so Sam stands for single abstract method types and Indie stands for invoke Dynamic but you know we like to talk about Samy and Indie um and and you know the other thing not to be forgotten after all the hype around Java 8 is that we have a new backend and a new Optimizer um that was a long time coming that a lot of the work started at epfl Miguel Garcia did a lot of the the early work on this and um both on the back end and the optimizer um very glad to now standardize on an ASM based so ASM is a library used around the whole Java ecosystem um to generate bite code um so it's very nice to be able to simplify um the pipeline at the back end of the compiler and and also um make it faster in a mid bite code and um the optimizer which um Lucas on our team took over from Miguel and and really turn into a production ready Optimizer that I recommend you give a shot and try it out um of course there's there's binary compatibility consequences for doing so but it is an Optimizer that that I think we feel comfortable now um recommending use in production and and so we did a lot of work around you know testing and adding new optimizations and so on Lucas has given a couple of really good talks about this recently at scholar world so I'm just going to refer you to his talks he can speak to that with much more Authority than I can um scal do um one of those things that we we as as a as a you know compiler and Library hacker team never quite find a time to work on and so we're very grateful uh for Felix Moulder and and yakob peski to to have contributed these really cool features for scol do to to make it look nice and you know this decade instead of the last uh and and to for example allow documenting your your Java sources with Scala do now so I mean that's that's really cool um um for the rapple um we're now using the same presentation compiler as the IDE and as anim and those other projects that are based on the presentation compiler that's part of the actual scolar compiler and you may have noticed that um tab completion got better at the at the 218 I think it was the first time we introduce it but I wanted to mention it here um and this other sneaky feature that's been there for a while but that we can't really enable because it might screw up emac users and stuff like that I don't know about VI but um so you can you can have color highlighting colored highlighting in in the reppel uh and we're thinking about how to kind of enable this in a userfriendly backwards compatible way but you know um we'll get there for the library I mean this was 212 was a compiler release so we've consciously try to minimize the impact on the library to facilitate cross building and and to really be able to focus on on one important aspect of of developing Scala um but there were some improvements some important improvements to the library um I would say that the three main ones are that either is now right biased and cats for example is intending to standardize on that instead of xor there's a lot of goodness in in this repository in the second bullet the Java eight8 compatibility layer dealing with streams cable um futures or whatever they call it in Java um and you know a lot of other stuff that 211 needs to to um compile to java8 style lambdas and that are still a nice convenience to have on 212 another thing I just wanted to mention if you were still counting on filter to be used in the four comprehension desugaring well don't it's now standardized on WID filter it's just one of those things that has been kind of niggling us forever and and we wanted to you know deprecate and get rid of it and and I'm glad we did um as I started out by saying you know the contributors um I mean ultimately you know it's getting close to half of the of the work um we want you to have the best experience possible and um we're very glad to have typ level um to to channel those efforts in in a different organization and to work with and and to kind of keep us on our toes to to make sure that we can we can meet those expectations and the SBT build is something that you can find on jira that has been talked about for years and years and we've always wanted to do but it's one of those things that just think about you know bumping your SBT version The Dread that that fills you with um just it's just one of those psychological things where you don't feel like doing the work um because it's just you don't know when you're going to end and I spent a lot of time reworking our ant XML build actually in 211 just as a little um this is not recorded right um um to kind of set the scene for the SBT rewrite so basically we had like an end build that was structured like an SBT build so we could really I mean we I guess you can call us a little paranoid we don't want to ship a broken scholar release that suddenly is lack is like missing some class files here and there or is doing like the O gii manifest all differently and you know there's a lot of you know paper cuts that that will that will kill you before you get to the the boss level um so but really really happy to have the SBT build and you know Stefan did a lot of the work our newest team member um and and we're reaping the benefits and and we all are I think um and and we're doing our best as Engineers to be good communicators as well um and um you know standardizing on platforms like GitHub definitely helps um and having scolar Center in type level and multiple channels to talk to the community is is is a great is a great Boon um to to all this and of course very happy to see new faces on the pquest queue all the time um so I also you know definitely want to thank the the doy team for a very fruitful collaboration I think especially for the first bullet here to trade on Lambda en codings it went both ways um we learned a lot from them um being able to experiment without with less baggage or maybe no baggage um and and our bag has definitely taught them a thing or two about what what does what what actual production B code should look like so um there's a lot of other things that that that um are there that are essentially aligning us with do for the longer term future of the language um I won't go into much details but I'm happy to take questions later if you're curious um and you know of course as as now daily users of SBT the the the 01313 release despite its it's ominous number is is is a real nice upgrade so I recommend you check it out um actually um speaking of questions looking at the time I do probably have time to take live questions which I usually prefer is there anything that you'd like to um you know interject or ask about at this time no well then I'm just going to get a little bit more Technical and see what what happens next um just a little bit more um so as I said we're super excited to have Java eight underneath us now and I do want to start this little topic by saying that I don't think functional programming is just you know throwing a lambdas into an existing language um this is great for us because we now have all the tools in the platform we have the mindset and we have a lot of java libraries out there that are think starting to think more like Scola programmers and and so it's great to have for Scola as a language without a doubt um and and I always think of java 8 as as a bit of a gateway drug to to Scola um I think once you've tasted the kinds of abstractions that you get there you you'll want more and we have it so um I think the number one thing that I would mention is is isolation is being able to reason about your code um you know through time think about sharing mutable data structures and and what that does for program understanding or being able to distribute your program and and so these are all tools for a means and and the means is to write modern applications that scale out and that that are robust and that will you know that that you can let crash um I'm not going to plug reactive don't worry um but I I do think that there's a lot of good in there and and a lot of that is enabled and is easier to do in Scala and is kind of natural to do in Scala um another kind of Insidious example is having statements in your language which makes everything look like a side effect um if you think about Expressions as resulting in a value it's much more natural to think about computations as data for example or just as computations in their own right um and similarly like you know maybe these look like conveniences case classes and pattern matching but they shape your thinking and they shape the way that you implement your programs and and structured data is all around us and being able to make sure that you covered all your cases is my opinion quite important and quite helpful for the compiler to do that and we don't have the best exhaustivity Checker out there but you know having implemented I think it's pretty good um but it definitely um can be better and we're looking at what people in in the body context they're doing there and even though the collections aren't technically the language I think of it as part of the language and I know that a lot of a lot of people do and and they were designed functional up by you know by Design from the start so I think that makes a big difference although there's a lot of interesting things that we're seeing in Java 8 and that we definitely want to interoperate with and learn from as we as we go into 213 and the collections reite of 213 or I should say refactoring um and the the kind of hyper and friends that were're able to do in Scala um may seem like just the benefit of not having to do code generation or not having to have your IDE do this I I I don't I don't agree um code generation is a maintenance liability and you should use it when when nothing else is available but we have a perfectly good way to infer types and to get rid of that baggage and to be able to refactor and infer you know maybe slightly different types but at least you still know what type checks so it is really about safety and maintainability at the same time without getting in your way and I I I did say that um and and I mean it um I it's it's it's part of the a feature of the of the type system in Scala and a way of thinking that the type Checker has your back and and um when it does compile you have a good shot at being right and I'm not saying you're you're you're you know you're guaranteed to be right we're not a proof assistant and and we will never be um we you know a type system is a lightweight way to do verification of your programs and and we certainly don't want to make it into something that becomes unbearable um but having this variance um on the definition site really is something that I think is important to drive home here because just look at what you have to do in Java and that is a perfectly understandable decision on their part they couldn't do it any other way because of the backwards compatibility constraints that they had when introduced generics um and so I'm not bashing Java it's it's just the their hand was forced here and they know that um but by having this power at the definition site you don't enforce this pain or you don't inflict this pain on your user every time they use your abstraction and this may seem like an you know variance you don't have to understand how it works for it to help you in your daily programming and I think that's kind of what we try to do with Scala and we don't always succeed and sometimes the type system or a compiler does get in your way or in your face um with ugly error messages or slow compile times but ultimately that's that's our goal we we want you not to have to worry about bugs that we can worry about um at that level okay so onto the more technical stuff um like I already said the trait now compiles um to an interface um that's great for binary compatibility it's greatly simplified the back end in the compiler not to have to have two of everything when there was only one in the in the kind of the conceptual domain of Scala um and it also means that we can now compile function n uh from 1 to 22 um it's still 22 uh to to a S Type um yeah and so this sounds like a magic kind of solution to to um fit traits into the Java ecosystem sadly it's not um we will need something like class dynamic or something to really really get rid of all the niggles or something like tasty or or I don't know what it will be um but if you have a field in a trait subclasses of that trait are still going to be recompiled when you change something about that field when you remove it when you add another one um when a trade extends a class an interface in Java can't extend a class so that's a that's a a liability or an obligation for the subclasses downstream to add that class it's not something that is rendered to the interface on on the Java 8 platform when you have a super call maybe most surprisingly that actually gives rise to an abstract method that is a super accessor because we don't know what the super call is going to be until all the traits are mixed in and we know what the linearization is going to be in in the first subass of that trade so these are all kind of slight mismatches and it it fits almost just right but don't be fooled trades still come with a penalty when it comes to evolving your your apis it's substantially less and at least you can do some Evolution like you can add a concrete method you can add um a final constant Val because it doesn't give rise to a field it's just a constant that will be inlined everywhere um but you know it doesn't come for free be careful when you change your traits it's not all of a sudden solved question um would you say that extend having a trait extended class is good practice bad practice I mean what's your recommendation it's hard to say in general but I would definitely say think twice before why why are you doing that um do you do you really need it um it is a shackle and so it is a good yeah it is good practice to avoid it when you can I would say what cave what possible problem might you hit if you did that well so like I said if if you add a class to a trait Al the sub classes need to be changed if you add a trait uh super class to a trait the subclasses don't necessarily need to be changed assuming that they don't violate any of the other rules um an interface can can receive more Super interfaces in a binary compatible way it can't receive classes at all so um that's an obligation for your subclasses to be to to to be you know accounted for or you know to pay the price for okay um other questions good and so forwarders yes I I meant to mention that too um so actually and we did a lot of experimentation here um so forwarders are basically just little Implement like little method implementations for all the trait methods um mixed into the the final subass once we know like when like what all the order of of method calls should be and what all the super accessor should look like those forwarders basically overwrite all concrete methods defined in traits and we don't necessarily have to do that because most of the time it follows what Java resolution would give you but having it turns out having all these Implement having all these overrides there sped up um jvm performance cold startup performance by a significant factor we uh Lucas wrote a Long blog on that that you can find through the release notes um or or through the P request um but yeah it basically comes down to the class hierarchy analysis um that the that the jid does to figure out where all the method calls are going to go um is just not the data structures are not set up to to really efficiently deal with pretty deep hierarchies especially like as scen and in the scholar collections um so yeah we at the tradeoff of bigger bite code and slightly more brittleness um for for for binary compatibility we decided to to enable them you can actually disable them in your project if you don't care about startup um and and you want the other benefits you you can you can turn it off um it's not needed for correctness but obviously we care a lot about performance um so we we we really went down all the way to the vtune machine Cod level to figure out what's going on and um anyway so we're watching this space and we might we might you know flip the switch in 213 if if the the jvm gets better at this but for now um you know maybe we'll have a reactive VM or something at some point um I thought that was a funnier joke anyway no reactive VM then that's Market tested um um yeah so having you know invoke Dynamic driven Lambda um is really easy to summarize it's basically doing the same thing as Java C does and that's what Scala C has always done when we can let Oracle worry about the VM and the performance and you know compiling all this B code and it's worked out pretty well for us and and we we intend to you know continue profiting from from that um there are there's basically one major gacha and that's um because where you're where where does the the body go when you know it it it it goes to to the The Meta Machinery that spins up those those bodies um well it it's now in a method in the class that encloses the the the literal function that you're writing and so everything that's on the right of the arrow goes into a method at the soonest kind of spot where we can put a method before it got spun off to an anonymous class that was a subass of a function n usually in in in Scola and um so for example synchronization would happen on on the on the monitor of that object that was an instance of that class now it actually is a monitor of the enclosing class and if you're already holding that lock and you come back from a different thread you deadlock and so we're getting reports that people are surprised in Scola Che for example when you tend to Define lambdas in objects and you you spin up a future or something like that and then you you await that future um it used to kind of accidentally work because you weren't locking on yourself when you when you're when you're in the when you're um when you're calling that fun function now you are and um that also means that you will capture the outer pointer if you reference um if you capture stuff from the class it'll indirect through the dis pointer instead of capturing just that field so there is a potential for memory leaks which we've worked to to minimize excuse me um and we'll continue to improve Lambda lift to to capture really the minimum amount but it is a tough tradeoff between how many arguments do you want to pass into into that method and you know how much he do you want to hang on to um so that's one of the things where where you need to be careful um and and things like spores spores um can help although it the project is is um you know needs some more work I would say um but yeah this is something that that gets very technical so I don't want to linger on that too much but I do want to you know make sure you got that caveat um I think I've said most of that um wild cards is all I'm going to say um but to give you an example of of of stuff that now works um you know you can have you can actually have an overload that takes a function and that takes a samp type from java and you can call it with this beautiful CeX of underscore different looking underscore and another underscore um and you know it'll pick the function one um and that's because whenever you have an expression of a function type um you can pass it to a function or a S type because there a con there is a conversion from a function literal to meet its expected type of of any S Type not just a function and type that Scala knows about as a built-in function the other way around when you have an arbitrary expression of a comparator type you canot pass it to a function two because it's not a subtype and there is no conversion that goes the other way this is kind of the intuitive explanation we had to fuss it a little bit um to to really just slot it in back in a backwards compatible way um but so um this is kind of the best we can do in the space that we are um under the constraints that we have but so be aware that when you have an overload like this the function version will be called but because we're doing type inference for higher for overloaded higher order methods the same way that D is doing it it actually figures out the types um for the three examples and and that's that's kind of that was another feature that we did to make sure that the migration is is smooth um but there is a change there um so I have a quick example for you just you know to prove that you can um if you wanted to work with streams um this is just in the repple and it all works until you hit wild cards and I I spent a lot of time thinking about how to kind of plug this in and we have some ideas Jason implemented a plugin to kind of retroactively bestow V definition side variance on a lot of the Java built-in types because what you're seeing here is a breakdown of type inference because we don't understand definition side variance and what it means for the direction that type inference needs to go in when it's following the subtype latus um so it gives you suboptimal error messages um and it it doesn't happen in a lot of the cases it's it it has to do with you know really like the perfect storm of overloading and and handp specialized Java methods and and wild cards and um there are theoretical things we could do about it and there are practical things that we are doing about it um it's just not in the mainline compiler and so the solution here is is to actually Supply the type argument that that we can't infer in the Java can uh um yeah so that's something to be aware of it's something that you can work around um and if you do a lot of java interrup um it might be useful to investigate that Plugin or or to have some wrappers where where for the for those API kind of pain points that that that don't match very well with our way of doing type inference so I mean to conclude briefly about 213 um we've been thinking about this for a long time uh you know while while the compiler was compiling for example and um I just want to give you a sense of what we're thinking and what we want to put our our team's resources towards and our time towards um and all of our energy um and and so it is going to be a library release that's that's our Tik Tock scheme of focusing on one One release we work really hard on the compiler and then we turn to the library and I think everybody will agree the this scy Library can use some some more work and some more love and uh we've talked about that in the past I dread to click on this link it's been a while uh and and we're shooting for a slightly shorter cycle this time because we won't have this parallel tracks going on between like we did for 2 11 and 22 um so most of all we want we want to simplify the collections and and they're they're kind of two areas where we want to do that there's a lot of common gachas like seek being mutable by default and things like that that are just accidents of History um and that we've never fixed even though we wanted to because of backwards compatibility but with 213 we're going to we're going to make some of those breaking changes and we'll be very clear obviously about what they are we also want to want to look into refactoring and the Mantra there is that the community build which I haven't counted but is in the single digits of millions of lines of code um our goal is that we should be able to to to Port that to the new design in in a week doing it ourselves if we can do that we feel like we're at a point where this is not too breaking and it has to carry its own weight obviously we're not just going to refactor to feel better about our design we're refactoring to make you more productive with it um and what I'm what I'll say now is that the inheritance hierarchy will change um parallel collections will be moved to the side there won't be like all those gen traits um we're thinking about a better split between mutable immutable um having um modules for views and and really just kind of of opening up the the API a little bit making it less heavy at at the top so that you get less overlap and so I think I'm I'm confident we'll agree on our goals we just have to figure out how to do it without breaking everybody's code too horribly but we also don't want to fall into the into the Trap of never changing anything we've always acted on deprecation not as quickly as we always would have liked but we've always removed deprecated stuff and we'll continue to do that and 213 will be one of those releases where there's going to be some work um and it's not just going to be build like for example between 211 212 210 and 211 was always the goal that you could just basically use almost the same Source B source code um modulo macros and all that stuff um and and so 213 will try to make the impact minimal if you're just using the collections but if you have been extending them or using some more advanced stuff like um um breakout it it it might it might not work yes oh you will you uh per a side col of the old col and yeah so that's that's one of the so the question is will there be a parallel universe of the old and the new and I mean like like you know how we how we broke out like skx andl yeah like old junky collection right yeah for those who like that that yeah um so that's definitely one of the things that we've been thinking about uh since the collections are so tightly coupled to the language and a lot of you know those those types appear in the spec it's big effort to have like a shared super a set of super classes and between two different implementations of them well yeah but other people will you know so I don't know I mean like I'll be happy to talk about this more offline and in the community and and the process is just starting and and you know we'll we'll start all the all this dialogue um but um yeah I I like that that way of thinking and and definitely been come up before in in our discussions we ultimately have to see what we can make happen honestly um and and the more people we get to join in this effort the more ambitious we can make it um so definitely um stay tuned for those announcements and and and you're very welcome to join in that effort so you know we don't want to just modularize the the collections there's a lot of stuff in there that I remember from when I was an intern at epfl uh that just got in there because no one believed Scala would would be this popular um and so it's still there you know and that's very often this those simple explanations are the right ones and that's for a lot of the Cru that's in there it's there because it got in there originally and never no one ever removed it and for some of these modules we we we see a bright future for them others they're kind of being moved to the side so they can gently migrate to the farm and we will just not mention them again um there is some stuff in there that I rather not talk about in the future um but we don't you never know how people get attached to to weird abstractions that are in there or or methods that are crucial for some code base um is one of the thing one of the rules is that you know whenever something is syntactically valid someone is doing it and um we don't want to be completely stifled by that and you know sometimes you have to break stuff to to you know to make breakfast but it's you know we try to be be reasoned about it anyway so my my my interest is still to simplify the language and in this case it means aligning with with what what's being researched in the D incubator um I'm I'm almost there um and so trade parameters are are the thing that I would like to see most in in 213 and that I would like to work on and we've done a lot of work behind the scenes in 212 to clean up the way that fields are handled internally uh and so we want to reap those benefits of working on on um object initialization better synchronization for Lazy fils H and trade parameters and so that we can deprecate early initializers I I hope no one will be too sad about that um and you know but with the scholar Center developing scholar fic this is a great time to start being more aggressive in in what we can get rid of and procedure syntax is one of those things that I I can honestly say I never wanted um and I'm finally going to have the pleasure of getting rid of it and similarly you know implicits without signatur so my wish list basically is everything that's happening uh in anybody's crazy experiment um and I don't mean to say Do's crazy but it's also an experiment um you know I'd love to see come back to to Scala Scala to Mainline Scola and so I'm I'm really I really like the work that they're doing on friendly or error messages for example and uh we'd love to see that come back come back to the scol 2 uh line um configurable reporting is something that I did some work on internally to clean up the way that we handle reporting uh warnings and errors so for example you could say anything that's been deprecated for two releases make that an error any recent deprecations I'm okay with that that's a warning something like that or you know don't let me use anything from that package that's deprecated um so being able to configure those things will be super useful and it's a lot of those things are are just really nice to have but not things that I can you know really motivate spending spending our team's time on the rapple has gotten a lot of attention a lot of love Andrew Mar has done a lot of work um and a lot of other people have contributed to making it a nicer EXP expi and it's it's one of the key things that set Scola apart and with Java 9 um they will have a reppel too so we need to be better quite simply um and and I mean I think we are um but we need to continue improving and so syntax highlighting like true syntax highlighting um um wrapping that is that is more more amable to embeddability so all those big data worksheets are are are not all of them but often they are built on the repple and making that easier is is is definitely one of the goals I would have for my wish list of 213 features another little um evil corporate strategy here is that we want to have your scolar compiler phone home with the version that you're using um but in general I think it would be a great experience to be able to download one jar ever for the Scola platform and get SBT get play um get get you know the scolar rapple prepackaged with different different modules I'm just throwing it out there I don't think we'll work on this but I think there's a lot of benefit to having the SBT launcher being able to launch the Scola console kind kind of like what ammonite is doing with being uh you know able to to ship with prepackaged dependencies and just have everything sit in your IV cache instead of having to download tars over and over again Scala fix I mentioned already is is a great project under the Scola Center umbrella that we'd love to use for upgrades to 13 and probably will work on Scala bide is kind of sitting there waiting for someone to show it some love um makes me sad that we don't have more time to work on it um but ultimately it wants to move all the lint or linting out of the scolar compiler and make it extensible it's kind of like wart remover but with a plug-in infrastructure um so that's that's out there in the open um and by open I mean not for you to see but for you to to change and for you to to have opinions about and Implement those opinions so to conclude um again thank you very much for all the contributions thank you to the organizations that are that are showing how mature our our our community is um thank you to scal Center and the inspiration from D thank you all for attending happy to take questions when I have time Mr pretty you mention without yeah exp because I knew you were in the room I'm just going to talk in the microphone like this now just don't do it um I mean the problem with implicits without signatures is that type implicit search and type inference are are happen at the same time and when you have to figure out which implicits are in scope while you're inferring the type of an implicit that doesn't have a result type it just kind of gets into this weird circularity where things start depending on the order of definitions because we have kind of ways to break those cycles that say well you know these things have been inferred already I'm here now so let's see what we have and and that's really not the kind of programming that I would encourage anybody to to indulge in um when you have all the all the all the all the types available to you as the implicit search part of type inference none of that sensitivity to orders of definitions or kind of like caching strategies that we have in the compiler that people take advantage of I won't name their names miles but I'm sure you've run into them and and you know thought of them as bugs luckily but you know I hope no one thinks of do as features um yeah so I think that's kind of what we're what we're um thinking about and in general any non-private definition you should really consider having an explicit type on it it's documentation it's really cheap insurance for future versions of Scala doing different kinds of type inference um you won't be bitten by weird binary incompatibility changes when typing for do something else um it's just it's just a good idea yeah miles um yeah I'm I'm been told I'm out out but um I uh I will happily take more questions throughout the day um thank you very much Adrian if you want to tweet about this the hash is Scala is that the Unicode like joint thing or [Applause] next for