 All right. Oops. Cool. Hello, everyone. Can you guys hear me OK in the back? OK. So I have to shout a little bit. So before we begin, just to introduce myself. So my name is Herdi. I'm a senior software engineer at Citadel Tech, a small startup here in Singapore. I'm currently working in Scala, and I do also a little bit of Kotlin. So I'm trying to, you know, keep up with the times. Before, well, I sort of mentioned in the Meetup page, I'm actually migrated here about last year from Perth, Australia, specifically moving here to actually took a role, full-time role in Scala. So that's how much I love working in the language. So, you know, I was previously working in the .NET ecosystem, so Windows, the whole works. So moving to Scala was actually quite a big paradigm shift. So I had to learn a whole bunch of new tools, even had to work in Linux, so believe it or not. So, but, you know, it gives you a bit of perspective. So, you know, not being content just learning Scala, you know, I've also tried to learn other stuff at the moment. I'm a little bit enamored with Lexer and Elm. Seems to be quite in at the moment. You can sort of find me all over the Internet. That's my to-the-handle. Find me also in GitHub. If you want to, you can follow me on Instagram. I post random photos of buildings, sports car and whatnot. Also, just had a website up. Only had one post, though, but I promise I'll put more stuff in there. So, you know, I'm hoping to achieve at least one of two things today. One is to actually get, you know, share with you a little bit of knowledge about Doty. Otherwise, the other one is to, you know, by the end of the presentation, I think you might be tired of the whole orally meme. I don't know. Have you guys seen this before? Not really. So this is kind of like a satire. So if you, you know, there's the publication called Orally, which publishes technical books. So in this sort of similar format, so this is actually sort of like a parody of them. So it's, you know, it was pretty big about three months ago. I'm not sure about now, but it's in the Internet. So anyways, I'll sort of put this up because this is going to be a long and dry presentation. So I'm hoping that if I, you know, put something a little bit different, you're not going to fall asleep by the end of the presentation. So I'm going to put a lot of different ones as a segue to the next category. So speaking of this, I want to share you a little bit about why I'm actually here tonight actually speaking about Doty. It's not because I work in, you know, Doty or even in compiler technologies or not, I don't even consider myself as a Scala language expert, although, you know, I think I'm all right with it. The main reason is because I attended this conference called Scala Matsuri about a couple of months ago. So there's quite a few people coming from, that came from Singapore. I sort of had the idea to do sort of like a sharing session a week before I went there. I thought it might be good to actually bring back some knowledge from the presentation. It's also a good excuse to actually come and visit Japan. You know, I'm quite, you know, excited about the Japanese culture. So I had a lot of yakitoris while I was over there. So, and I think this is the second or third year running. It's always been held sometime around February. This year's talk was actually pretty good. So they had a bunch of guys from EPFL coming over, guys from LightBent, and also a bunch of other guys from Europe which, you know, work on really exotic stuff. They talked a lot about, well, some of the talks are, you know, covering Doty, Pavel, I think he talked about the free monads, you know, went completely over my head. You know, I didn't understand a single thing, but, you know, I think it was pretty good. So, and there was a demo of Scala Native. You know, they actually, I can't remember his name, but he quoted a snake game live throughout the presentation. There was, you know, everybody was actually clapping at the end because he actually made it work. There was one about Scala.js, and there's a bunch of other stuff. So there's a good mix of, I guess, different talks ranging from the beginner's talk up to the expert one. So, you know, if you have the time and resources, you know, come to the next year's one. So hopefully, you know, Singapore will sort of represent a bit more. In any case, they do have a YouTube channel. I don't know if you can actually see, but in my presentation, you know, I've put all the links on the resources there. So after the presentation, I'm going to share you the link on my, sorry, I'm going to share you the link to my presentation. So if you decide that you want to, you know, probably decide it's there. Whoops. So why I chose Dode in particular, you know, it's because of a tweet, really. This is kind of like a personal best to me. You know, I never had, like, 94 favorites before, and I was pretty excited, you know, in the first 48 hours. Apparently, people are quite excited about this. So I wasn't expecting that, you know, people are, you know, actually liking this, you know, because seeing that Dode is kind of like still experimental at this stage. So, but, you know, thought it might be a good idea to do today. So talking about what we're going to discuss today, well, actually I'm going to be doing a lot of talking, probably not much discussing. So I'm going to cover stuff about DOT and Dode, the developer tooling, the current status, and some of the stuff that they've actually dropped, already implemented, and something that they're actually thinking about putting in. There's going to be a couple of small slides at the end about, you know, releasing a timeline because basically everyone wants to know when can I use it. And the last one is just probably just a small sort of call to arms, you know, just so everyone can, you know, get excited and start contributing to DOTI. Unfortunately, this is going to be probably about 80%, 90% talk. I have a small bit of demo. I'm hoping it's going to run okay because this morning when I tried, it just didn't want to download stuff. So we'll see about that. So to begin with, has anyone heard about DOT here? Or everyone's familiar with DOT? Really? First time? You heard about it? You heard about it. So now there's a reason I put this particular cover here. So in one of the talks by Man, I should say Professor Odeski in Australia, I think late last year or early this year, he was talking about a little bit of the history of Scala. He kind of alluded that Scala was being rushed into production. If you're in a startup, you just want to get the MVP done and just push it out the door. So that's kind of like what happens. So you got the language out and then throughout this past decade, it sort of just evolved organically. But one of the things that he was concerned about is that there's really no, I guess, foundation or formal proof of the language. Basically what Scala is, is what's actually being implemented. So he sort of want to take a little bit of control of that and sort of not I would say fix, but put some strong foundations to Scala. And basically that's what he came up with, which is called DOT. It's basically short of dependent object types. So in short, it's actually a calculus of dependent object types that underlies Scala. So small mathematical proof that actually underlines I guess the Scala language itself. So why is this important? There's a few reasons for that. And as I've mentioned before, the way the Scala language grows organically, sometimes you do find sort of like the edge cases where you sort of think that some of these things that can't be done is actually allowed. So I guess what they can consider loopholes. So by having a calculus, you have sort of a proof that whatever they formulate is going to be correct. I've seen ensuring type soundness, and is it based on a JVM? Do you think it will be still JVM? Yes, yes. How are you going to deal with now? Or are you going to ignore all existing libraries? There's a section exactly on that a little bit later. Don't worry. So also with DOT, it's enabling a sort of a feedback loop for a language design. And the added benefit is that you sort of can make connections between the language features. Don't work on language design. So I don't think I'm qualified to talk about DOT. But I mean if you are interested, there's actually a paper on DOT. But what I'm showing you on the left-hand side, it's actually sort of the common grammar they use as part of developing the language. So if you go to the GitHub repo, you see the issues. Sometimes they do talk in this sort of symbols. So they do have a set of grammar to talk about, say if they find a problem, this is sort of the common syntax that they use. One of the key things that is actually pretty important, Professor Odeski mentioned is that because foundations are formative. So I think this is quite important because for me, Scala sort of occupies quite a unique space in the language landscape. It sort of blends the OOP and functional paradigm. And that's not that many language that sort of has that characteristics. So the key thing is that you could sort of choose an existing foundation, but what you ended up happening is that you're actually just going to come back with a language design that's actually just a variation of the existing foundation. So if you start with ML or Haskell, you ended up with a Haskell-y language. So that's why he sort of insisted on building this sort of unique foundation because Scala, Scala, and he wants to keep it that way. And this is not the first attempt in actually describing dots. So there's actually several attempts in the past. So he started with the V object calculus in 2003, you know, it's a rich type system but gets unwieldy and also had some problems with type boundaries. Followed by a featherweight Scala, you know, with some decided type checking, they, you know, progress a little bit forward, but still not enough. In 2008 comes up Scalina, which introduced kind of like a higher kind of kind of type in Scala. But it's also sort of not enough. So I guess the common theme in all these three sort of designs is that they're all overly complex until they come up with the dependent object type. So this is actually the paper that I guess sort of summarized the design of DOT. It's all Greek to me, so unfortunately I can't really talk too much about it, but the link is there, it's freely downloadable so you can have a read in your spare time. So it's basically a minimal set of calculus that contains street extensions at the moment, so records, type labels, and recursion. They do, however, are considering or actually currently studying some other extensions to actually sort of fill the gap between the current DOT with the current, sorry, the DOT as it is with the current Scala language state. So if you think of DOT as the foundations, I guess it's kind of like analogy for a recipe, then DOT is actually the kitchen where all the magic happens. So DOT is actually the implementation of DOT in Scala. So it's actually a new Scala compiler developed at LAMP, APFL, based on DOT. So if you had a chance to play around with it, it's kind of like similar to Scala, actually it's almost a Scala, well apart from the missing features, it is Scala. However, because they actually started afresh on this one, they were able to take the existing practices, avoid the mistakes with the existing Scala compiler. So the code base is much more smaller and streamlined. So it's about half the size of the current Scala reference compiler and well, they say it's promises to be twice as fast. So at the moment, there's a little bit of speed up, but until everything is complete, I guess it's still just a promise, so we'll see about that. But I'm happy to take any speed ups that I can, really. So this is roughly how the DOT is being architecture. Unfortunately, I couldn't really find any more information on it, but if you see this sort of graph, you can sort of infer that DOT is still have a little bit of dependency on the current Scala compiler. So you have the NSC and the DOTE front-end, which generates the abstract syntax tree, which later gets transformed into a simplified one, then gets emitted by the bytecode emitter. Just want to direct your attention to this little thing. So Tasty is actually something that is going to come up pretty often as DOTE matures. What it is, it's actually sort of like a persisted AST. So it's coming up from sort of like a related project called Scala Meta, which is going to replace the whole macros and things like that. So what it does, it's actually a serialized format to store AST at compile time after type checking to be able to be loaded at runtime. So I think the goal is to be able to use that information as a language interchange format, not only for use by Scala, but also by all other languages that can implement it. So it aims to be compact, lazy, extensible, and precise. All this sort of, I guess, information. There's actually a couple of links I put down in here. It talks in a bit of details about what kind of format they use, what information they stores over here. In Tasty, I'm not going to talk too much about it because, you know, I only skim the service, but all the information is there. So Scala Meta, apart from actually helping to define Tasty, is actually a metaprogramming toolkit that's taking place front and center in the sort of new dotty ecosystem. So it's going to replace the Scala macros, and it's going to be used by a lot of the other Scala tools to help migrating from the existing Scala versions to the new dotty platform or ecosystem. So it's chosen because it's actually much more simpler in its implementation compared to the existing Scala macros. Why they decided to actually build something new is because the current macros has a lot of ties into the compiler implementation. So they decided to make something that's independent. I'm not sure the point about sandboxing, to be honest, I haven't quite researched it that much, but they do have some restrictions, so they only allow black box macros. So this is the term that I've actually first heard about in basically the presentation about white box and black box macros. There's a last link on the slide that talks a little bit about what they are, but basically if you think about a black box, you don't need to care about the implementation details, but if you give it an input of A, you get an output of B. Whereas a white box macros, you might get an input of A. What comes out, you might be a specialized type of B. So by actually enforcing the black box macros, you get a little bit more confidence about, I guess, your types. So this is kind of like the short syntax of how the macros look like. I think I can scroll this. So you get the inline to inline stuff, and then you get sort of the meta context there. So when I mentioned about ScalaMeta being in the center of things, so this is how it is at the moment. So they're going to bring ScalaMeta support back to Scala2, so I think they're working on sort of like a back porting, backwards compatibility, and also it's going to be useful because this is some of the things that help you migrate your code over to Doty. So it's going to be used in ScalaC Doty. Apparently it's also being used by the IntelliJ Scala plugin. I'm not too sure about that. But for the meta programming itself, you can help you write macro annotations, macros, also being used in ScalaFix. So I'm going to talk just a little bit on that a little bit later. Also ScalaFormat, and you can basically use it to supplement your own library. Now this is one of the things that I found quite interesting. So Doty Linker is kind of like the pro guard of Scala. So it's a whole program optimizer. Now I'm kind of excited about this because it actually helps you to make your Scala application smaller and faster. Again, it leverages testy, tasty. It does sort of a call graph analysis, so it looks at where your program starts, looks at where the call is being originated, and just removes stuff that's not needed. But the cool thing about this is that some of the stuff that comes into the Linker actually has existed currently. So the things like the smart specialization, inferring precise types, and eliminating virtual dispatch actually already exist in various shapes or various libraries in Scala. The guy that's working on the Linker, the main guy, he actually developed Scala Blitz. Also the first time I heard about it in this talk. So it's actually what you call a high-performance Scala collection library. So if you have the time, feel free to Google it. It's apparently pretty fast. So the main problem that we have at the moment with the Scala collections is that compared to Java, where Java actually better yet, I will show you the link. What's the point inferring more precise types compared to inferring actually more generic types? If you develop in library, you actually want the more generic type to be inferred. Yes, but that's at development time. At compile time, you want to turn that into a specific type. You're compiling new libraries, right? Pardon? You're compiling new libraries. Yes. And you're presenting interface like public API for library. And at this point you want generic types, not precise types. Yes. What's the point then? It doesn't look like benefiting from more precise type compared to inferring the most generic type. It avoids the boxing and unboxing and also eliminates the virtual dispatch. So if you have a generic type, when you actually call that method, it'll do a virtual dispatch or is it dynamic? Dynamic dispatch to the actually precise implementation of that. This Doty linker. Actually, I should talk about the current implementation which is the specialized annotation. So what happens is that if you have a generic method, say a dev get of a type T. So if you put a specialized annotation, now this is just a layman explanation. I haven't used this library. But my understanding is that at compile time, it looked at all possible usages of that particular subtypes. And then creates some sort of method overloads that allows, well, at runtime, when you actually call that with that specific subtype, goes directly to that implementation. So it avoids sort of all the round trips because it's a precise type. You don't know. Inherent from some type. The types that you pass into your library will actually have different virtual tables. Yeah. So the linker is a separate step after compilation. So you start with a soft code, compile a soft code possibly separately. And after you compile it, you then have a separate step before you run it to take all the libraries you're using already compiled, and then you link them together and optimize it using all the libraries. So a library will have like, like many information before linking. So when you compile a library, it will preserve information clearly and only when you compile the entire applications, and it will be optimized ready. Yep. It's like any time optimization in C++. You compile it first, and then you link it together and get more optimizations based on the whole world you have. So yeah, the surface of your program will not change, but after it compiles it, I guess in first what exactly. So I'm just going to quickly switch to this presentation. So it talks about why he does what he does. So by the way, this guy is, you know, he does a lot of work and he did a lot of presentation on this particular topic. So if you have the time, go to his website and see all this presentation. Oh, sorry. Oh, yes. Okay. All right. Okay, let's see. So this is the problem that I was talking about in Scala because there's actually a lot of, I mean, Scala gives you a lot of like good tools for dealing with collection and stuff, but it doesn't come for free. So one of the problems is that, you know, compared to Java, the performance is really poor. In this case, you have almost 20 times worse. So if you see, you know, in the Java, it's actually pretty straightforward. You know, it does what it, well, you told it to do. But in Scala, it's actually, a lot more things are actually happening underneath. So there's, sorry. I'm just going to skip through, but the video is there. He has his slides. So anyway, so it's a lot of this stuff that the JVM doesn't, sorry, the Java doesn't support, but the support in Scala. So basically what happens is that, you know, your generic type gets overloaded with its more precise types. But the problem is, you know, it's sort of the more types you have, the more expensive it gets. Because in here, you have sort of, you know, non-primitive types and a reference type, which makes it 10. But if you have sort of two type parameters, then the cost... What cost? Oh, when you actually sort of infer the more precise type. So at... The compilation. Yep. So 10 to the power of 10. Is that how you say it? So I'm just going to skip through to the last bit after you use Specialize. So through this sort of approach, you sort of brought down the collections performance back to what Java can manage. But of course, again, it doesn't, it's not without its actual cost. So, you know, your compilation times is going to be a little bit longer. Yep, so some of these things are actually now being built into Doty. Let me show you how do I get there. Oops. It's... Oh, let's go. Endlessness. Sorry? Endlessness. Oh, that's all right. I actually tried it on my phone, but I think this is better. I don't want to, you know, try too much. But this is some of the things that are actually going to come into the Doty linker. And the good thing about it is that some of the stuff that's actually not tied into Doty specifically is going to get backported into Scala. So if you haven't heard about Scala 2.13, it's actually going to have some sort of work on the collections library, which I hope will include some of these improvements. Oops. Let's see. Yep, that's it. So that's about the Doty ecosystem. The Doty compiler is one thing, but without a good development tools, you're probably not going to be as productive as a developer. So some of the stuff exists. I mean, you can sort of start creating your app in Doty right now if you want, although it's still very early stages. Still fine. A few things are broken. If you just sort of want to go and give a quick test run, there's this website called Scasti. Have you guys heard about it? It's kind of like a paste bin for Scala. Actually, let me just go to Scasti. There's actually two links here. The one at the topscasti.org is actually an older version. If you want to give it a go, go to scasti.scala.org. The only requirements is that you have to sign up with your GitHub account. Well, it's in beta. I'll just give you a quick look about in case thing. So it's kind of like a virtual repl. Well, not a repl exactly, but you can paste in your code and remote server will actually compile the code for you. The good thing about it is you're keen to have a play around with Doty. Doty is available as a target. And if you want to put Doty inside your Scala application, they do provide sort of like the minimal configuration. So just copy and paste it into your own file and then you can get started with it. So you can... Oh, here we go. Just click Run. It's connected to the remote server and then it's just going to compile. Unfortunately, it's not kind of like a repl. It's just give you the output of your program. But if you just want to take Doty for a spin, I don't want to have to download all these dependencies. This is pretty okay. Oops, running mean. Okay. It is a little bit slow because, you know, it's someone else's server. So the other way to actually get started with Doty, actually a couple ways. IntelliJ actually has a Doty plugin. So Doty is actually available as an SDK. So when you're actually creating a new Scala project, you can just import SBT. Oh, sorry, not import, sorry. Just create a new SBT project. Scala... I'll meet up with Doty from the SBT version. Oops, what's going on? Actually, sorry, wrong. Pick the... Switch it to Doty. Now they actually link to the remote server. So at the moment, Doty runs on nightly builds. You know, it's up to you, probably just going to the latest nightly is normally okay, unless you find something is broken. So I did download at the latest nightly earlier today, but I'm not sure, depending on the time zone, hopefully I'll still get the same one. Okay. Yep, let's see. So this is sort of the default setup that they give you. To be honest, this is a little bit more complicated than necessary, but it does help you to get up and running pretty quickly. The other alternative is to actually use an SBT.Doty plug-in. So it's actually just released by EPFL. So you can actually find it in... Oops, wrong one. So let's go... github.com. EPFL. Sorry, call that snub. So this is the older one. Here we go. SBT-Doty, okay. So this is a much simpler way of actually getting started with Doty. So all you need to do is actually define the dependency on your plugins.SBT. So we'll just do that right now. Actually, they don't have plugins just yet. Let's go. What else do you need? SBT versions minimum 3.13. I'm just going to copy this build of SBT declaration. There is also an option in Doty. So if you wanted to give it a go, but wanting to preserve sort of a Scala2 compatibility, I believe, or actually compiling it in Scala2 mode, you can actually pass this compiler option. There is another compiler option, which I'm just going to talk about a little bit later called Explain. So I'm just going to leave it here. Okay, just refresh that. Okay. Actually, I'm just going to move this... Sorry, just bear with me. Okay. There's nothing in it, anyways. So that's the sort of the minimal thing you need to do to get started working with Doty. So just update your plugins to add the Doty plugin, add the following config to your build SBT, then you can just write normally. This is not the first time I've run it, so you get around all those downloading steps, but just be mindful that the first time you run this, it's going to try to download the whole set of dependencies, which may take a bit of time. So yeah, that's pretty much it. They are working on an IDE support, though. When I was there at the presentation, their demos were actually run in Visual Studio Code. They're actually able to do that because one of the things that they're trying to build support for is the language server protocol. Have you heard about LSP? So this is actually a Microsoft thing, believe it or not. So when Microsoft developed, it's actually a core component of Visual Studio Code. So it's kind of like an enzyme in a way that it's actually a server implementation that's run alongside your IDE, communicates through this protocol to be able to do whatever you need to do. So at the moment, it's pretty limited, though, and it's still very experimental. They don't really have a sort of official plugin just yet when they were showing the demo, they had to connect to the server manually and started it up. But I'm hoping that they're going to come up with it, or it's going to mature soon enough. So there is sort of a big overlap between this and enzyme. So I guess with regards to the future, it's probably still uncertain at the moment, but it's promising nonetheless. But yes, you don't have to use VS Code or Adam. If you want, you can still stick with Intel J. So among the tools, I'm kind of excited about the REPL. Finally, there's quite a few worthy improvements there. One of the things that I'm actually quite excited about is the error messages. Have any of you played with Elm before? It's basically a Haskell-ly language for JavaScript. One of the things that basically Elm Guys is sort of excited about is the way that it helps the new developers get up to speed with the language. I'm going to show you what I mean by that. So anyways, we're in the SBT shell. You could go to the REPL by typing console. Oops. Okay, let's start. So I think before I'm alluded to this thing called explainer, I'm going to come back to it pretty soon. So there is an option in Doty to pass in against the compiler. So let me just think of that example. So if you try to do a try block without catch, it's going to give you a bit of a warning. Now, this is kind of cool because finally you can have colors. You can sort of see things a little bit better, especially where the errors are coming from. It does show you the line numbers, so you don't have to sort of troll through all those stack traces. And it does mention about having the explain compiler tag. So let me just exit. Actually, I have to reload. Okay. So it comes back with a more detailed explanation about what you actually... Well, I suppose not bit wrong, but what could actually be improved. But this is actually not magic. So there is actually an open issue in the Doty GitHub site where you can actually see what kind of error messages are still waiting for an implementation and explanation. So if you want, you could actually help out, go look at an issue which I'll show you later and just sort of provide some sort of helpful error message and basically some mapping against an error type. So this is kind of like the thing that is pretty useful for beginners, especially in Scala. So I'll leave the explain tag on. There's also a few other... Oops, not this one. A few other improvements. So say, for example, if you have mistyped a member, so let's say... Actually, let's go coffee price. So I think that's it. If you go... Well, let's see. Actually, just coffee. Say $10, very expensive coffee. Oh, actually, should have done it. Okay. So let's see if I go C dot. So it's kind of a bit smart about its suggestion. So it does highlight what is sort of not compiling and gives you a little bit of did you mean this. And the other thing as well is a type div. Okay. Okay, so let's just go... Everyone starts dancing? No, we have to do it manually. Oh, it's all right. So the other thing as well is type div. So as you can see, it sort of highlights where things get mismatched. So it's a little bit more friendlier than your current Scala compiler. The other sort of tools that's available that is going to get, I guess, all going to become quite important is the DotyDoc. So it's new document generator for the new Scala. Now, it's kind of cool, I think, because it's sort of inspired a lot by Jekyll. If you've used GitHub Pages, then you kind of know what Jekyll is. So it's kind of like static website generators. You just give it like markdown files, and it's actually going to build you a website. And if you see the current Doty website, it's actually all made by DotyDoc. So not only you can actually... Well, actually you can put markdown in your doc comments and then actually render it. You can put ad hoc MD files, and it's actually just going to render as a page. You can put custom templates, custom CSS. So there's no excuse for you not to do documentation. It started as a Google Summer of Code project last year, and it's also another part of the project this year. So I'm hoping that we're going to have more improvements on it. And the other thing that I want to mention is ScalaFix. So this is kind of like a good tool. If you're wanting to migrate, say, from one version of Scala to the next, because of the information the test is recorded, this tool can sort of automatically revise your code for you. Now I haven't seen it in practice, but they do provide like an SBT plugin or a command line tool. So if you say, for example... I'm going to go give you an example of stuff that's being deprecated. So if you run this tool, it automatically revives the code for you. Not sure if that's a good thing or a bad thing, but, you know, we'll see. So it's not only for DotyDoc. So it's going to be applicable to future Scala versions as well. So from 230 and onwards. Which sort of brings me to the next point. Okay, let me just check the time. Okay, I think, no? Oh, cool. All right. So moving to DotyDoc, there are going to be some stuff that's going to get deprecated. I've mentioned before, macros in its current form is going to be deprecated. The replacement is going to be ScalaMeta, because they're going to actually backport some of the features back into Scala2. So this is kind of like the quick example on how you could actually write a macro in ScalaMeta. They actually have a website dedicated to this metaprogramming tutorial. It's pretty easy to follow. And it's actually quite straightforward. So it's basically this example is kind of like a main annotation macro that sort of expands into the, I guess, into a main method body that accepts an array of string. So it's kind of like the console application you normally find when trying to deal with, say, Java or Scala tutorial. They use this special quasi-quotes, kind of like an interpolator. So once you get the information in this, you get a few stuff like the name of the method. Actually, I can't remember, and the main body. But yeah, so it's pretty straightforward. If you have time, feel free to have a look at it. This is kind of like a minor thing, but it's going to throw a compiler error. I'm not sure how many of you still does the procedural syntax. So based on what they mean by that is when you actually declare a method and followed immediately by a curly brace. So now they just require you to actually annotate it with a unit signature. So pretty easy fix. Now this is kind of probably big in a way, or not really. I mean, I put four sum in here. It's kind of like significant because this is kind of like the way people built existential types in Scala. So the existential types and hierarchical types, I think they're going to have a different form in DoDi. I'm not too sure exactly how it will be. I was still looking for more information about that. But for this kind of syntax, basically to move to DoDi, just use the wildcard types. So there are a couple of information. So if you're wondering what existential types in, there's a good blog post on it by Cake Solutions. And there are some Reddit comments that talks about what this means with DoDi. And how about the features, actually, that's coming? Actually, this is how I do my work most of the time. So it's really effective, so trial by fire. So one of the things is function-erity-adaption. So I don't know how many of you write methods with more than, I don't know, 22 parameters. Any of you ever did that? Yeah, before deseretization. So it's going to be something that's going to be automatically handled by the compiler later. So it's actually expended to this thing called function XXL. So this is taken straight from the actual source code itself. So I think it just turns it into an array of prams. They did it for the functions, but they still haven't done one for tuple. So I think tuples still have limitations of 22, but they are working on kind of like a heterogeneous list implementation for DoDi. It's in the DoDi website, but they don't really have much more information on that. Now, one of the cool things is intersection and union types. So this is kind of like the new thing in Scala. Well, natively, I mean, you can sort of achieve this with existing libraries. But actually having this natively will be pretty cool. So this is, well, basically, this is not a really new concept. It exists in some other programming language, but it is useful nonetheless. So you can actually, at the moment in Scala 2, you can sort of define intersection types using the width keyword. The problem with that is the way it's actually linearized or actually translated. It's actually linearized the, what do you call it? I'm lost for words now. Mental bank, sorry. But anyways, if you do A with B, it's not going to be equal with B with A. Whereas with this intersection type, A and B and B and A is going to return the same. The other good thing about it is union types as well. So if you want to try to do this in Scala 2, it's just going to resolve to any. Whereas in .t, you can actually get the actual union type. So if you declare something as an in or a string, then if you initialize it with a string, then it's going to compile and the type will still be in or string. And it will be compiled. So if my function returns in or strings and I can use it as an argument for another function that uses A or B without defining specific types of type, type in or union types. Yeah. I've only played with it a little bit. One of the limitations that I've encountered is that you need sort of a common trade to do that. So I'm not sure if they changed it recently. So in this kind of example, define has X. I think in earlier example, I was actually able to do that with just trades and basically defining A and B. So I'm not sure what's changed. Yeah. Again, this is new. I mean, they've put in .t, but I think the finer details are still in flux. So feel free to experiment with it. And actually this union type will actually sort of going to be important, especially like the points you mentioned earlier about noble things in Scala. So the other thing, I'm not sure how many of you use trade parameters, but there have been a couple of instances where I wish I could have actually just passed something to a trade. So this sort of avoids the, I guess, the lazy initialization of a trade parameter. So in the first example, if you try to access the value of X within the trade, it's just going to return now, but with this new trade parameters, you can actually just pass whatever. So it's kind of like a class that still retains its sort of mix-in properties. So and also, if you have a class that comprises of a lot of mix-ins, then you probably need to pass a lot less parameters. Some of the stuff that's coming, faster compilation. So they are actually moving to a different strategy now called phase fusion. So I do have some information. Oh, actually, Felix is one of the guys that works on DOTI. He made this pretty cool slide. So oops, why not? Okay, so it's actually splitting the compiler phases into sort of the micro and macro level. And through sort of this implementation, they can actually sort of make things run in a little bit more parallel. Oops, not this one. There's another one from Dark Demias or Dimitri Petrosch. Actually, I can't remember his last name, which gives you a little bit more detail about the final points of the compiler phases. Again, it's all in his website. He has videos as well. I think he does a couple of different talks for, I think he has one talk. Actually, this one is from Scalawood. He has one on Scala Ukraine where he talks about the DOTI linker stuff. It's pretty good. So links are all there. You also have the non-blocking lazy valve. There's actually a link to the SIP. If you want to read it in more details, you're going to bring support for static annotations on methods and field. You're going to have support for multiversal equality. So instead of actually having basically library-specific implementation, I think the good example is sort of in Slick where you have sort of a box type. You have to do the three equals. You can actually sort of bring this sort of multiversal equality using two equals and implicit. So links there if you want to have a look at it. Along with Union and Singleton types, they're also going to have literal Singleton types. So if I can remember... Let me just... actually... whoops. It's one of the things that I just realized that reset in the REPL doesn't actually do reset. It actually does replay. So if you want, you just need to quit and get into the console again. So... whoops. Say... 5 equals 42. And go. Sure. Now, I can't remember what examples I was going to bring with this. It's kind of like very useful. The examples that they talked about was in Scala.js, where you actually can call a method parameter by name. And let me just go to my notes. Hold on. Sorry. Oops. Nope. Where's my notes? Oh, here we go. Okay. So it's being used heavily in Shapeless as well. So I think you can sort of define the types by its name. And the last one is some improvement in pattern matching. So all the links are there if you want to check it out. We're almost gone for time. So there's only a few slides left. So there are a few things that are actually currently being considered in .t. This is kind of small, but I think people sort of want this. It's basically just in tactic sugar for enums. The moment if you want to do enums in Scala, you just use siltrate or abstract class. And you just basically provides all the, you know, with case objects. And if you need to iterate over, you know, you probably do macros and things like that. So I think this kind of gives you a little bit more convenience and has some sort of enforced... Well, it's going to enforce some behaviors to do a Java interrupt a little bit better. The other one is non-knowable types. So once you have, you know, the option type, you can actually now encode a type, you know, having a type or a null. So what they're thinking of doing is actually to extract a null to its own separate type instead of everything inheriting from null. So if you work with, say, a Java library and, you know, it might be passing in, say, a null type, then, you know, you could have something like the T question mark, which is a type of T or null. So this is kind of like one of the things that I find in Kotlin quite useful, that, you know, if a method or, you know, a property of members doesn't return a value it might be null, then you actually explicitly have to call the value. So you do, I forgot what it's called. But you have to do sort of a question mark dot to actually cast it to its type. Otherwise, it won't compile. So yeah, I mean, once you have union types and, well, once you have union types, it's pretty easy. Oh, I think. The other things that they're considering is better records. So records is kind of like tuple with parameters, sorry, labels. So instead of just defining just, you know, int, you can actually call it something, say, you know, int1 as type of int in something else type of. So I'm not quite sure where it's going to be applicable, but you know, probably going to be useful. They're also talking about an effect system. So I think this is sort of in line with Haskell, where, you know, if you have a side effect, you actually have to mark it specifically. So I'm not exactly sure how it's going to work. And I think they're sort of like considering a few different ideas as well. And, you know, with the talk of singleton types and things like that, I think they're going to have better generic programming support, I should say. So libraries like shapeless, you know, it's probably going to improve a little bit better. And the other thing as well is implicit functions. So they do have an example in the website where, you know, how if you have currently an implicit parameter, you can actually convert it into an implicit function. So, yep, if by this, at this stage, you're wondering when, you know, you're going to see Dottie. Unfortunately, not this year, may not even be next year. So what's going to happen actually is that, well, they are planning to release the, say, technical preview or alpha one or 0.1 sometime this year. But they're actually going to be focusing on Scala 2.13, which can do a lot of improvements within the standard library and collections. And then there's going to be Scala 2.14, which sort of backpots a lot of those tooling, you know, taste compatibility in it. And maybe, maybe we'll see, you know, basically Scala 3. But obviously there's no sort of hard timeline to it. So, you know, it's ready when it's ready, I guess. So, you know, it's Dottie's open source. If you want it sooner, you know, can involve help. Well, you know, I did sort of get started, you know, having a bit on the DottieDoc side of things, because it seems to be, you know, the most straightforward one. I don't think I'm that comfortable, you know, jumping in straight into the compiler. It's pretty easy to get started. Just go into their GitHub repo. Look at the open issues. They have staff marked as help wanted. So just put your hand up, say, you know, how could I help with this? They, you know, going to have the actual core team member come and talk with you. I talked with Felix on Gitter. So, you know, talking about, you know, what he wants to do with DottieDoc and things like that. So they're pretty friendly, quite supportive as well. So don't be afraid. And, you know, apparently they say that, you know, all this stuff isn't too hard. So, you know, if you want to get started, there you go. And that's pretty much it. So hopefully by this time you haven't been, you know, I can see you're all still awake and not too bored. So I'm hoping you learn something a little bit new about Dottie today and maybe talk with your colleagues and get them to get involved with Dottie as well. So thank you. So, if you have any question, I can't promise I'll be able to answer it. You can ask anything you want. Of this question, like, dependent type is a great thing. But usually the problem with it is a cannoliative syntax. It's hard to explain dependent type. So how it looks in Dottie, for example, if you want to have a generic list of a length of four, how would you look like and in which case is it possible to infer that the list is a length of four? Yeah, that's a good question. I'm not sure, because to be honest, I'm not really that comfortable with how the syntax is defined in Dottie as well. I mean, I keep looking and, you know, still trying to understand how it's all going to work. So unfortunately, I don't have a really good answer for you. I'm still sort of at the beginner stage with this new, with Dottie as well. So far, you know, I've looked at, I guess, implemented features and how it relates together and how it's actually, I guess, fits together with the current Scala. But yeah, it's, sorry. A little bit subjective question with how backward compatible Scala 3 would be. Because it looks like it would be that four types, composable types or whatever, it might require a significant rework of pretty much everything that's to interpret with Java libraries. And it basically means all the libraries out there that interpret with something from Java world would need to migrate to version 3 with manual stuff. And there's an example of the language that really struggles to migrate to version 3 because of exactly that, which is Python. So this is kind of a subjective question. What's your opinion of that? I think they're sort of conscious about this problem. I mean, people have been complaining about, you know, having to migrate even Scala say 8, sorry, 2.8 to 2.9, then 2.9 to 2.9. And everything breaks and, you know, everyone has to sort of spend a lot of time in their code base, which is sort of why they went ahead with the tasty approach. So they encode a lot of information. So in a way, some of those sort of heavy lifting will be done by the tool. And I guess the developers or the engineers or the programmers will, you know, I guess do the final checks. So I'm not exactly sure because at the moment it's still in a lot of flux. I mean, you know, we know that, you know, for some it's going to break existential types, how it's going to work. I guess, you know, it's even higher kind of types is still sort of the weighing on several alternatives. I think when one of the comments, Professor Odeski did mention that if you stick with the normal sort of Scala languages and if you stick with well-known libraries, you're probably going to be okay, but, you know, obviously it's case-by-case basis. But, yeah, there are tools, but it really depends on, you know, it's not going to be just like smooth, but they try to make it easy. Yeah. So this rewriting tool is going to take care of macros as well? Actually, good question. No, I don't know about that actually. It does with the normal code base. Do you suggest you still work with libraries that can rely on those? MacWire, for example, it's really good to use in Scala. Yeah. So the numbers about that you can still use in libraries, you can compile your code with a number? Yeah, I think from what I've sort of seen in the Scala machine representation, everyone is sort of just already moving towards Scala meta. So if you're developing anything new, just maybe focus on that instead of the current macro implementation. I think up to 2.10, it's still like this experimental. And, you know, I'm actually quite surprised how soon they actually dropped it. Yeah. Because DOTI supports this whole SVT DOTI code and supports the cross compilation. It's Scala version 2.11 to 2.12. You can sort of use the Scala 2 flag to compile to Scala 2.11 bytecode. You can use Scala 2.11 library in your DOTI code, but I don't think it does cross compilation well at the moment. Are there any libraries, Scala open source libraries which are compiled to DOTI? No, not at this stage. I mean, in terms of language, parity is not even close to the current Scala yet. So, I mean, you can sort of develop small prototypes. I mean, the compiler compiles itself, but in terms of actually, you know, I guess non-trivial libraries are not aware of anything that uses DOTI. So the ecosystem is basically nonexistent yet? Not existent. But, you know, depending once it's mature and people think it's ready, then people will migrate. I think personally, you know, I've seen a lot more faster transition from, say, 2.11 to 2.12 than the previous version, so that's actually kind of optimistic. So I'm hoping that, you know, if they did what they say they're going to do, say, backport a lot of this feature back to Scala 2, when it comes time to migrate to DOTI, then hoping that's going to be a smoother transition as well. So I mean, they say it's, you know, big major version 3, but I think it's going to be a lot less things that's breaking. So... 9.3 took 10 years to become popularized, so hopefully this will be faster. Journal 6 never actually launched. No, never become popularized. So how does DOTI compare to SBT? Oh, they're actually... Why should people switch to DOTI? Oh, DOTI and SBT is actually two different set of tools. So SBT is kind of like the build tool that helps you, I guess, what do you call it, takes your project artifact and actually compiles it, but, you know, it uses Scala as your DOTI in the back-end. So, I mean, it's kind of like independent. Well, the demo I showed you before, it's actually using SBT 0.1313. So it still uses SBT. It's just that, you know, we switch the compiler from Scala C to DOTI. Yeah. Oh, by the way, I think SBT 01315 is just released today, so I haven't had a chance to test-drive it. Yeah. But anyways, it's, yeah. I mean, it's not ready for production use, but, you know, it's stable enough if you want to play an experiment with it. Cool. Everyone's good? Cool. Thank you.