 Good morning, everyone, and welcome to Functional Con for 2022. We have with us today Luca Mugnani. He's going to talk on the topic familiarity or guarantees functional programming for the front end. So Luca, over to you. So thank you, Vikram. Let me share my screen. Okay. Hello, everybody. My name is Luca Mugnani. I'm a software engineer at Rakuten. Today I'm going to talk about how we transition from regular like JavaScript object oriented to functional programming for some of our front end project. So the story started three years ago. The idea was to build a new registration and authentication system that provides a consistent experience without friction to all Rakuten users regardless of the service they're using. We also wanted this system to be simple to be added to existing website, because we have several hundred services and each service built their own interface independently. We also wanted to allow a certain degree of customization. So in the past, we had some bad experience in maintaining projects when they reach certain size, fixing something in one place with break the code in other places making the experience of debugging or adding a new features low and stressful for developers. But as John Carmag explain the difficulty in understanding all the possible state of a system is the cause of a large quantity of flow. And it is also the reason why support center always has to reboot the system right. We want this new system to be reliable, simple to debug and simple to be extended the new feature. So, during our preliminary investigation about the front end stack, we came across Elm, which is a functional language that complied to JavaScript. Elm was matching all our requirements so we decided to give it a try and build a proof of concept with it. The first experience was very positive as we were able to build a nice demo in a short time even with limited knowledge of the language. What we liked about Elm were mainly the guarantees, no runtime errors, 100% immutable data, 100% pure function, and that all types are correct. But at the same time type annotation are completely optional. So, Elm guarantees that there will be no surprises when upgrading dependency, thanks to the enforced semantic versioning system. Those characteristics also protect the project from the typical issues of MPM, they know the packaging system. Another aspect that was important for us was that Elm combined together a lot of different tools that otherwise need to be selected individually. It helps to cut short endless discussion about which tool is the best and makes all Elm project resembling each other. So it becomes easier to move from one project to another. Also makes simple to set up the development environment. Also, Elm could target other languages other than JavaScript. For example, experimental effort to target the web assembly. And this seems like a nice feature as we may able to start using web assembly or other languages without much effort in the future. Another thing that we liked was the Elm UI library. It is a semantic layer above CSS that lets you write complex layouts in a very intuitive way. For example, to center something horizontally and vertically inside an HTML element, we just need to specify center X and center Y. If you have to do the same in CSS, I would probably need to Google it because I just don't remember it. This is probably what I personally like the most about functional programming. The order of instruction doesn't matter. With an imperative language, if you use a variable that is not defined like B in the second row, that is only defined in the third row, you get an error. The exact same code written in a functional language just works regardless of the order of instructions. These are several nice consequences. For example, you can move your code around without problems that is very useful during refactoring. Another thing that I would like to highlight is the stuff that is not in Elm. For example, the any type that basically shut off the type system in TypeScript at the vulnerabilities does not exist in Elm. Noon and undefined also do not exist. It is same for try catch blocks because errors are handled directly by the time system and so on. So this makes Elm a small and simple language. Also related to the compiler in Elm, there are no escape hatches. This means that guarantees do not depend on the discipline of the team members. Moreover, the compiler's friendly error and the concept that if it compiles it works, give the impression that the compiler itself is like an assistant that is looking over your shoulder and guiding you while coding. This is an example of an error message in Elm. By mistake, we pass the number to a function that instead the aspect of string. The resulting error is very precise. It highlights the problem, the exact position of the problem, and it gives also in green a possible resolution. Especially when moving from a dynamic language like JavaScript to a statically typed language, it may feel that types are slowing you down. Those friend's error messages help to mitigate this issue. Also, we evaluated the differences between TypeScript and Elm as there were some opinion that TypeScript would have been good enough for what we had in mind. Recently actually I wrote an article about this investigation. You can find it in dev.io. In short, the main difference is that the TypeScript cannot bring the same guarantees that Elm does. TypeScript objective was not to be sound since its inception. And this decision was probably made this to allow TypeScript to remain a superset of JavaScript. Being sound means that the type checker can detect that compile time every single error that may happen at the runtime. Elm instead is based on the sound the Hindley Milner type system. The other difference is that the TypeScript is familiar for developers that already know JavaScript, while Elm is not as it used the ML syntax. So, at the end of our investigation three years ago, we were faced with this decision. Do we take the red pill and move away from JavaScript embracing a new language and a new paradigm? Or do we take the blue pill and remain in a world familiar to JavaScript choosing one of the mainstream frameworks? In short, do we choose guarantees or familiarity? Well, somehow we didn't agree with the idea that if something is popular, it must be good. And we were excited about the innovative and disruptive ideas of Elm. So we took the red pill. Fast forward three years and about our new registration authentication service. We had around 30 releases, one every month and a half with around 15 feature implemented in each release. We are very satisfied with the level of maintainability that was our main initial goal. Our code base now has 70,000 lines of Elm code and the 2000 lines of TypeScript code. We had no blockers and the basically zero issue related to the Elm code, but a few issues related to the TypeScript code, which is around 3% of our code base. So Elm has been proven to be a resilient technology. Moreover, we successfully hired and trained several developers. We didn't use Elm only for the registration and authentication system, but for other project as well, from static pages to internal projects, open source project and so on. Some of those projects are generated server-side so they also work without JavaScript. Hiring was one of the concern that we had at the beginning, but we also heard that the companies that adopted Elm were not having any issue with it, but quite the opposite. After three years, we can confirm this. We get application from passionate engineers that want to join our team just because we use Elm. And in any case, Elm is simple to learn and safe to write. It also uses as a training language for children and teenagers by some school. So onboarding new developers is a smooth process and they're usually able to learn Elm and working production in a matter of weeks. Regarding instead what happened to the language in those last three years, the Elm ecosystem got better and larger with new tools and new library. Elm also inspired other system to a different extent, for example, with UI, Redar, Scala and Rust. At the moment, there are still no valid alternative to Elm with similar guarantees. There are some alternatives like a pure script or re-script with different set of guarantees. And as Richard Feldman and I said he put it this morning, of course with different ergonomics. We noted that all of Elm is recommended as a gateway drag that lead to functional programming thanks to its design principle of being a beginner friend. A recent nice addition to the Elm ecosystem is Elm review. This is a powerful static code analyzer that not only warn you about issues in your code, but it goes there and fix those for you. We also remove code that is not necessary. So what you see here, it's a typical reaction after running Elm review for the first time on a large code base. It is like having an automatic pull request reviewers. So we added in all our pipelines. The Elm ecosystem is quite comprehensive nowadays. There are, these are some of the most interesting and popular libraries. Stuff like M Spa to create single page application, Elm chart for nice visualization of data, Elm pages for static generated website and so on. A small curiosity, this chart is from the state of JavaScript, an online survey that run every year about the JavaScript ecosystem. It is far from being scientific or reflecting the real state of JavaScript ecosystem, but it's still fun to check the results. These are the most dreamed feature of JavaScript. And I realized that at least the five of them are implemented already in Elm. Other people actually argued that they that all of them are in a way or another already supported by Elm. So it is nice to see that ideas from the functional world are becoming desired feature in a mainstream language. I'm looking forward for the time when, you know, all of these are implemented and we can write functional co-directed in JavaScript. And at that point Elm will be like the new jQuery. So at work we are running regular internal workshop right now. And as a consequence we created some training material that we made available to everybody. For example, a demo built for our workshop. It is an e-commerce application made of only 2,500 lines of Elm code and it collects our best practices. It can be used as a learning tool or as a boost trap for new Elm application. This is a chat sheet that contain everything that you need to know about Elm including advanced stuff. And it was nice to realize that it all fit easily in one page. After all this time spent using or maintaining and teaching Elm, we came out with some internal best practice. And be explicit is probably the most important. We spend more time reading code than writing it. So we don't want our colleagues having this reaction when they read our code or even worse, our self when we read our own code months later. We try to follow the manifesto right junior code. In our team we don't have any member with the formal education in functional programming or category theory. So we all enjoy reading like simple and idiomatic code. Following I will give you some example. If you don't know Elm or the ML syntax. Those example may not be clear for you. But I hope you can get some idea out of them. Some of the following points may be a big controversy about bear with me about idiomatic Elm. We prefer among these two example the one on the right with the case of structure. It has less stuff inside in green color than it to be remember compared to the other one in yellow that has more stuff in it. We avoid point freestyle as it is hiding some information. I'm cheating a bit here because if you are the type of notation it would be more readable but still just to make the point. Also in this case, using pipe operator instead of the function composition operator, it makes the code more explicit. So the overall experience have been extremely positive. We were able to implement many feature quickly with basically zero ratio. But I want to briefly talk about another aspect that for us as a developer is equally important if not more important the developer experience. This is an interesting Twitter that I have seen recently. The major of a language quality is how much trouble can I get myself in. Let's try to evaluate a language from this perspective. Here I listed some question that we usually ask ourselves when writing the code in a dynamic imperative language. Those are important question that we need to answer carefully if you want to write good quality code. For example, can I move this piece of code. Can I put this in a try catch block. Can I trust this library. Should I check if this method is fixed before using it, or can I remove this function is there like any edge case that I forgot to consider and so on. It is a lot of stuff to think about and to be worried about when moving to a purely functional language. These questions are automatically answered by the system. For example, can I move this piece of code. Sure. Should I wrap this in a try catch block. No, the concept doesn't even exist. Can I trust this library. Yes, because libraries cannot have their own side effects. Should I check if this method exists. If the code compiles it works. Can I remove this function. Again, if it compiles without it. Yeah, you can remove it. Is there any edge case that I forgot to consider. No, because the compiler really forced you to consider them all, and so on. When using a purely functional language those questions all disappear. And this give us a piece of mine and a lot of extra time to care about what we value the most like implementing important feature, or caring about your ex usability and so on. This is what we call it a stress free developer experience. If you're interested in this concept to have a look at this nice presentation pragmatic functional programming by Richard Feldman he does a much better job in explaining then than me. About the future. So we plan to expand the use of Elm and reduce the use of other languages whenever possible as we would like to have all our code to be covered by the Elm guarantees. And so we will keep contributing to the growth of the Elm ecosystem and follow new progress down to the compiler and the core libraries. The same time we will keep our eyes on promising emerging technology, at least they hear some of them like you ran respect their rock. Maybe rock is more on the back end. Anyway, etc. If you would like to evaluate Elm as a possible option for a future front end project here is some tip for you. Watch some video or other material made by Evan Chaplicki the creator of the language, Richard Feldman mentioned earlier, or others there is a lot of my stuff out there. Join the very friendly Elm community is luck you can find it just googling and ends luck. Ask someone that already use it or build some simple application with it. Also tomorrow there will be another talk about Elm at this conference by Graham Dixon talking about real way oriented programming. So while we are wrapping this up. What are the takeaway that I would like you all to leave with. So first of all, let's appreciate how like we are, as we are living in a moment where it's possible to do from 10 with the pure functional language. And second, let's challenge the front end status quo prioritizing the developer experience and makes our life better. So this is all thank you very much. So that was the one position. We have some questions on the Q&A tab. You can look at it and then probably answer them. Yeah, so why the first question is why is TypeScript still require in your code base. So there are certain things that they need to be done outside Elm, because certain certain communication with certain API of the browser for example need to be done outside for example if you want to use the local storage. This is done outside them outside Elm. This is one reason local storage will be four lines of JavaScript code so that is not the big part. The bigger part that we have some library that we need to use in JavaScript and we never took the time to convert in Elm. So this is the largest part of our TypeScript code. And second question. What language is your backend written in do you try to get guarantees over the API from an interface for example by sharing the data types used by the backend and the front end. Okay, so we tend to have a lot of Java in our company and we are trying now slowly to transition to front to functional programming also there but it's a it's very hard for social reason also and cultural reason I'm not going to talk in detail. So but what we were able to do is at least to use Kotlin so our backend now is in Kotlin and the way we do this communication is we use a swagger. And so the backend is providing a swagger file to us as a front end. And with that we generate automatically there is a tool that it take the swagger file that describe all the API and the generate Elm code. The interesting things is that the back end even though they maintain the swagger file, they don't use it to generate the Elm code. So many times, the communication doesn't work because they don't reflect the modification into their own code so they use the front end to debug basically the backend. Is Elm able to position popovers based on the mouse click coordinate? Yes it does. This can be done completely in Elm there are some function that will tell you the coordinate of any element in the DOM so you can use those to do this kind of trick. Elm have a native rich text editor widget component now. There is I believe there is there are several actually rich text editor. I don't know how much they are complete. We don't use them so I cannot go more than I cannot answer more than this. I know there are some. The other option would be to instead use like a third library third party library and inject into Elm as a web component. JavaScript has a lot of library and a huge active community. How do you feel about the adoption of Elm by a larger community in the year to come. So yeah, this is I don't know the answer. I would say Elm will consider the goal of Elm is not to become mainstream. I don't think I will ever be mainstream. I think Elm is good like for company who like this idea of the functional approach is very good and there are no problems with it. But for the for the mainstream stuff maybe it's more about influencing the direction of JavaScript rather than, you know, becoming a mainstream language. And we trust pure code and not to misbehave for example any possibility of runtime error such as divided by zero environment issue, etc. And if so how to address them in pure code. I would say. Yes, we can trust. Especially especially for normal application like like what we do like a web single page application. We never have issues. Still, for example, if you divide by zero, you will get an error in Elm. What you can do, there is a library but it was one line of code what you can do is that you can create a safe division operator that instead of returning a number return maybe a and you can also avoid that problem about divided by zero so you have this wrapper and then you check if it's a zero then return nothing and if there is not zero you that you do the division but we don't even do that it's a in general we don't have issue. So I guess we can trust. How do you handle an unpackage that is not compatible with a specific Elm version. Elm calendar one zero not compatible with Elm 19 one. Yeah, so in the zero nineteen and zero nineteen one I think there was no problem there was no need to update the dependency. There was a need to update dependency between zero eighteen to zero nineteen. So, first of all, Elm, maybe, I don't know if you know but it's, it's very slow in updating so recently every release happening like every two years. And when that happened for example from zero eighteen to zero nineteen all the library need to be updated so usually you wait one or two months and all the major library get updated and then you also move your code into the new release. If a library don't get updated. Maybe you can you can just take it and update yourself usually the update is not it's not a big issue. Does it support the hybrid mobile up implementation. I'm not sure what the hybrid mobile up implementation is. There is no specific tool to to create a native mobile application. You can easily build the PWA progressive web application, or you can have your Elm application running in a web view for example in an app. This is what we do on a regular base. How do you feel about the future of Elm. Oh, I feel very good. It's still like, you know, not so popular, but it's the communities is really like active. There are a lot of movement, especially in the packaging and external library modules and so on. And the the creator of Elm it's it's working on an Elm regularly and they we know actually what is working right now. He give us some idea what is working on the things is he he's not so active on the social media so if you don't know what's going on in Elm you may feel like is anybody like really working on the core of the of the of the language. Also keep in mind that the language as itself is basically done the author itself he keeps saying, if you like what you see is what you will get for the next several years so don't it's so if you if you want to use Elm don't expect to have like a new version like every month or every six months. As I told you the last release was now more than two years ago. And the large modification was more than four years ago I think of five years or six years ago so it's very stable language so you have to enjoy the language itself. Not the fact that it's there's no like a list of new feature in the backlog that we are waiting to be implemented that the language is basically done. Okay, look, I think we have sort of reached our time. So, thank you very much for your dog.