 have used Beam. Awesome. How many of you have coded in, how many of you have coded in functional programming using functional programming techniques? Awesome. Haskell? Put Haskell to production? Awesome. See, I was, I was actually wondering, like it's a one-year-old story how we built Beam. I wanted to actually share the story and what it transformed us as a payments company into a company who actually is inspired to build creation tools right now. A quick background about me, I have a lot of experience actually. Like I, people think I don't look like that but like I've been working for 15 years and pretty much an enterprise-y guy from the old-timer, old times. Started in Amazon where I built like large-scale systems which can actually support, my sequel 4.0. So most of you wouldn't have touched something like that. Like old systems where consistency hashing where actually in papers we implemented it and have been in payments from that time looking at how to build a system of really, really large-scale for 100,000 transactions, been a Java programmer then went into Clojure at some point during my career at Bang Bazaar. After that, when I started JustPay, JustPay is a company running for the last five years and we started the company saying let's actually solve payments for India and create a one-click experience without a hardware-less one-click experience. That's how we started. So along the way, when we were maybe three and a half four years old, Beam came and in this talk I'm going to talk about how it kind of transformed our thinking and completely pushed us 10x better in how we do engineering. So the story behind Beam is we have been into UPI even before Beam. So as I said, we are super excited about one-click hardware-less payments for several years and when we first looked at the UPI spec, it was amazed. We were amazed at what we wanted was there in it. In fact, we were trying to work with the banks couple of years ago trying to build something like UPI but you know it's not at all easy. You need to have a socialist and to build something like that. You can't be a company and kind of create a network. So when UPI came and we said we wanted to make this work and this is like six months to a year before Beam itself, we were into UPI because if you really look at UPI, it doesn't have OTP. We were always trying to eliminate OTP. Though OTP powers our business or other side of business, you might have seen just pay auto-reading OTP in most of the apps that you use if you use Android, right? But we wanted to in fact eliminate OTP and just create a one-click experience and UPI provided a way towards it. Second is when I entered into the banks, I saw there are too many layers. Again, when I started the payments company, I thought 10 people are enough to solve payments in India. The payments is just moving money between one account to another and doing authentication. What's the big deal about it, right? But when you entered in, there's so many people out there and like nobody is trying to move outside, trying to build their old mainframes, et cetera, et cetera. Some of you who have been into enterprises would wonder like there are all these oligopoly networks and the real problem is simple. You can just, it's just there out there but like there is a lead wall, steel wall, all kinds of walls. They just not let you go into that other side. But somehow UPI found a crack in the wall and like just entered in and said like core banking to core banking, just move the money, right? So we saw that if UPI is done well, it is really going to make payments simple. So for me, I also think payments has to be free though I run a payments company. So all this felt like, yeah, this is the right direction. We have to support it, right? So when beam came in, we were, well, we have to jump into it. We have to jump into it and make this work. So even when beam came, maybe maybe one more thing. So even before beam, we have been thinking about while we entered into banking, looking at all the how much we have to talk, et cetera, et cetera and banking, how enterprising it is in the other side, unless we are super good in technology, I don't think we'll have fun working the banks because there is so many other things that we have to do to close a deal, et cetera, right? So we have been thinking about something called specification to application. Like this is how many of you know Clojure? Clojure or Lisp? So I've been thinking about when we make these apps, we have to declaratively make it. And is there a way in which you can make an app in a single page? So this is maybe an email that I was taking my Emax and just writing like I wanted DSL like this and I am sending to my team in 2016, just a little bit before the time when we got beam as a requirement, where I'm saying just like how you write a C program in which you just start saying like main get us, write something to the file, read something from Redis, you can just declare it, you can actually write line by line without callbacks, et cetera. But in the other side when we were using Node.js, it's a mess, right? So I wanted something like that for app development, something like saying like just show the login screen and the return value of the login screen is the login, let's say the username and password, which I can then call an API. You get what I'm saying like the user's journey as a thread of execution. So this is also something that has been kind of going on in our company, right? So then the beam happens when beam came in, like, first it came in, in fact, it didn't come as beam to us, it came to us as, okay, there are lots of banks who are not able to build apps, lots of small banks and NPC came to us and said like, okay, you guys have been doing apps for the banks, you are in the process of working, can you create a template app which is like a reference implementation for the small banks? Well, small banks was not like the thing that we can solve, but we thought, yeah, we are going to do engineering in a better way. Let's show it as an example, even with small banks, it's okay, it might work out, might not work out. Let's do our best and like within a week, we are, this is a little bit before the three weeks. Within a week, we are just like prototyping and going and showing saying like, this is the thing that we can do. Like this is, I want to do even for the small banks, I want to do something which is not there in the world. Like we have our own type of design called, we used to call it, not material design, I always wanted design also to be unique that in our company, we want to, we used to call it solid design, we used to be inspired by cars and bikes, etc. Like how, how the controls of physical vehicles, etc. We wanted to give that kind of feel, we used to call it solid design and we have all this and we made it and like people were impressed and somehow after a few days, it comes to us and saying, in our saying demonetization is happening, maybe there are requests where there is a possibility that this can be launched at countrywide scale as an app launched by NPCI. We are wondering, is it even possible? UPI doesn't have that kind of the philosophy of UPI's PSPs are run by banks, etc. But when we thought through it, yes, why not? And so, well, and there are lots of unknown etc. But we also didn't know that, yeah, we had to do the Star Knight and it's three weeks, I just committed, yes. I said, yes, yeah, we can do it. I thought, like, maybe we should mash it together. See, I'm a little bit of an optimist. Sometimes I thought, like, maybe in one week itself, let's all come together, work in three shifts, move the entire company into this and like get something done, right? Because we had a lot of things already in our minds where we wanted to go. We had our own 35kb react native. I wanted that to be put in use because we can do rapid prototyping, which is actually close to implementation in the UI side using that. I thought, like, yeah, this is an opportunity, let's just say, yes, and like, I want to get all the team together and do it in one week. Then more and more requirements start coming and I'm getting like, okay, we also have to do Star 99 hash. Then we wonder, what is the Star 99 hash? How does it work? How does USSD work? Right? And you have to integrate with all the Telcom operators. And there is something called SMPP protocol. What is that protocol? So we committed and like, then it's a big challenge and we are in a way in a difficult situation, right? And it has to support all languages. It has to support accessibility because this is going to be a government app and we can't, people are going to complain and from the day one, it has to have high reliability and scale. And then there are like teams in Chennai, there are teams in Mumbai, infrastructure has to be in a physical infrastructure in some place. We are used to the cloud and we have to go back to, again, to the bare metal infrastructure and procurement of hardware has to, so many other things have just came to us and we have said as now we have to somehow execute. So it was not possible to do this without doing something radical. So we were forced to just put our all our ideal ideas. Like saying like, okay, let's put our functional programming monads which we were experimenting with into it. Let's put somehow our non-programmers should code. Like we just said our lawyer also has to in two days learn JavaScript programming and they have to take care of multilingual. So pms and our lawyers even have to code and we have to get all our customers and we have to design with the customers in place. All this communication over it and all is going to kill us. So we have to collaboratively create, right? So I think the two weapons that we had was at that time was functional programming and this collaborative creation. We tested it a little bit. We even internally in our company we use, we in fact use these collaborative. One is if till when we were a one-floor company every time we are like calling everybody and like everybody we call it like we are running the company like playing jazz music. Like we are in the flow and we are actually creating and unbelievable things the outcomes happen. But how do I bring that to enough teams that I don't know about and who is fragmented? Well that is something that is collaborative creation. We wanted to do something creative about it and definitely functional programming. Functional programming I think a lot of you guys would know it's the purity is a big, big thing in functional programming. So you can actually parallelize. You can create composable combinators and you can combine them if you use the right functional programming technique. So we put all our other libraries that we were building which are functional programming immediately into practice into a very serious app. Well I think it's a lot of detail here. So one of the core things is we just jumped in and we started building the we planned it out and we said it's not like prototype versus implementation. We have to do prototypes which is like implementation. So we started given a lot of unknowns which are out there. Things which we know we have to be 10x better. So we went and there are two things that we were there. I am not going to actually get into the collaboration what we did because that's another thing altogether. I'm going to focus on the engineering part in this discussion. If you guys are interested you can talk to me after the talk about some of our thoughts about how collaborative creation can happen. So if we have to somehow attack this problem and solve it. The known things we had to wherever we think there is a 10x possibility we were actually like kind of our vision was that we were kind of thinking engineering should go like this and all. Now we are saying engineering should be like this from day tomorrow or now. So we just put all our bets into practice immediately. Which is we had written a monad. How many of you know monads have heard about monads. Yeah. See monads are nothing but computation builders. If you look at Node.js right now you have async await etc but I think when we went to Node.js writing back end was a big big problem like even compared to Java it's pretty bad though you have functions as first class citizens etc. So we to build something reliable in the back end we created our own JavaScript monad though we if you know Haskell there is something called do notation we don't have it that's a problem there but like we had a library internally in our company which we have been using for few products. So we wanted to fully use a monadic way of writing the back end for beam. The second thing is we had a way of writing the front end which is like the L architecture we have been experimenting where you how many of you heard about L. Yeah. So we had a JavaScript way our own way of our react native library plus L architecture and we have been experimenting with it we in that hot reloading everything works with our own library and we can do rapid prototyping the good thing there is in our library a fresher android developer will be able to immediately be productive in react native they can't be because react native has its own markup language which you have to learn here we just took the android's XML syntax and just you can write that in JavaScript so we had a bunch of interns in our company we put everybody into code and immediately we start making the screens into code and in two three days we are like having like an app working like in the front end with dummy dummy data right so that that I think and and you know like all these screens can be parallelized then all apis when you write it in functional mode we are having lots of people who are writing all this parallely and we are people some people are coordinating assembling them together everything is falling in place and wherever unknowns are there we are mocking out the data and like kind of in within a week we have like a like a system in place because even this three weeks there is always this unknown like can it really be done should we tell the prime see I also don't know whether prime minister is going to launch I didn't know from till the last moment right like will this happen or not is but we thought well this whatever it is like compared to where we are it is like a great thing if it works or not whether it launches or not not a problem let's do it let's give our best so whatever the way we did like a lot of people like um we like after a week some IAS officers big big people are starting to talk to us why don't you do this feature why don't you do that feature like that right and the because of because of this rapid prototyping of the UI that we did within a week what happened is like lots of people just collaborative creation started evolving like people who from various places who are actually big stakeholders in this started coming and they will call our team and they will ask directly like a like a big person will just call at 11 o'clock to a person in my team and can you add this to the UI and just do it and show me they will just do it and done that feature is done and in fact we also did for the ussd how many of you know ussd what is ussd that yeah so we in a within a day of coming up with this requirement we created a small prototyping tool first we didn't go into ussd we just said okay let's show like a Nokia phone and like and we again created a monadic DSL for the conversational DSL very quickly we did something where because ussd is it's about questions and answers like you throw a question to the user user answers question answer question answer and in fact we made the code so simple and we started sharing okay this is how you write that code and this is how the UI looks so a lot of people then get enabled oh yeah what the the person who gives the requirements knows how to give that requirement to us they are not going to give it in some format which is not understanding which we just made it as close as possible to implementation right so that we created our prototyping tool that is our presto UI this is our own other ussd prototyping tool this is we extensively used for architecture collaboration etc all these collaborative canvas tools where multiple people are all all the mouses are moving and people are commenting and we are discussing architecture how to solve our backend problems etc and yeah so this is how the backend looks like with our with our monad it doesn't have the do notation so it has its own limitations which if you had written in haskell or pure script it would be much better but we were able to live with the limitation we had to use a state because of that just to move things between the pure functions these are all like chaining pure functions together right for example api initially it has to limit the rate maybe it is fetching something from redis if redis doesn't have it has to fetch from the db and it is cleaning up the response and any error happens anywhere we will be able to catch it like that is a big thing in node js it's not possible somewhere some error happens some callback will just ignore it and and it could end up being a big serious bug and we wanted reliability to be in control because anything happens we have to be able to catch right monads give you that and the entire thing is javascript this is also something that we were we had to take that approach this used to be like should we put our react native library to big production use or should we start small we had to put it to big production use so that is all javascript back end is like again javascript it's like there were discussions like oh this is high enterprisey stuff should we write it in java no way you can do it in java within this time so all that good stuff that we had to do because of this time crunch just got approved right which was great functional programming will people be able to maintain it this is how we can do it so people we will teach functional programming to your people so everything now we are teaching Haskell to people in enterprises you know because like this is how we because because of these constraints time constraints we just went in like things which go in a bullock cart went in a flight and like when you go in a flight you just can't ask questions and all just done like all the good things we just go went and put it there put it out there and like now people are okay oh it's all working the what is this whole functional programming about now in banking circles and all people talk about it you know we are going and in fact when I go to the bank and say we are already using functions what is this then I we have to again maybe we have to get a new term for it but but it's it's actually I'm quite excited these days that we are bringing functional programming the right paradigm we feel like into the hardest place and we have made it work through this um so yeah like like as I said before our pms were coding and our lawyer is the one who made sure she is diligent about every detail and we just taught her javascript and like she manages certain files took care of all languages coordinated and let her how to build it and like yeah change it and build it change it and build it and non-code as are able to code now in in fact in my office even admin is thought qap team is already learning has script that is now my office admin why not so that is that is the kind of confidence we got out of all this um so so that's how the beam happened see there are lots of other stories uh how we did all our shift pre-shifts and all that it's not uh uh it could have burnt us out it's like it's three weeks and so many unknowns and um uh it was it was even with all this see here it's all javascript right it's not like like there are lots of issues also that we faced um so from the beam uh experience these we were the the good thing about that is like we were able to see the entire picture i was able to see like in three weeks if we if it can be made why not in one week with because in three weeks we are able to make it with so much of inefficiencies of javascript and um certain types of things which are not unified etc etc right so we took that uh specification to application as something that we should go ahead and do it for the world like we have we have we have had this experience and uh see meanwhile other other threats are going on in our company like i met met this guy called rahul from how many of you know there is a language called eta uh there is a guy uh from banglore who uh who is writing a haskell compiler for jvm and we uh after we got this success we went to the haskell community and we saw him and like we were impressed till then haskell is supposed to be like a rnd language right and this guy is just out of dropout from college and he's like writing a haskell compiler and i'm a systems guy we are actually talking about how do you manage the uh like haskell has laziness and how is he able to kind of find a hack inside the jvm amazing stuff he was doing and we were thinking man we have like 100 people in our company this one guy is writing a compiler like me and dilip in fact dilip is also here uh my team members we got really impressed and we said like we should get into haskell like this if uh it's it's not like impractical this guy is writing a compiler and he's believing he's saying like i'm going to invest next three to five years in it like like like a realized guy he's saying right and uh that's when we thought well let's just jump in the next thing is like why should we take baby steps entire company we should try moving into the ideal stuff so then at that time there is a debate happening where uh what should be the real uh it should be should it be haskell should it be ghcj should it be the one is like we wanted to unify the back end and print and so we we didn't want different runtimes so when we were getting into haskell we saw that ideally if it is a javascript based um runtime it is going to be better so we went into uh choosing pure script and uh definitely i used to be a closure coder i still really like closure and lisp but uh what i found is the kind of constraint that we had which closure is suitable for a very small highly experienced team uh who's very much in sync otherwise what happens is you know enclosure everybody will create their own language and some like you can create dsl's enclosure and things will go out of control you won't know what the code will do the same code will return people can create their own meta languages and it will all go out of control so it is like it's like the artist way versus haskell is the scientist way scientist way is more collaborative like more people come together and one paper is referred by other etc etc haskell has that kind of a feel and we also have like when we have 100 people when we have maybe thousand people in our company because india is about scale of people right we have to utilize it so then i thought like yes we uh maybe we should get into haskell so that we took that trade off and um went into haskell and action my concern about haskell was will it decrease my creativity because there are types now now it's all gone but i i would say at that time uh some of the people who like art might think like it's constraining i want to just express myself this is all coming and bothering me will define the type look at the big picture i don't want to think the big picture i just want to do what i want to do right now so a very fluid environment like lisp will give you that but haskell will just like if you want to print something somewhere you have to change the type signatures of everything if you uh see i'm i'm talking about lots of uh lots of things assuming you guys know stuff but like i believe i i'm going to convince you to go and learn all this so you will what i am saying you'll you're also going to feel so i'm in that in that regard uh i think it's okay for me to just talk at a high level uh but we had the concern that haskell is like math it's not like art but like maybe we want to do business like art but we saw that if you get a little bit deep you can actually do it like art that is what we realized when we started experimenting so um with all these right trade offs we entered into haskell and we are big time into it right now um so the um the problem that we were kind of trying to solve which is getting again practical into uh mobile app development uh we see the event driven programming model is not scalable it's it's for transactional apps 80 percent or 90 percent of the apps that we make are transactional or even in a very game like app lots of things are like flows or transactions as i said in the i showed the closure code initially right you want the user's journey to be like a thread of execution you're getting me what is the user's journey even if it is multi machine like i imagine it like that even if you have iot even if you have uh user one user two and uh there is client server there is always like a thread of execution a user one i do something then it maybe goes into the iot device iot device waits for a day and comes back then it continues then it goes to the server and continues doing something then it goes to user two if you really look at it it's like a workflow which goes right so but i don't think we have unified programming models to look at the entire picture as a workflow the only thing that i saw was haskell libraries which kind of again gave me confidence that this there is a library in haskell called transience that that guy was actually talking uh writing mathematical equations in which you can write the entire application like with with symbols etc where you can actually front and back and end all doesn't matter you just write it like an equation right so that gave us that that really gave us a kick that we have to go and do it uh so that uh to achieve that user's journey as a thread of execution and to write it as equations is something that uh we think will really really make that one week app happen and see we are also not happy again considering i from come from a little bit the early 2000s days uh it was not tech was not so much of a pop culture tech was like we had to get into systems we have to understand things deeply there are few things that you really understand and it will remain for 10 20 years nowadays you learn something today tomorrow it's gone and every day you are on hacker news like what is new today what is new today so it's like it's like i i don't i was i was also into it for some time so i know that uh maybe 20 percent of you can do that 80 percent should get into fundamentals and since this it's the other way around in the industry 20 percent is fundamental 80 percent i we thought we have to change this so we see that um see again another story about functional programming functional programming um comes from deep math what is math all the mathematicians want to find the truth in nature at least a part of the truth in nature they want to find commonness what is truth truth is about patterns that repeat things which are common between so many things around you right so the mathematicians are the pinnacle like and also artists in fact but mathematicians have a systematic way of going after finding what is common between things right and people have been doing this for maybe thousands of years and uh last few hundreds of years mathematics really got again big and complicated mathematics itself became too diverse that a single mathematician can't understand the entire mathematics so this has been a problem that people have been worrying in mathematics for the last 50 years like there is mathematics of numbers mathematics of spaces mathematics of changes like calculus mathematics fractals etc then there is um this higher dimensional um again that is in spaces spaces itself gets into a big deal uh multi- dimensional and all that like things like topology and all that is also there right and in all of these there is algebra um but but overall what mathematicians themselves were uncomfortable about is mathematics is not good right now we have to fix it right so this is something that they have been working for the 50 1950s 19 till 1970s and they invented something called category theory so category theory is a layer below mathematics it's a foundation of mathematics so what they found is again by accident a couple of guys were trying to unify a couple of higher-order mathematics and they found something called category theory and surprisingly the building block of category theory is a function how how cool is that and we are all engineers we deal with functions every day the whole mathematics of all last few hundreds or thousand years all that is invented the fund the foundation of that is function so this is what in 1970s they found out but it is very abstract how is it and all it's very hard to understand but it took like last few decades to uh bring that uh insight in from mathematics haskell the people in haskell for example there are um the guy see haskell also has all these different layers of people people who are implementing the haskell compiler people who are getting the concepts from mathematics and people who don't even care about haskell but are into the programmably rated mathematics and all right and slowly things like monads and all are coming from that it is not like a made-up concept the people who actually talk about these they say these are discovered this is there in nature everywhere that's why we put it into the language if it is a little bit non-intuitive yes work a little bit hard but like for you to understand what is meant by force you have to slightly think a bit more you say oh yeah i don't think force is there see maybe you also have that attitude to kind of be creative and come up with your own new abstraction but like you can't discard uh some of these real true insights right so that with that spirit uh in our company we went and learned to some extent a bit of category theory and tried to build intuition around it and i think we are understanding it more and more and we want to make it more human we want to we also want to bring that simplify it and make it because there is a lot of truth in it we want to make it human so the whole point of the problem in haskell is that it is the humanness is missing it's all people get into some other like just like einstein going and thinking light will go at a constant speed it doesn't feel right to us right and like i don't think we all know that but how many people really feel all this is correct like okay length gets contracted time gets delayed really like so here also it's like that these are a bit higher order thinking but i think we have to simplify we have to make it more accessible so we are in a quest towards that so but but the people who are in technology with experience have to take these challenges and go into it and we think this has to be solved and you know the like JavaScript has like so many libraries even a two line thing sometimes becomes like a npm library like so too many too much of fragmentation and people call names they don't know what it is right so rather i think we can create much more solid libraries with combining the concepts and reduce the fragmentation so we thought we have to create a ux dsl out of all these techniques etc to make it more human human is user experience right like user experience of programming itself and what are we programming we are programming in fact user experience of an app interacting with a consumer right so we thought it has to be like a conversational dsl app is nothing but something that talks to the user and talks to the system and it is just a conversation going on right so we created a conversational dsl and a dsl can be chained like a narrative using a monad but that also since it's functional programming we have the ability to make it very composable you can actually create small small snippets of code which can be reused across apps which can be put outside and everybody in the world can just use one mobile otp verifier or one login flow and it can be perfected so currently everybody writes these things themselves but a lot of them are actually the same thing a lot of people what they do so why are people doing it differently because a lot of impurities are in when you write your code it is kind of you know what it's a how many of you know about this impure functions and pure functions yeah so maybe i'll quickly put it this way a pure function is like a mathematical equation for the same input it gives you the same output and it also can't change the external world okay really speaking 95 percent of your program is pure conceptually only five percent actually has to do with the other things but this five percent is like mixed up with your program like a quichadi so your entire hundred percent becomes impure and whenever something is impure it's unpredictable so your entire it's unpredictable it's also not composable just take my word for it you can go and learn why it is not composable if you can somehow separate out this five percent from the 95 percent that 95 percent becomes super stable composable reusable etc etc right so that that is the philosophy that we too can be created this dsl um and the entire app building this is pure script code can become like a chain of computation which is which is all pure functions and a business people should be able to write it so this is what we did and we chose pure script and to reduce the fragmentation there are only three building blocks one is like the ui structure um then the flow structure all the business logic whether it's front and back and there is no differentiation it's all just functions and then types your database business model communication between functions everything is all as types so you just look at things as these three things and then everything simplifies and I already covered this why we chose pure script well ghcjs was very large in size we had to be like an sdk inside app so that also you can I will share my slides uh and lots of benefit I think I've already touched upon a lot of benefit see one other big benefit with types is once we get across dealing with types types will actually give you a lot of errors initially you for you to do some simple stuff it won't allow you a lot of times when you when you actually you're going to try haskell right so when you try it you'll find that but like refactoring really really gets simple and it's a big inside to me like I don't need to be right I have these big ideas of speculative app and we are doing something every week sometimes refactoring every month etc and such things are impossible for me in javascript I'll be afraid to touch a existing code right here we just go and refactor and get things changed in a day or two and we are also working on helping people learn functional programming colleges starting something called school of functional programming we're working on one day apps one week apps etc etc all this our vision trying to do visual programming how to make the humanness we are still working on these ideas if you are interested in collaborating let us know and even we are looking at how to create a reactive system front and back and everything being reactive a lot of people would have heard about FRP but FRP at insteroids like your entire app should be written in one page like an equation and it is all reactive right so yeah so that that's about what I wanted to give and I urge you guys to go learn learn haskell and I will also send if possible if I can share I will put it in my slide some links which you can go and learn from