 Cool. So just a little bit about me. I'm Hurdy. I'm a software engineer at one of the banks here. I'm currently working in Scala and Kotlin, obviously. I have other interests in other languages like Alexa and Elm. So I'm still dabbling at it. I also like to maintain this. I'm currently maintaining a couple of open source projects. I'm also busy organizing Scala Meetups and also doing some volunteer work with NUTSSG. You can find me in the Internet, Twitter, GitHub, and I also have a website. So not much in there though. So sometimes I think it's a little bit hard to sort of explain why we're doing what we're doing. So I want to start this presentation with a little bit of information about why Scala and Kotlin. So the idea for this presentation is not to actually compare. It's not going to be a language war, which one is better. But it's just to give you a bit of information about why we chose both for our current project. So, you know, as the story goes, the business said, you know, why not roll out this product globally? So they come up with a new, basically, requirements. And as engineers, we have to do our best to actually basically deliver what the business wants. So, you know, sometimes it's a small thing, but in our case, it's actually not quite a small thing. So they come up with, I guess, the direction that we're moving from what was predominantly a batch-oriented product. Now they're wanting to turn it into more of a real-time product. So there are a few challenges, though, you know, with such a big shift. One of the biggest is the amount of the technical depth that we've, I guess, sort of accumulated. So the existing product is actually written in Java 7, Java 7 code, and Java 7 runtime. And if you've worked in a bank before, you know how hard it is to actually get that updated to Java 8. But, you know, when I joined, one of the first mandates that was given is that, okay, so we have this product. So we want to see if we can come up with a nice new improved algorithm. So we decided to write in Scala. Of course, things never really went to plan. So they decided, okay, we want to accelerate this. So it's like, what? Okay, so, you know, we're going to be delivering this new product in quite a tight deadline, but at the same time we want to improve the developer experience. So a lot of the boilerplate code we want to basically remove just trying to be able to concentrate on business logic and flow and of data. Also, you know, right now the code is not in the best shape, so it's actually quite hard to test. So we want to make it easier as well as we go along the factory's things. Of course, the Java 7 problem, so right now it's running on WebSphere application server on Java 7. But, you know, because cloud is the way to go these days, so we want to support it on Docker and Kubernetes. So that's one of the challenges as well. So basically this is what I feel like doing. You know, you have a car running and you're trying to change the wheels while it's running. I'm pretty sure you're all familiar with this scenario. But why Kotlin? So we have the Scala code, but why Kotlin? So purely subjective reason, because I've used it before. It's all right. But other more objective reason is because they have good Java 7 support. So starting from Kotlin 1, they do support Java 7 as a target, like Scala as well. So Scala 211 does compile to Java 7, sorry, Java 6 compatible bytecode. But at the same time, it has more, sorry, Kotlin has modern language features, good collection libraries, which doesn't require you to upgrade to Java 8. And this is one of the key features of it is two-way interop with Java code. Some other reason is basically Google's endorse it for Android development, so we know it's not going to go away anytime soon. Well, I hope, unless Oracle has different ideas. So I'll go into a little bit more detail why Kotlin and Scala. But for the purpose of this presentation, I'm just going to give a little bit of an overview on how those two languages are actually quite similar and how they are different in some respects. So if you look at this piece of code, oh, pizzas here. Basically, it's hard to tell which one is Kotlin and which one is Scala because they are the same. Sometimes if I open up IntelliJ, go to a file, it takes me about one or two seconds to figure out, you know, what the hell exactly I'm writing here. It's just Kotlin or Scala. So, of course, I'm exaggerating, but for this simple variables, VAL and VAR, it's kind of like it has similar concept in Kotlin and Scala. So once you assign to VAL, you can't assign anyone. Again, same with VAR. Kotlin also has a concept of case classes, or in this instance, they call it the data classes. The only difference being that it's called data classes, and it also has a VAL in front of it. So to, I guess, to show that it's actually a public property. However, unlike Scalas, they actually generate the getter and setter automatically. So again, back to the Java 7, oh, sorry, Java two-way interrupt. When you see this, when you try to use this class in Java, basically the signature is what you would expect in Java code. So you get user.getname, user.setname, and so on. String interpolation, kind of like similar, mostly, except in Kotlin, anything with a double quote, basically you can just put a dollar in and it's string interpolation. Multiline is kind of similar as well, so you can use margin and strip it. So, in all honesty, I can't remember which one is which, because I didn't actually look at the document, but just try one of them. It'll work in one of the language. The other way around, isn't it? See? All right. I just written this one to be able to call. Okay, great. Some other small features. lazyDelegates, quite easy to do in Scala, lazyVal. In Kotlin, it's by lazy. And of course, we also have companion objects, so where we put all our static stuff in. So in Scala, you could define it at the same level. In Kotlin, it's actually part of the object, so you define it as companion object. Actually, I forgot what I was going to say, but just talking a little bit about constant, that in Kotlin, they have a specific keyword for constant. And on this example as well, that Scala uses depth for methods, but Kotlin uses run. Actually, this is not valid Kotlin code, because it doesn't have the brackets. You can have object, actually, yes. But this is just the way, well, yeah, you have class and you have objects, you have data class. But this actually, yeah, that's also one of the other similarities as well. But in order to create companion objects, this is how you do it in Kotlin. Put an object, lazyDelegates, Scala. I don't believe so. I don't actually use it that often. We use data classes and class, but yeah. They also have deconstruction. So in this example, I'm actually giving a tuple, which is quite easy to construct in Scala. One caveat in Kotlin is that they only provide parent triple. Anything else, you have to build your own data structure. But any data structure, data class that you build, is actually, you can deconstruct like tuple. So you can actually just extract it, just A, B, C, D, E. Then type alias. Now it's probably quite a trivial feature, but sometimes when working in, I guess, like a complex code base, you want to give different meanings to say, I guess, primitives. So sometimes we want to define money as amount, but you don't really want to create a new class for it. So as in Scala, at compile time, it's just going to basically fall back to the original type. So that's, I guess, some of the stuff that is actually quite, well, almost the same. Now there are a little bit of differences as well in Kotlin. So one of the key things here are nullable values. So in Scala, you can still define something and then assign a null to it. But in Kotlin, they actually do enforce it at the compiler level. So if you define a local date, sorry, okay, let me take a step back. So just to give a quick explanation, whenever you see a question mark effort type in Kotlin, that means it's actually a nullable type, which means that the value could be either that or null. But however, in Scala, you have the option type, but the thing is like in option type, you can actually assign null to it as well. So in this regard, when dealing with Java code, it's actually a little bit better. One annoying thing, though, when you're actually using Java libraries, anything that comes to Java, you'd see in the API docs, comes with an exclamation mark, meaning that don't trust this code. You got to make sure it's not now. But within the context of Kotlin, whenever you define your types, you have nullable types, it will force you to deal with nullability. So I'm giving you an example of a let operation, which is kind of like a map for option types in Scala. So this is sort of like a magic, what would you call it, method, because it works for any data type. So in this example, what I'm doing here is a date that might be null. If it's not null, then I'm actually getting the value of that and then getting the day of month. So this day can either be the day of the month or now. Same in Scala, so at the end, you would either get a sum of the day of month or none. So one particular, I guess, drawbacks of this is that when dealing with this nullability in Kotlin, when you actually put nullable Java value, this actually doesn't... Wait, sorry, let me track back. So today, local date, now today. So when you have a value and you put an audible value, it's okay, whereas in Scala, in Scala, you actually have to wrap it in option type. So sometimes when you're actually dealing with Java code, you have to be really careful about whether it's actually null or not. The question, does Kotlin have the flat map or map? Yes, but flat map is not... No, for... If you have an array which might have a value or null, you do map not null, which will remove all nulls. Filter not null, map not null. It's one of those. So flat map doesn't work like in Scala where you actually iterate over... Actually, okay, none option. It's okay, we can check the... Yeah, yeah. But yeah. One of the other good things that I like in Kotlin, it's actually easy to provide extension methods. So in Scala, you have to jump the hoops by providing an implicit class and then bring that implicit into scope in order to provide additional functionality to an existing class. Whereas in Kotlin, you basically just start typing the type, dot, whatever method you want, and then it'll provide you. So as long as it's important in scope, you can build a lot of these existing extension methods. So, you know, in this particular example, extend result set from JDBC. Of course, this is just an arbitrary example, but normally you have to... In Java, it's very hard to do. You have to wrap it over, but in Scala... One other difference in Kotlin and Scala... In Scala, basically, square brackets... Sorry, curly brackets, you know, just create a new expression block. In Kotlin, you have to use lab. So that's the magic right there. Now, one other difference between Kotlin and Scala as well is that like Scala, you implicitly returns the last item on the... Oh, sorry, the last value on the block. In Kotlin, it does require you to use return unless you use this. So in our project, we sort of, you know, set out on this lab convention just so we can keep that sort of like idioms similar with Kotlin and Scala. One other, I guess, similarities when, you know, creating ADTs. In Scala, it would be a sealed trade. You'd have case class, case object. In Kotlin, it would be a sealed class. And you can have a data class or object that extends from it. So the good thing is that in both languages, if you do pattern matching against ADT in Scala, it'll provide exhaustiveness. In Kotlin, it will do the same. So unless you specify, sorry, explicitly handle that case, the compiler will complain. Also something similar in the collection libraries. So they do provide similar methods. So you have the map operations filter. You can take the, I guess, the element at the beginning, head or first, support for deconstruction in Scala. And Kotlin is quite similar. One thing in Kotlin is that they don't use underscore. They use this sort of magic word called it. So every time you don't actually define, I guess, or sign a name, you refer to it as it. And pattern matching. So, you know, you have ADTs. You can pattern match it. So if you don't provide or you don't handle all cases or scenarios, the compiler will complain. However, this is one of the big drawbacks of Kotlin is that the pattern matching is, I guess, not as nice as Scala. So they don't do deep deconstruction. It's very, I guess, in my view, is just a little bit better of the normal switch statements. One thing that is quite different from Java switch is that whenever you check for type, inside this block is basically casted to that type automatically. So when you're dealing with ADTs, if it's a BMW, then you can actually basically just get the serious property. So as I mentioned in the beginning, Getter and Setters makes working with Kotlin code from Java relatively easy. You probably won't realize that it's actually Kotlin code. Just on this point as well, before I decided to move to Kotlin, we sort of continued down the Java 7 code until I got tired of writing code too much to write. We also used Lombok. So if you're not in a position to move to Kotlin or Scala, Lombok provides some of this nice feature. Although in saying that, they don't really work well in one project. Obviously, when you have Java code and Kotlin code, because in Lombok you define the properties just as private fields and you can't access the Getter Setter, you actually have to create them in separate modules in order to access them. So one of the, I guess, differences as well is in Kotlin you actually need to use this no argument plug-in in order to keep the existing Java convention because otherwise when you have a data class, you actually have to construct it with all the arguments supplied. So only with this that you can actually basically instantiate this object in the Java way. Well, in a way, yeah. So you have to, I guess, you know, it's a choice. But it was quite helpful, especially when dealing with, I guess, migration projects because you don't have to change everything at the same time. So this is exactly what we've done. So, you know, we had the old Java 7 code with this style and then once we, I guess, the code is in a nicer shape, we remove the plug-in and then that's just a matter of actually converting. Oh, no, no. No, unfortunately not. Oh, you can, I think it's just now. I can't, I don't know, I actually haven't tried it, so I didn't try to intentionally break my system, but won't try that. Good question, I think. Pardon? Yeah, you have to initialize it all the arguments with the properties initialized. Yeah, you have to initialize it all the arguments with the properties initialized. Yeah, yeah, exactly. So also the other useful plug-in is the all-open plug-in, especially useful when you actually use Spring, because Spring doesn't like if you have a lot of, like, final classes. It complains that can't proxy this, can't proxy that. So yeah, there is a plug-in called Kotlin Spring to alleviate this. The other way is, sorry, when talking about overloaded constructors, this is one way that it helps to do introp with Java code. So when you actually have a class with property with a default value, if you don't use this, basically it doesn't generate that sort of like overloaded constructor method. You simply add this annotation and magic. It's not the same with functions. Functions, I think it does it automatically, only in this constructor overloads. The other thing as well, static methods and fields, yes, you can basically create them in the companion object, but without the JVM static, when you try to access this fields of function, you actually have to access the companion object first. So it would be user.companion, then whatever it is. So with static, you actually sort of like converting it to a more Java way. One of the interesting things that Kotlin has, which I wish Scala had, is this thing, supply run and also. So what it does is, this thing is really useful to actually make working with Java libraries really pleasant. So it's actually quite helpful in terms of ergonomics. So I know sometimes you've seen those, when you instantiate a class with Java, you go new class and then class, set this, set that. So with Kotlin, you can do the method apply. And implicitly, it's just going to return this at the end. So with run, it's a little bit different where it actually returns the result. And one other thing as well is also, so you normally use it to perform some sort of side effect, but it'll actually return the callable value. So it's really useful, especially with some of the Java libraries, just assume that you want to mutate that object. You just use supply. So do this for it and then you'll get the updated object. I wish we had this in Scala. This object, yes. So I know I'm using the same example, but yeah, in this instance, the name is actually var h var. And then this would be something like a persistence that returns a persistent state of that object. So yeah, so very useful when dealing with Java code. You don't necessarily want to apply this in Kotlin code. Yeah. One other nice thing is obviously when dealing with the variable values is at the end of the expression, you still have a null, you can actually provide a default value. In this instance, I'm just throwing an illegal argument exception. So I mean, that's probably the main part of the talk. So I just want to sort of like close this talk with a bit of retrospective. So I haven't really touched on about some of the toolings that we used to actually get this thing working and glued together. So one of the things that I would like to highlight is that Gradle actually helps a lot. We had a choice of actually going with Maven or Gradle. I ended up using Gradle and I don't regret it. So no XML, it's concise syntax and it's scriptable. Basically, it's groovy. Oh, actually, yeah. I think they're just trying to have a level playing field between Maven and Gradle. I think for all of their plugins, they have both Maven and Gradle. Sorry, you have a question? Oh, no, okay. So yeah, the reason why I went with Gradle is because of the scriptability. Our project isn't exactly a typical one. So I'm actually leaning on all this scriptable scripting functionality in Gradle to actually get that sort of like working together nice. So just to give a bit of context, before I started on this whole project, the only way to actually compile and package a project is through Eclipse. So it took us a long wait actually to get this into sort of like an automated build-deploy package state. So I don't know how I can do it without Gradle. Ah, yes. So they provide, yes, the language. I think they're switching from groovy to Kotlin, which is awesome. And yeah, of course, it supports Scala, Kotlin, and Java in one project. The only caveat is that you cannot, well, the thing is with the Scala plugin, it always compiles last. So you cannot refer to Scala classes or Scala methods from Java or Kotlin code. So you actually have to extract it to a separate module and then you figure out how these things depend on each other. So you build some sort of like a nice graph, which is quite exciting. But the process, you get parallel execution. So we're using Gradle 4.7. And it's nice when you do Gradle W compile, you see it spins up like eight demons and compiling everything all at the same time. It's like, yes. People complain that, oh, Scala compiling is slow. But if you're compiling eight modules all at the same time, it doesn't really matter. So anyways, I talked about Lombok. We used the data annotation to sort of like create that automatic get and setter. For logging, this is pretty useful. We use type safe logging and also K logging, which provides some similar functionality. So it automatically provides you with a one thing that we're trying to sort of enforce is that all our tests is going to be in Scala. So I think that's one of the good things that all the testing ecosystem is a lot more mature. And this is the first time I'm actually running Scala with a genetic unit test runner. I didn't even know it actually works out of the box. So that was great. So with Spring, you only had to provide a little bit of code to give it a bit of like the context management feature. But then it'll just work. And of course, Gatling as well, being quite indispensable. And it's written in Scala. So anyone knows what Gatling is? Anyone use Jmeter? Jmeter. Yes. That's better. No, I'm just joking. No, but because it's written in Scala, so it's kind of like all the Scala ecosystem in the testing environment. It's sort of like nice and cohesive. So it comes to, I guess, the point. Throughout the presentation, I've sort of talked about the similarity. So it seems like there's actually quite a big overlap. So when would you use Scala? When would you use Gatling? I mean, for me personally, I would probably fold to Scala for any new projects. But just for this particular one, because we have a lot of sort of like code that we actually need all older. Sorry, Java 7 code that we need to work with. So Gatling kind of makes sense. So the title of the Java++ now falls to Gatling. I guess we can call Scala the Haskell minus minus now. So a lot of overlap, but it's still lacking in a lot of respect. And I don't think that's where they want to go anyway. Kotlin still uses a lot of the facilities from Java unchanged. So we do find issues with, or not exactly issues, but annoyances like type erasures and having to do casting. And you just litter your code with suppress here, there. So just to get off those annoying messages. But if you're still in Java, can't move to Scala for whatever reason, this is probably a good bet. So some of the lessons learned, we use mostly Kotlin code in the core or common module because we need to preserve that sort of like entrop between Java and Scala code and Kotlin code as well until such time that most of it are Scalaified, I guess. So like what I mentioned as well, we basically break down our project into a lot of modules, provide hard boundaries. But the benefit is that the build is heavily parallelized. Now it's not really fun actually having these three languages in a project. Anyone can tell you that, especially with, you know, I guess the build order. Sometimes you start writing, IntelliJ is smart enough to recognize, oh, you're trying to reference the Scala code from this module. But when you run the compiler, they say, no, no, I can't find this. Fix it. Scala type conversions. Yes, implicit everywhere. So unfortunately it's, well, it is quite unfortunate that we had to deal with Java big decimal. So we had to do a lot of conversion, Java list as well. Oh, the good thing about Kotlin is that all this sort of like collection method just works on normal Java types. So that's a good thing. And of course, you know, if you think that writing in Scala can be done in many different ways, well, same problem you're going to meet with Kotlin, you know, it provides that kind of flexibility as well. But most of all, you know, trying to get this thing sort of like cohesive, there's a lot of orchestration with all the different team members. So, you know, had to agree on, you know, what approach we take syntax, code styles, and basically what we're going to do in the long term. So we agree that, you know, Scala's the way to go. So, but in the meantime, you know, we'll use Kotlin. So what's next? So, you know, this is still me pondering about where we're going to take the code. Obviously, one of the things is that, you know, I think everywhere. Oh, let me start first. So, you know, whether it's actually makes sense to bring some of this sort of like functional programming idioms to Kotlin. Is there any value to it? I mentioned AeroLibrary. It's basically just a greater dependency way, but provides us with these types, option types, and all those things that come in the Scala standard library. So maybe need to spike on it a little bit. And also, once we move to asynchronous, how are we going to bridge this gap within the Scala future and within Kotlin coroutines? Does it make sense? I don't know. We'll see. And the other thing as well is, you know, because of this sort of like, I guess, two different languages, three different languages, especially for Scala, you have to do a lot of conversions. You know, how much cost are we incurring here? So, of course, for end to end, we do have Gatling. One of the tools I've used before was Scalameter. Again, you know, mature testing libraries in Scala. Scalameter is actually sort of like a macro benchmarking library. So you can actually, you know, basically bench your method execution time. It does warm-ups and then basically drops a bunch of stats for you to look at, including memory consumption and things like that. But we haven't done that yet, so maybe soon, I hope. And that's it. Anyone have any questions? So you're using Kotlin now for the Java 7 interop? Yep. So you're on the Java 7? Yep. Yeah. How much interop are you doing with actual Java code? Yeah. Are you calling Java code from Kotlin? And you're pretty much leaving that untouched? Yeah. Or what? How does that... Okay. The thing is because I guess that particular code base is a little bit tricky to... Basically, we can't do migration all at the same time. So what we're going to do is actually refactor, I guess, portion of the code into, I guess, a function and then move that over to Kotlin. Something along the line of that. So you still need to call the new code from the old Java code. So, I mean, you can sort of do it in Scala, but it actually is a little bit harder and sometimes like it doesn't... The method signatures doesn't quite... Okay, so collections are a bit harder. What else? The collections? Collections between Scala and Java. Verdin collections. Yep. Of course, I mean, all the other stuff are sort of like vanity because you're dealing with the Kotlin data classes. It's not as nice as using it in Scala because you don't have to apply and apply and then you don't like the... I guess, what else? What I'm getting at is... Okay, so it's transitional now. What happens when the entire code base is all Kotlin and at some point you get approval to run Java 8 or Java 9? Oh, actually, about... Yeah. And then, so now you have a code base of Kotlin and Scala. The syntax is relatively similar. Yep. What would you keep Kotlin around? Is there a case for it? Yeah. So one use case that I think is valid is actually at DH, which is the web application framework because we're relying on a couple of, I guess, important... Well, we use Spring Web and there's also a library to generate JSON API spec responses. So the mature one is only available in Java library. So that's what makes sense for us to keep it in Kotlin. But for everything else, we're hoping that we're actually just going to use Scala for that. So again, the only use cases for me personally is when you actually have to really deal with Java libraries and Java code. Okay. Yep. Just one comment also about the type conversion. We also use Scala in our so-called the Kotlin model. Yep. We use Java and the Western Web layer. So we realize that it's actually a lot simpler and at the same time, a lot more powerful, you just use the Scala data types in the Java project because JSON anyway can convert some of the Scala objects back to JSON. Okay. Okay. Now that's actually an interesting comment. No, I have to look into that. We're using Java powerful collections like this. Yep. Okay. I'll have to seriously spike on that. Cool. Thanks for that. Any other question or comments? No more? Well, oh, yes. How much people in your team use Scala and how much people use Kotlin? Okay. No one use, oh, no one use Kotlin before except me. So in the beginning, it was sort of like a lateral decision. But I think it was because we had this sort of constraint. So, you know, we could keep it in Java 7 code. But then obviously, you know, we don't really get that sort of like, how would you say, like the code is not as easy to understand as if you were writing it sort of like the Kotlin or Scala idiomatic way. So, but in terms of Scala, some of the people in the team have had Scala background. And of course, you know, when they move into Kotlin code is, you know, not that hard. Because some of the, I guess, syntax are quite similar, except that, you know, some of the things that we can do in Scala, we can't really do in Kotlin. So that is kind of frustrating. So, but good thing is that the Kotlin standard library documentation is quite comprehensive. So sometimes we can actually just figure out a way how to, you know, do a similar thing in Kotlin. So. So I understand this currently Kotlin is the second rewrite of this code piece. No. So what happened is that we started to spike on this new algorithm in Scala. But at the same time, we need to bring this all the code base. And basically the two has to meet together. So, because the code base is already running in production. So we can't easily write them all in Scala all at one go. So we're choosing to the sort of like migration, you know, step by step. So, you know, just take bits of his converted into Kotlin. Some of the core stuff that don't depend on the existing code base can be written in Scala. So it's kind of like a bridge. Oh, sure. I follow up for the team thing. So it's like a group that does this algorithm spiking in Scala? Or does another people have to work with putting it into the system system? Or does everyone has to now work in all three languages? So most of us in the team don't have to deal with the Java 7 code. But definitely people who actually deals with the new code base will work in Kotlin and Scala. So like, you know, we provide sort of like help in terms of pair programming. And also we, I guess, help them in code reviews as well. I know it's not going to be easy. The other challenge is that, you know, of course, we are kind of like distributed amongst teams. So sometimes the only feedback that we can give is through code reviews. So of course, you know, when you have people coming from Java backgrounds, they move into Kotlin or Scala, they write it in a way comfortable, which is the OOP way. And then we give advice about, okay, you can actually do this way in Kotlin. Most of the time, like, you know, they got it our way. Why are we doing what we're doing? Things like, you know, like, you know, those variables have to be immutable because, you know, you don't want to accidentally change the value and things like that. And plus some of these collection features, most, you know, are familiar with it through the Java 7 library. So it's less of a big jump than people think it is. If you could upgrade in Java 8, would you still go with Kotlin? If it was available, you know, I'd probably start using Java 8 streams or, you know, all their collections library. So, you know, things were different, I might not even consider Kotlin. So of course, you know, I might still bring the Scala code base because we already had developed it. But yeah, and it's just because, okay, you know, we have this runtime that exists. But, you know, I don't know when we can actually upgrade. So we choose this as, I guess, an option. Sorry, full back mechanism. So what kind of related to this question? Was using an older version of Scala that could target Java 7.0? We're using 211. That can pass down to... So I guess the question would be, rather than actually rewriting the Java code base in Kotlin, was writing it in Scala actually in Kotlin? Yeah, it would be. But it's... I guess one of the things about that is the two-way interrupt isn't as nice. So yeah, I mean, it's easy if you only need to call Java code from Scala, but when you need to do it the other way around, it's... Yeah. Are you guys using the Arrow library? Arrow? No, not at the moment, no. But I mean, yeah, that's one of the things to consider, like, you know, if we get anything from introducing these, you know, option types by either... Is it really necessary at all? Arrow. Oh, yes, Kotlin Arrow. So they provide sort of like this functional data types, type classes, and all this other stuff, nice things that you find from Scala as basically a dependency. So... Is there anything that is not there in Kotlin? At the fundamental level, the pattern matching is really lacking in Kotlin. Is there anything like four comprehensives? In Arrow, yes. In Arrow, but not in base Kotlin? Yes. Future? Coroutines, I guess, but it's a bit different. Sorry. When you have your final game, you have your post now in the future in Kotlin and Scala. How do you intend to migrate everything to Scala? Oh, we don't intend to migrate everything to Scala. Most of it, we want to keep it in Scala only at the, I guess, this key modules which deals with the spring web and this JSON API spec library. I think it makes sense to keep it as Kotlin because it's just the way, I guess, the way you use the library. Is there a situation where you have to call Scala Kotlin Kotlin? Oh, yeah, we're already doing it now. Yeah, but it's a couple of... Either it's actually a Scala object so we can actually invoke the method directly or we enforce interfaces on the common module and that Scala class implements that interface. Because we use spring, so there's a bit of a DI going on. So it's the spring, something, legacy that you inherited? Or choice to use spring? Not to use spring. Well, certainly once we... Well, I guess I won't say finish migration, but once we have the code base in a good state, then there might be an option to use something other than spring. But right now it's because the existing code base uses that, so it doesn't make sense for us to just completely throw that away and while the core is still untidy. So I guess that is going to be the last thing that we would change. And you mentioned Scala tests during writing all of your tests in Scala? In Scala, yes. So we have some tests in basically just the JUnit tests so we're converting into Scala tests. Even the spring integration test is in Scala tests. So say you have Java engineers and they're used to writing in Java manner, type the hats. Would you say writing your tests in Scala, would be a good way to introduce Java engineers to Scala tests? Yep. So actually that's one of the first things that our colleagues done. So they started writing tests in basically Scala tests. So that's also how they actually experiment with the language. Because when you come to the implementation it's a little bit more tricker, but with tests you basically just invoking method or preparing some data and then basically inserting on it. So, yes. So they do kind of like a TDD but also as a learning experience. Have you introduced any functional concepts? Not right now, no. So just a little bit of careful about introducing too much too soon. So your mind will melt. So we're still using DI and it's basically just like the spring way where you use all the wires inside. Next step is to actually just convert it to a constructor injection and then next step of that is, yeah. Because the thing is you don't want them to hate the language. Just give it a bit by bit. So if it's too complex then they just are, what is this? Yep. Cool. All right. Thank you everyone. Thank you.