how awesome Fp is, and you wish that they would just tell you, oh yeah, okay, great, great. And how many of you who are already using social programming languages at work wish that your company would adopt them more? You'd use more of it. No? You guys have 100% Fp already. Oh, that's okay. Also, this is a story about how our company transitioned from Java to Haskell. And hopefully, you guys can take away some tips about how to make it convince your organization to make the jump. First of all, let me tell you that our company things move quickly in the startup world. And actually, as of two weeks ago, we've branded from Sumo to Odeco. As Odeco, what we do is we use machine learning to do predictive ordering and inventory management for small coffee shops and cafes. Previously as Sumo, we were doing data analytics in the social media realm. And our Haskell transition happened when we were sort of in that form. Get another sidebar before we begin. Java. As much as we, especially the people in this room, we like to like trash Java, it was a really good thing for the software industry. In its heyday in the late 90s and 2000s, it really was like an order of magnitude improvement over what was before. You had some great things, a better object oriented features. You had managed memory, you didn't have to free your own pointers. And decent web libraries and of course a familiar C-style thing happened. So Java was really a 10X chain, really revolutionary for the industry. So then why did we move away from Java? Well, in June of 2014, this is what we looked like Sumo. We had eight Java developers, at least on the back end, we had eight Java developers. We had a monolithic Play app. I don't know if any of you are familiar with the Play framework. We were on the original really old version of the Play framework that was on Java. Nowadays it's Scala. And we were not having a good time. Our development speed was slow. We, it's a big monolith, lots of spaghetti code, very difficult to make changes without screwing something up terribly. Maintenance cost was high and developer satisfaction was low. So as a solution to this, we decided to let's stop using this monolithic thing and let's move to a microservices architecture. And by moving to this architecture that gives us an opportunity to go polyglot to use some different languages. A bunch of, we can use a bunch of different languages together for that reason. So why, so, okay, we can use different languages now. For YFB, why functional programming? Point number one, we wanted to find out well, could functional programming be the next revolution? Be the next 10 exchange like Java was, 10, 15, 20 years ago, okay. And the next thing was the recruitment of different shares. Java shops and Python shops are a dime a dozen. We can say, hey, we're a Java software company, here's our job posting, please come work for us. But we really look like all the other Java shops out there. But if we say, hey, we are using functional programming in whatever FP language, that differentiates us. That makes it a little bit special and perhaps that will allow us to more easily repeat. So why Haskell in particular? There are a number of different functional programming languages and you might think, hey, we were on Java already. It would be pretty easy or easier to just stick with the JVM, move to Clojure or Scala or something like that. Well, as part of the transition to microservices, we wanted to use Docker and JVM on Docker is problematic. You like have this giant container on top of another container and you might screw up some things with resource management. So for us, that eliminated Scala and Clojure. We wanted multi-core support and that eliminated vocabulary for us. So we wanted to compile down to some native code instead of running on the JVM and we wanted multi-core support. And also we figured, hey, if we're gonna go to functional programming, let's go all the way. Let's go to the strictest, most awesome functional programming language that didn't allow us to cheat, right? We used OO features like in Scala, you can cheat, so let's not do that. Well, if we're gonna go all the way, why not go through something like Idris? Well, I mean, at the time, so now, no, not quite production ready. And I didn't have a large health community and we were comfortable just jumping in. So we chose Haskell. And actually we already had a person on our team that was really big Haskell fanatic, the Haskell expert supports that outdoor decision as well. As it turns out, moving from Java to Haskell is really not that much different from any other kind of big organizational change. Most of the work, most of the resistance you might get is political, not technical, right? And in order to affect any kind of change, one of those individual change, you really have to do these three things. You have to gather your champions, you have to convince the people who haven't decided and you have to outlaw the group of crafters. So who were our champions? At the beginning of this, of this, I guess, weekly, our, there's a guy whose name is Todd who actually was supposed to give this vision to me but he couldn't make it on the trip. He's our current CTO, but at the time he was actually not our CTO, he was nearly a very senior engineer. We also had one senior distributed systems developer who was the Haskell expert and we also had another senior full step developer and these were our champions who wanted to push for the Haskell. Now, very, very fortunately for us, our CEO at the time and our CTO at the time were very receptive to this change. They were really, they really wanted to innovate the company, to innovate. So convincing them, fortunately, was not a big problem. It turned out it was actually more about to convince the rest of the engineering team. So our next step, so we have our champions, our next step was to convince undecided. Now, Haskell is known for being notoriously difficult to learn, whether or not that is really true. For example, perhaps it's true because most people come from an OO background and it's difficult to switch to FP. Perhaps if somebody learned FP from day one, it might be easier, but the practical reality is Haskell is difficult to learn. So we decided to run an experiment. We wanted to see if we can train somebody who was like a Java only developer and to become a successful Haskell developer in a reasonable amount of time. So that we can convince all the other people working inside it, and quite frankly, to convince our champions too that this was possible.  This developer was also a very good looking person. So what resources did I use to learn Haskell? Well, back in my day, in 2014, the Haskell programming from First Principles e-book wasn't out yet, some of you may be familiar with this book. I think it's considered like the gold standard nowadays for learning Haskell, it's a very good book. But back then we didn't have that. So what I used was there's a really great course given by the University of Pennsylvania called CIS 194. And they make all of the future materials online and that's what I used primarily. I also used learning your Haskell, you've probably seen that one before, and a lot of support from my colleagues, especially the ones who knew Haskell already. So what happened? Hey, success, I did it. It took me a while, it took me like two months, almost full time, for me to really be comfortable developing Haskell by myself on my own.    So after the successful experiment, our roster of champions was, again, our senior developer who is now our CTO but at the time was like a VP of engineering, our one Haskell expert, or we have one intermediate Haskell guy, and after I went through the experiment, we also had another person come and learn Haskells, we had two Haskell newbies as well. So this was our Haskell team. And so now that we have this roster, we are ready to start developing some new stuff in Haskell. So what do we need to do? We had to change our continuous integration frameworks to be able to handle Haskell. As a Java only shop before, we only handled Maven, Nexus and all that stuff. And now we had to switch to using GHC and Cabal for package management. And even back then, Stack was not around, the Stack beta, I booked this up the other day. The Stack beta didn't come out until 2015, which seems beyond what beyonds going. I cannot imagine life without the forced that now. And he's not here right now, so I guess I can show this picture, but a special thank you to FP Complete on the person in the dark for giving us Stack. Of course, in addition to changing our build infrastructure, we also had to run a bunch of new code, had to rewrite a bunch of existing business logic. And that would unfortunately, during this period, we were also doing that new architecture to microservices. So there was a lot of opportunity to write some clean sheet stuff, which is very helpful if you're trying to read your language. So we wrote a bunch of new services, took us a little while to settle on a web framework. We used Snap, then Scotty, and then finally decided on server. Yes? How do you handle the development of developers? Sorry. How do you handle the change in the development and project? Does it support cross-compilation in a seamless way? So developers need to have the same like the next steps of the process. Oh, the question was, how do we handle like a cross-compilation? Correct. And how did developers, do we have to have developers on the same, like mobile environments? Well, the answer is, so there was a subset of the engineers who were working on Haskell and by and large, they were all on Linux, Ubuntu, and laptops. And everyone else who was not working on Haskell were either on Macs or Ubuntu. So some more code that we needed to write is we had to write our own Netflix Eureka client. Netflix Eureka is a framework developed by Netflix for service discovery. This is the thing we were using at the time.  So we had to like, write our own. And we finally had to learn how to version software properly. In the Maven world, we're more familiar with Maven. Whenever you do a build in a release, it just picks up the patch number four here automatically and you don't even think about it. So that version of ours like completely meaningless. You have versions like 4.2.5. But to really use Haskell property, use the matters of dependencies properly, we really need to finally learn how to use Sembert. So, but even after you learn Haskell and you can code in Haskell, there are things you should do to make your day-to-day life easier. So we adopted a couple of policies that made it easier to work with Haskell day-to-day. Number one, this is a very specific thing. Always use explicit imports, please. That first line import data.text, that is the equivalent in, let's say, Java import com.globalot.store.  This is very important because there's nothing more frustrating, especially to Haskell you need. To open a file, read the code, see the name of the function that you're not familiar with and have no idea where the LN came from. Because you look at the top of the imports and they're all just implicit imports. And unfortunately, a lot of open source libraries in Haskell right now do use implicit imports and that kind of sucks. Haskell has a very, very high skill ceiling. There's the NLB and then there's the Haskell wizard and the gap is very high. So you can develop some really great skills in Haskell and write code that is really slick, really powerful or really tertially short. But if you use those, all those powerful features, they're often more difficult to understand. And you don't really need those features to get work done day to day. So here are some things that we actually, we chose not to use. You have one of these things. So in Haskell, there's such a thing as language extensions. They are features that are added to the language that roll out with every release. And you can actually start using them before they're like officially turned on by default by explicitly saying, oh, I want to use these in that feature. There are lots of features like this out there and some of them are very cool, very powerful. But some of the more advanced ones, you can get a little bit hairy, a little bit difficult to understand. So we made a point to avoid the really advanced one and the definition of advanced is kind of subjecting, but we kind of stuck with the level of type families. That's one of the extensions. Around that level of difficulty is where we kind of draw the line. We also tried using the operational loan ad once. I don't know if you guys are familiar with it. Didn't really work out for us. We kind of stayed away from that. This last one, I'm gonna get flamed for. I don't know, okay, yes. We stayed away from the Lens Library. Oh, damn. So learning Haskell and being comfortable with Haskell was difficult enough, you know, learn a whole new language, a whole new way of thinking. The Lens Library adds another layer of complexity on top of that with all these operators, you know, with God, squiggly, and it's like another new language. And a lot of the things that the Lens Library did, like accessing, deepening the structures, you felt like we, you know, we could, our structures went that deeply nested and we could get away with doing all the things that Lens did just by using simple features, the basic features like pattern matching, letter, auto-accessors, et cetera. So we chose to stay away from the Lens Library. All right, so let's see. So we've gathered our changes. We've convinced our undersiders that now we need to outrun our detractors. It was definitely a lot easier to develop in Haskell, like I mentioned before, because we were on a microservices architecture. So the old world and the new world can coexist side by side. You know, they can develop Java stuff, they can develop Haskell stuff, we'll talk over HTTP, that's why. So we started this whole thing in June of 2014 and then by February of 2016, about 50% of our services was in Java, 50% was in Haskell. And we did, in fact, make some FP-oriented hires. We hired two engineers with direct Haskell experience and we hired one more engineer with like general FP experience and they did convert, we included, two existing engineers. So as of this point, about maybe a third of the team was Java only, maybe the other two thirds was like Java and Haskell. Now our original intention was not necessarily to get to 100% Haskell, 50-50 was pretty good. So how did we get to 100%? Well, as a startup, there's one way to do that and it's ugly, it's the fire anyway. In February of 2016, our company very nearly failed and we pretty much laid everything off. We went down from 45 people to seven people and the only engineers that we kept on board were the ones who had the Haskell. Now this wasn't like, we didn't like engineer this layout to get rid of all the Java people. Company failed for various business reasons, I'll get into that. But we did find that our system was trending towards Haskell already and in fact our strongest engineers were our Haskell capable engineers. So it kind of just made sense to keep them. But all is not lost. Today, we're looking much better, okay, thank you. We're back up to about 23 total employees who are engineering team are the eight engineers of, all four of our back-end oriented engineers at Haskell. Using Kubernetes, we're actually no longer using Eureka, that's Eureka. We're in Kubernetes, about 100 or so pods, more than 100 pods of 15 microservices. Mostly Haskell, we do have one, we'll be at Rails app, we have our app that's doing our machine learning. There's some legacy services still sticking around, but we're working on those. So, how did it turn out as far as our original goal is of being a 10 exchange, meaning to be a 10 exchange, and using FP as a recruitment differential? As far as being a recruitment differential, I think it absolutely worked. We, over time, we've had five function FP-oriented hires and we have, in fact, had Kubernetes contact us, interested in working with us. We've never had that before as a JavaScript. And this last point is a little, like, snooty at the latest, but FP we found is generally a filter for good engineers because, well, FP is just better. And if you're an engineer who is interested in functional programming, you have the good sense to recognize that it's better, and you probably expend an effort to learn it yourself because most companies are only pulling up to get to learn out of the job.  So what about FP as a 10 exchange? Well, this improvement was not as clear-cut. We think that productivity is improved by 10x. We're not sure. Harder to measure. We think that feature development speed is about the same as Michael Snowman mentioned this morning at the keynote talk. Just talking about, like, MVP getting that first thing out there, development speed is about the same. Although, changes to existing code is a lot safer because of the strongly typed system in Haskell, though refactoring can be slower in some cases because, specifically in Haskell, you really have to get the structure and the scaffolding right around your code. And if you wanna make a certain change that requires changes with the scaffolding, you really have to sit there and think for a while to think about what you really need. And you have to get it right. Because in other languages, you can get the scaffolding kind of wrong, but you can still kind of fake it and it'll work, Haskell's not as good at that. Now, I think it's possible that we will see more improvement as our system grows larger and it becomes more complex. And well, because in what's a Java or Python goes languages, the system status gets worse as the system grows larger, it grows more complex because, well, now you have to rely on tests, let's say, instead of the compiler to tell you what things go wrong. So it's, well, I suspect that we will see more gains in productivity as compared to if we were using as the language like Java as our system grows larger. So some stability has greatly improved. Haskell services generally are very durable and we don't have logs that are littered with no point of exceptions anymore.  What are we doing here, right? No more of that. And developer satisfaction is quite high with Haskell. I mentioned that we do nowadays have a Ruby of Rails app and we introduce that into our ecosystem and all the people who worked on the first version of that, you tell them, you're like, no, the next project, please put it back at Haskell. So people really like Haskell and we're working on moving bits of that Ruby app of that Ruby to Haskell. But it's not always Rails and Firefox-wise, it's a compromise and there are drawbacks to using Haskell. Errors are rare but when they do happen they are more mysterious because you don't get statuaries in Haskell. When something goes wrong in Java, find it explodes but at least it tells you what line and what line, blah, blah, blah. In Haskell you don't really get that. So you have to put in a lot of logging or try to reduce the problem yourself locally in order to figure out what really went wrong. Haskell eliminates entire classes of errors due to its strong type system but it introduces a whole new, longer class of errors, memory management errors due to its lazy name. These kinds of errors are generally rare but it does happen and it does add a new thing that we have to think about.  So what are some takeaways that you can take home back to your companies in your quest, Sisyphus and Quest to get them to a doubtful function for them? Moving to Haskell isn't like any other work change like I mentioned before. Most of it's gonna be political. It's not a time question, it's a political issue and you have to do those three things. You have to gather champions, you have to convince your undersiders that you have to eventually outrun your detractors. It is definitely easier to do in a small company like any other kind of change, right? And I just wanna say that Haskell is definitely ready for production use. Some people might still have the idea that Haskell is just an academic language or no, there are some really great production level frameworks and libraries that can actually write restful web services in production and because that's what we have. And we've been running on this for three, four years. Some recent improvements in the Haskell ecosystem makes it like now is the best time to jump in and use Haskell. Like I mentioned before, there's a really good learning resource now, the Haskell program, most principles people. There is Stack, the build and dependency management system is really good and relatively recently there is a really cool web framework called Servant that we really, really like. So now do it now, now's the best time. And getting management support was instrumental. I mentioned before that convincing our CTO and CEO to allow us to make this change was actually relatively easy for us. It was harder to convince them as an engineering. But getting their support and management support was really instrumental.  You need to let them know and commit to having a critical mass of maintainers for this new thing that you do to assuage their fears. Some more takeaways. Our advice is to use Haskell features conservatively. You can actually get work done and realize all of the great features of type safety and all that good stuff in Haskell without using all of the super duper fancy language extension. Use your own judgment about which ones to use and which ones to not use. But just be cognizant that you are allowed to not use them.  Have an onboarding plan with resources and mentors that they're ready to onboard people because ramp up is gonna take longer. Being on a microservices architecture really made the transition a lot easier because the old and new world can exist side by side. What we found, and I'd love to hear some comments on this, we found that the functional programming population isn't quite big enough yet to support like a 50 plus size in a team of like just MP people. Our team right now is like eight people, at least four of them in the Haskell. And we are trying to recruit in New York City and we're finding that it's, well, the population's maybe not quite there yet, right? So be aware of that, if you have dreams, a world is out to a really large team. Official programming is great, but maybe you won't perceive it as like an order of magnitude change immediately. It's gonna take time to realize all the changes. So that was our story of how our small startup transitions in Haskell. For maybe some of you working in a much larger company and you wondering, well, how the hell am I gonna do that with a large company? I've proved this in here to give you some information, some tips on how to do that. So actually, I worked for, I did assistance at Intuit in San Diego. Intuit is a company in the US that does tax preparation software and accounts itself with. It was mostly like 99% of Java shop. Before I even got there, there was a, and it's a very large company. Before I even got there, there was one, a few developers who were really into functional programming and in order to sort of evangelize functional programming, they organized a study group around functional programming. So after work, off hours, you pick up, they did Scala, they did Clojure, you pick a book every week, you do a chapter, and in this way, they gathered their champions and convinced someone to sign it. And they successfully did that. They leveraged that study group into like could join the management to let them use Scala for one of their systems on a team. So they went from only, only Java, so now one team is developing a few subsystems in Scala. And eventually they also got hooked up with the local leader, the San Diego functional programmers leader. And they also got Intuit to sponsor the leader. They provide food, they provide the menu. And Intuit, the company, sees it as a recruitment tool as well to evangelize their brain. So that is how you can really get your company on board, especially if it's a larger company with functional programming. And that is our story. Here's my contact info. Objectively, we are hiring in New York City. We're hiring F.P. engineers. Please come check us out. Thank you. Any questions? I think we might put a bunch of questions. Hi, so did you, when you were talking about the effects that this language potentially could have on productivity bugs and everything like that, to what degree of rigor or systemization did you go to in order to track that? Did you have any specific metrics you went over? How did you judge whether or not productivity was improving or whether your bugs were improving? What kind of usability metrics did you use or things like that? Unfortunately, zero. It's like feeling, man. Well, I mean, so one really janky metric thing of that was just the compared feature shipping time. And that's just one measure. And we found it out, it was about the same. Unfortunately, we don't have that rigorous data. Two questions. Yeah, first one is you talked about the null point of exceptions in the logs. So when folks started using Haskell, so Haskell too has exceptions and even use types for indicating errors.  Did you seal off exceptions coming out of the Haskell? Could it be wrote or how did that go? No, we did not. Well, it's because Haskell's compiler is so strong. Like most of the things that would be exceptions, especially null point of exceptions in Java are caught in compile time. Yeah, I meant things like we are trying to do a file that doesn't exist, it's through an exception. That's certain, yeah. Well, I mean, if doing a file IO, if something goes wrong there, then yes, there will be exception and you will have to handle it, catch it and handle it like you would do it in the other language. Okay, so the exception hand. My second question was with respect to Stack and Cabin. So what does Stack give on top of like what's, why should someone use Stack instead of taking in Cabin? You should totally ask Michael Snowden in this question if you would tell me. But so from what I, and I'm not an expert in this, but from what I know, when there was only Cabal back in the days of war, there's such a thing called Cabal help where you have in your file, your Cabal config file, you've said that, oh, my project depends on such and such, dependency of these versions or whatever, but builds in Cabal were not deterministic. So sometimes you, so because you specify a range, these are the ranges of versions I want for this library. One build Cabal might give you one version in that range, another build it might give you another version. The problem with that is the other libraries that you say your system depends on needs might depend on that library that's changing. So now those other dependencies don't compile and now you're like, oh God, what happened, why are they compiled? This is Cabal help. With Stack, you specify specific versions of libraries that you use and Stack provides a list, a comprehensive list, very large list of a bunch of commonly used open source libraries out there that you might use. And these are very large lists and they maintain this themselves and they guarantee you that in version, in one particular list, all of these libraries work well together and they will compile and they won't work. And then in a few days, and they update this weekly every couple of days, a new version will come out, here's some updated version of these libraries and we guarantee all of them work well together. So that's what Stack is doing. Yeah, couple of questions. One, you mentioned scaffolding and you said sometimes you have to spend a lot of time at figuring it out and you have to get it right. Can you give us a little bit more sense in terms of what you mean by scaffolding? Is it the type classes you use? Is it a much bigger framework that you want? What is it? Yes, exactly. So by scaffolding, I'm talking about the type classes, I'm talking about monad transformer stacks, things like that. So those things can get this right. Okay, my second question is you talked a little bit about productivity and you having noticed some productivity improvement but not 10x. Is there a sense you developed at any stage that in a different direction that you would need fewer or more people because you were working in Haskell as opposed to working in Java? So you're asking if you were engineers to do the things that we do? Right. I mean, because that's a different measure but it helps differently because if you get fewer people your communication overheads kind of come down substantially and if that's one of the benefits that you are seeing then that benefit is actually much bigger than it seems because then it really speeds up things even though you're having a few people and the time taken is the same it still probably has a different character to it. That's interesting. I think I suspect you're right because our team is pretty small but we've got a lot of cool stuff, a lot of cool big things. So you're probably right although we are continually hiring so it's not like we are choosing not to hire more people because we think it's good enough now as a startup you're growing, you're always hiring more people. So from that sense we're kind of blind to that kind of a benefit because we're hiring anyway. But I suspect you're right, we need fewer people to do more. Hey, did you end up writing the same code that you had earlier written in Java? In Haskell did you end up re-implementing or because of your downsize or whatever did you pivot and end up writing a new product completely? During that transition I probably like 90% of the Haskell-Coby world was just new but maybe 10, 20% was replaced at the same time. Okay, that's a smaller set but any comparison between the same code written in Java versus the same code written in Haskell? I mean, yes, there is a comparison and the re-implementing Haskell-Coby is much better. It is generally shorter, more terse and is generally more understandable because of the strong type. And just personally I found that after I started programming in Haskell and I returned to programming in something that I thought on Java, I feel like programming in Haskell has made me a better developer. Now I see more of the perhaps the words of these other languages and it gets me angry. And I try to bring the same good practices from Haskell into those languages we never have to program. Yeah, another question. You mentioned the hiring problem a little bit and I've had some experience with this difficulty of hiring for these kind of positions. Do you have a, what is your methodology that you're using to find good people? Because I found even within FP, maybe FP is a good filter initially but we're finding it even more difficult. We have to have an even stronger filter. So do you have any thoughts on how to improve the predictive power of your hiring process for success without doing something illegal? Yes, so it's difficult to find people who already have a big experience, even more difficult than my people who have like specifically Haskell experience. What we found that was we generally have to hire smart people who are open to learning new things, especially if they should work. I mean, we're still working out the case in our hiring process. One specific thing that we like to do is we like to give our candidates a small take home project to do. Instead of asking them to come into our office and like wipe out something like on the spot because I, okay, this is me waiting to know. I think those kinds of interviews because that when during your regular job, do you ever, there's somebody walking in the room and says, write this code now. And you have like an hour to do it. No, the way you write stuff is you sit, you think about it and you plan it out. So I think giving our candidates take home project is the best way to do that. So how do you evaluate how smart, quote unquote, somebody is in a legal fashion? Well, we take a look at their choices when completing that assignment. We leave a lot of it up to the engineer. They can choose a language or a framework who make all these different choices and we judge them, we judge them whole, their choices. And we're judgmental about their justifications of their choices. Like it's fine if you make a choice that we wouldn't have made, but tell us about it. Tell us what you're thinking. And also we bring them home for the interview and we ask them to maybe fix some bugs that we found, see how they do there and just kind of talk to them. How do you find smart people? How do you find that? I don't know, well actually, one thing that I found is a good indicator is can this person explain something to you? Like take a difficult concept, some really large project that they've worked on and explain it to me in a concise way such that I can understand it. I think that is the question. Yeah. Hi, functional programming is great, but I have a question. So how much language choice matters for building great software? Because people have built great softwares using very basic language such as C and C++. So how does it matter if I choose a C++ or modern C-sharp or Java? What's this functional programming? Wow, that's a question you would ask to this entire conference. I think actually it doesn't, right? I mean, let's take this to the extreme. If you were writing some kind of web services service, would you do it in an assembly? That would be crazy, right? Your choice of tool does matter. And yes, there has been great software written, well, for ages, using various languages. But you have to ask yourself, was that software great in spite of the language? And how painful was it to develop that software? Like how much effort did you have to put in testing and refactoring, fixing things because you didn't have a strong type system? Like how much more productive did you have to use that? You mentioned that you wrote your own Netflix library in Haskell. How often do you still write your own libraries and how much time you spend contributing to upstream open source library because the state is not that good or the state of the system is really nice nowadays? Well, I mean, I guess the question would be for some kind of third party VPI if they already do provide clients like all of this mobile language, how often would you have to write it in? Well, nowadays we're not using that many third party APIs that provide clients in the first place, so we'd have to write in one of the first place. So it's hard to say, even though we're using Java. I have one last question here. So you said that ramping up is a bit difficult. So do you think introducing Scala for Java developers eases out that learning curve or is it just a mean to convince the business to move to FB? Well, I'm sorry, are you asking is in order to solve the ramp up problem, should we use Scala and Haskell or are you saying? Basically for the transition from Java to FB. So like just the direct transition from Java to Haskell or like you said that one team got Scala for it. So would Scala be a better option? From a technical point of view, Haskell is superior. Yeah, go Haskell. I think it's better than Scala. However, as a political option, if you are at a big company that's difficult to change and you're on the JPL already, it might be too big of a task to move to something like Haskell. And if you wanna do something like FB, you'll have to do Scala. Yes, it's more of a business decision. Then the technical one. Thank you. Thank you, I think that's all the time we have for questions. Thank you so much for the talk, Michael. This is very, very interesting.