From Rails to Elm and Haskell - Richard Feldman

so this is from Rails to element Haskell so it's a bit of a preface I've given a few talks of my time about that sort of technologies that are outside the mainstream which I think Gelman Haskell our rails not so much and a common question that happens afterwards is people say ok I know a lot about the technology now but like how do you actually use it like why did you use it why did you choose these particular technologies out of all the you know mainstream and non mainstream technologies out there so this is a talk about the second part of that so we're not gonna get as much in depth on these languages but it's gonna be a lot more about the journey about how we went and why we went from rails to Elmen and ultimately in Haskell ok so back in 2013 I was applying to two different jobs and one of them I was interested in because of the product I was like yeah I'd like to work on that product it was a software for English teachers to help students learn writing this is something I was interested in and still interested in in fact I was actually at the time building some writing software at my own on the side as a side project so yeah that's cool I'd like to contribute to that and then on the other hand there was a different company that I was interested in because of the technology stack and in particular there was one technology that stood out of me that I was really interested in which was Haskell and they were like hey work we're hiring we use Haskell here now the reason that I was interested in Haskell I had never used it myself personally but I had a friend who recommended it I'm gonna say enthusiastically you hear some laughs maybe you have a friend who is recommended Haskell enthusiastically it seems to inspire that in people and this is the you know I would hear things like oh this will like change the way that you look at programming this is the type of language that everyone should learn everyone should get some experience with it and some of the things that I knew about it where it's a pure functional language which means that everything is immutable like all values are immutable you cannot mutate anything and also all functions have no side effects like if you call them passing the same arguments they're gonna give you back the same immutable result they're not gonna do any side-effects not gonna touch anything they're not gonna read from anything it's just their arguments and their return value and the whole language is built out of these things and I can see how that can kind of be like a mind-bending kind of like wow this this really changes my perspective on things and I was like yeah that appeals to me I as a software developer I care about my craft I love programming like this was interesting to me that I would get to go and potentially work with this technology so it's in the interview this is a really small start-up like under ten people so I was talking with like the CTO one point I was like hey so I heard you're using Haskell there can you tell me a little bit more about that and the CTO says oh yeah I wanted to use Haskell originally but then I wanted to be able to hire people so I went with Scala so I was like oh okay so I didn't end up working there I thought it was a little bit ironic that he was like yeah we want to be able to hire people and I was like well hire different people I guess that was gutted the thing that attracted me to this company so I was a little bit sad about that but uh but at the end of the day I mean there was this other company that I was really interested in and that's where I ended up no red ink so helping teachers teach writing and you know I was passionate about the product and you know technology is only one factor among many of you know what appeals to me about a particular position so this was our team back in the day there was a the four of us and then one remote guy and there's like 1.5 X with me at the time basically uh and and you know we were a very small start-up obviously and and you know sort of scrapping by it as best we could now we're a lot bigger there's a whole bunch of us and we basically have grown from five ish people to now 70 some-odd people still fit in one room for now but we're still growing we're still hiring and this is our stack back then it was rails and CoffeeScript so this is a very conventional stack at the time CoffeeScript these days is like wow what is this 2013 but but again then it was so you know this is very very traditional stack and so I think the weirdest part about the stack was that me being sort of functional curious and having you know this interest in Haskell and sort of knowing these characteristics about Haskell and also me being the front-end team at the time I was basically doing sort of functional style CoffeeScript which I'm gonna define as sort of pretend at a skull and just choose not to mutate things even though I could and sort of use a you know avoid side effects and use discipline to sort of enforce that even though the language isn't doing it for me also in 2013 a little technology came out called react you may have heard of it and at the time there was sort of like explaining Pichai I saw this I think was on hacker news or something it was like oh yeah so this react as a way to you I write your you eyes where they're a pure function from state and I was like yes I'm interested what your function hang on so so I was like very immediately intrigued by this and I was actually later I discovered that actually when react came out this is very controversial I actually didn't realize this I was only partially occluded to these things and apparently a lot of people there's a huge backlash to this which I did not know about so much so that this guy Pete hunt who is really into react and worked at Facebook when on this big speaking tour called react rethinking best practices where he was basically defending react and he was doubling down and saying yes we are doing things differently because we think they're better and they're worth it and the title of his of his talk was called rethinking best practices in relation to this tweet that was by a the author of a popular JavaScript build tool grudge is like oh yeah Facebook rethink established best practices how way to go turned out maybe they were onto something since now react has downloaded more than jQuery like the first thing ever so it's a but again back then it was it was a pretty controversial choice and in fact it was also a not only was it outside the mainstream but it was in those early days really under supported I mean there wasn't a whole like library ecosystem there weren't all these tutorials and stuff so so thinking about getting into this because of the appeal of that functional programming aspect of the the render function was was controversial and and risky worth noting as an aside another technology at Facebook invested coincidentally is Haskell so this is Simon Marlow he's one of the house movement by developers Facebook hired him to work on Haskell because they actually used Haskell not across their whole back end but it like for their spam filtering and like stuff like that so pretty interesting that that Facebook sort of interested in these functional technologies also oh camel reason ml this there's a bunch of stuff that they do there they're pretty into it even if the bulk of their back end is still like typed PHP so we had this question right okay this is our team like we're a really small company we're like thinking about you know should we adopt react this is controversial new technology and remember this is not how big we expect the team to get like at the time we had this image like oh yeah someday we will fill a whole room full of but you know back then it was like well it's just us so maybe this is okay for now maybe it's fine for just us like I'm happy doing you know Haskell flavored CoffeeScript but is the next person we're gonna hire gonna want to do that or they're gonna want to use this thing are they gonna say like yeah I don't want to rethink establish best practices I want to stick with angular and knock out like everybody else but you know the this is a real concern for us like and so we had to sort of balance the the risks of adopting react with the potential rewards so the risks were like number one no ecosystem I mean everybody's like you know jQuery there's this huge ecosystem of jQuery UI widgets and calendars and this and that nowadays of course people say the same thing about reacting like how could you use not react you're giving up on the whole react ecosystem talk about ecosystems a little later of course there's a learning curve right this is a whole new way of doing you eyes like the way at the time was you mutate the Dom and then react to saying like hey we're gonna have a pure function of like UI from state to the virtual Dom there's a learning curve to that so anybody that we wanted to ramp up on this is gonna have to learn that and then of course there was like - how will we hire people will it make it easier harder we didn't really know but the rewards you know it seemed like we would have fewer rendering bugs like the the pitch of like it's just gonna be a pure function whatever your state is we're just gonna make the page look like that it's pretty easy to see how that would cut down on bugs we'd hopefully end up with more maintainable code because we wouldn't have to have as many moving parts to it and ultimately this is the non-trivial reward is that we would get to grow as developers this is like something that has technical benefits but it's also something that would expand our perspective and let us grow our craft and as people that care about that stuff like that's a selling point that improves morale that improves our tension it's like that's a real concrete tangible benefit to the company in the same way that I was interested in applying to this company because of the technology they were using that's a real reward to using stuff that's outside the mainstream can go anywhere and get an angularjs job but this is one of the few places where I could like actually learn react okay so we decided to do a controlled experiment to try out react so here is sort of our formula number one find a low-risk project that's a good fit so that is to say a project were like we want to build this anyway probably ordinarily we would build it in jQuery which is what we were using before but we're gonna choose to build it and react with the understanding it's gonna go a little slower but it's gonna help us evaluate this technology low risk is really important something that we can back out if we end up regretting it so we like pick some small project that's something where it's like if this doesn't go well we can scrap it and rewrite it in jQuery and maybe we'll lost a couple days maybe a week or two but we won't have lost like six months of like betting a whole new greenfield project on this new technology that none of us know so to get it all the way into production I think this is really important like it's it's really easy to say oh I did a little like hack project and I put together to do MVC yeah look it's an example like that's not the same thing it's getting into production when you get into production you have to deal with things like how do we build it like how do we deploy it there's lots of things that can potentially go wrong other than just like oh I got a proof of concept up and running and then finally once you have something in production you can either expand it incrementally if you like it and keep going or you can say you know what experiment over we concluded that we don't want to go further with this and now you can back it out so that's how we tried out react we specifically picked the student dashboard which had this live update feature where basically you'd be in a classroom full of computers students are all waiting for the teacher to press the start sign red button and you don't really want to have to say like press the start assignment button and then say okay kids everyone refresh your browsers and now you'll see the assignment pop up you wanted to just appear on their screens while they're sitting there waiting for the teacher to finish explaining and then hit start so with this live update this is actually a pretty good fit for react because we wanted to be mutating the screen and a bunch of different ways just based on new data coming in and so this seemed like yeah this is something if we just take this one part of one page this middle section here yeah that'll be that'll be a pretty good initial project it's pretty low risk but it's a there's a significant real benefit so we did so we implemented this thing in react and it was low risk was one part of one page but it let us get react into production so next question was okay we've decided on a project what are the learning resources we have to like actually learn how to implement this thing and at the time it was pretty slim pickins it was like the official react Docs some talks of blog posts and of course the to-do MVC codebase which will be a recurring theme so 2013 hey we got it we got react into production and we're happy with it we liked it and we decided to keep using it more so experiment results success all right we got react in production we're happy with it we're gonna keep using it so this point I'm like wow Haskell style CoffeeScript with react I mean does life get any better I'm just living the dream it's like good could there possibly be a better like nicer stack to work with turns out yes believe it or not so 2014 one year later I came across this language called elm and I came across it because of this blog post called blazing-fast HTML and elm this is before like blazing-fast was worn out and weren't supposed to say anymore but 10 2014 it was it was still cool and it showed this benchmark of these popular javascript libraries backbone ember angular react and so forth and then l which which it was doing really well in these benchmarks and what was interesting about this was that Elm unlike the others was not JavaScript it was not a framework it was not a library it was a programming language and it was not only that it was a pure functional programming language like Haskell like everything in the language was immutable and there were no side effects like all pure functions and I had this like strong type system with all these really strong guarantees and yet it was like outperforming like pure JavaScript like while compiling to JavaScript that really caught my attention was like wow this this it's hard to believe you can do better than CoffeeScript flavored Haskell where Haskell flavored CoffeeScript with react stapled on top but maybe this is it so I started using this one my side project dream writer and I tried it out and and ended up giving a little talk and a meet-up about my experience with it and the short version is that it was really positive I love this thing I I felt like I was a kid again just like learning programming for the first time and just being like wow I can just like run and like make stuff and whatever I do the compiler is just like tells me okay just do this this this this and then it's gonna work again and like no matter what wild changes I made it seemed like once I got it to compile again it just worked and the you I just did what I expected I was like how is this happening and so I I was I became really enthusiastic about it but at the same time I was like okay let's be real like like pump the brakes here I'm not like we just adopted react like a few months ago or like I was you know now we're up to like a seven person team you know I we're not at the point where I'm like thinking about okay we're gonna use this to work and in fact that one of the local Elm meetups I was walking back with Evans flicky who created the language and I was like you know Evan someday I would like to use this language at work we're a small start-up we're not gonna do that but like someday that's that's that's a career goal for me he's like all right man so fast-forward a little bit and we got this react code that we're working on this new feature and we take it out to a classroom observation so this is something we do periodically like we take our code out to a classroom and actually watch kids use it if you've ever done like user studies or something like that you imagine like oh man like the horror when you see users actually use what you've built and how they use it imagine that but middle schoolers so I mean like everything you can imagine that they would do wrong it's like oh no no no and to top it all off in this particular case we were doing it for teaching active voice and passive voice which is hard for adults to learn so this was really just like okay we would take it out and we'd use it we'd be like no no no okay this is back to the drawing board right we'd go back and say okay we need to redesign this because we got to teach them this concept this is like our value is that like this is hard for teachers to teach we want to help them teach it so we'd go back and we whiteboard out designs and we'd like go and and then I'd basically change the react code you know take it like a week or two and then we take it out to another classroom observation it was just totally fall flat again and we just let this mean more so than any other feature that I worked on up to that point we just kept hammering on this thing and everything we tried was just like really just just just fell flat when we tried it out in practice they just weren't learning it and at the end of the day when we finally shipped the thing I looked back and I was like why was that so painful like why did it take me so long in between these observations to ship a new version of this when I'm over here on my side project just like cranking stuff out and just breaking everything you know we and then once it compiles it works again and I realized I was like yes I mean cuz I don't have this elm compiler I was like but but I knew that that was available I just didn't use it cuz I was like I can't do that this is where a start up you know we can't be that technologically that'd be reckless but in retrospect I was like no I think I just made a mistake there like even if I had taken into account how long it would have taken us to set up Elm and get it up and running and on board everybody like just on this one project it would have paid for itself in how much more quickly I could have iterated like I knew that experience was there but I was like I don't know I don't know so after this I and like reflecting on this experience I was like I made a mistake like we should have just started using it so let's not make that mistake again let's try it out and do an experiment like we did with react and see if we like it so we did the same evaluation what are the risks well familiar smaller ecosystem reacted like no ecosystem when we started Ellen had a packaged ecosystem but it was smaller than even it like reactants surpassed it at that point so definitely smaller learning curve again significantly higher react was a library this is a whole programming language so onboarding people we knew was going to take longer that was a much bigger risk for a language than it was for a library and then of course this is amplified even more how little are we gonna hire anybody like we're not gonna be get like seasoned elm developer right come come join our startup is just not that many people using the language but you know well we had had similar risks with react and it'll worked out fine like the small ecosystem not a big deal at the end of the day we could use jQuery as a fallback if we needed to same thing with Elm Elm has JavaScript Interop so for something we really really needed we could just do interrupt with react or jQuery or whatever we needed learning curve again like I've managed to get over the learning curve myself on my side project but still pretty confident we'd be able to deal with that and how will we hire people it hasn't been a problem with react maybe it wouldn't be a problem with the Elm - so their rewards were eight we could actually move quickly without breaking things like we could we could iterate on stuff and make big changes based on what we had observed in the classroom and then not have to worry about like oh my god it's gonna take us so long just you know having to throw out all my tests and because the design changed so much and then having to crank on so much stuff until it gets back to a working state where we can try it again that was a pretty big deal also just ending up with a more reliable front-end overall like elm code has this reputation for like not crashing and so that mean less debugging time less tracing down production fires that also sounded like a pretty big deal and finally again growing as developers like react yeah I was sort of a paradigm shift it was like a way to expand our horizons this is even more so because this is a whole language I mean this is the real deal this is a pure functional programming language yeah that that's the type of growth that I was like really looking for that I was willing to consider another company for so yeah we did the same formula let's do a controlled experiment try it out so find the lowest project that's a good fit get it into production and then either expand incremental e or back out so we chose a different project for this one we had this sort of drag-and-drop interface that had a pretty complicated back-end you uh you I sorry business logic behind the front-end so basically like this complicated business logic didn't have anything to do with rendering just sort of deciding whether or not usually you were able to drop things here or you know what to show the user so obviously this is a good fit for Elm because it was complicated and it was something that we were tweaking and fiddling with on a pretty regular basis so we figured hey it's not doing any rendering and at the end of the day if we end up deciding that we don't and want to use Elm well at least we'll have this one part of our code base that's like easier to refactor so pretty little risk again one part of one page not even any rendering so at the end of the day we decided you know what this didn't work out and we want to throw at Elm or at least we're only throwing out one part of one page learning resources for Elm we had the official guide which is very well written but but pretty light on details of course good old to do MVC codebase are all our old Stoll word for learning but actually here we had another code base which is my side project dream writer so we could actually look on something at least significantly more sizable than to do MVC and a lot of cases having some existing code basically you can look at and my experience has been more valuable than sort of like the diminishing return end of documentation being able to see like this is how to do a real thing that works is pretty valuable so it was good that we had that we also just had like somebody who actually knew it at this point so unlike reactor was sort of like learning on the job like I actually this point had a few months of doing like Elm as a side project basically all of my free time because I was obsessed with it so I was able to help out and and so one of the main ways that our team learned Elm was basically just like okay I'm gonna pair with you we're gonna we're gonna work together until you've learned it pair programming is really effective when it comes to knowledge transmission that's like one of the biggest benefits of it and that absolutely applies to ramping people up on new technology and of course once I'd taught those people then they could teach other people and now there's much people on the team who knew Elm who didn't know it until they joined our company but now they're able to onboard others because of what they've so 2015 goals get element of production and we succeeded and one of the things that we found that was pretty cool and this is a release that actually happened shortly after we got it into production was one that improved the error friendliness now I used to be a Java developer back in the day and so I'm familiar with errors like this anyone here ever seen any sack traces like this yeah sorry this should have been a trigger warning on that so this is really I mean like I I was used to this from my compiled languages and even even stuff like this this is like a like intended to be humorous somebody posts this on the internet it's like okay so this part of the stack trace comes from Tomcat and this is from spring and then this is down here is from hibernate and like yeah I mean this is not the friendliest error message I've ever seen but contrast this with with Elm so this is like if I if I make a typo let's say it says okay the user record does not have a phone number field i misspelled phone number right it says this is usually a typo here are the user fields that are most similar and it like lists out okay so here's like some other stuff that it could be and then find it's like so maybe phone numbers should be phone number it's like really just bottom lining it for me it's like hey I think you made a typo here's why I think you made a typo like it even uses the word typo so I mean this is like really the extreme opposite end of what I was used to based on my java experience so I was like yeah this is rad like I love having this level of help and it turns out my teammates did too so this was definitely like one of the unexpected benefits of Elm another one was so no runtime exceptions is kind of a tagline of elm now granted when you have a new you know established large JavaScript code base and you have a brand new elm code base like you kind of expect that right so like there's gonna be a long like list of JavaScript errors that have accumulated over time stuff crashes its programming it happens and then like of course you know at first like it we deploy elm and it's obviously gonna be much less but what this graph of runtime exceptions isn't saying is I haven't labeled it for the years this is current this is like since 2015 when we introduced Elm now it's not that there have been zero runtime exceptions instead it's zero pixels on the graph because JavaScript something like mm we finally had one two years after we deployed it and we were like ah come on we tarnished our perfect record but the language feature that that that happened with no longer exists so if only we'd waited a little longer maybe we'd still be at zero so it's not zero runtime exceptions but it's negligible like it's not something we'd really worry about anymore like it was our own code gonna crash you're like there's a production fire the pager went off is that Elm no it's so this is this is a really nice like tangible benefit you know it's not like you know developer happiness it's like no this is a real technical like okay I can measure the benefit here but yeah there was believe it or not more developer happiness going from like this mismatch to like like a cohesive language that was designed to actually be functional programming so actually there was so much that I gave this talk at strangely this is a stolen titled make the back end team jealous because one of my co-workers who was more back-end focus was like hey man I'm like feeling pretty jealous like all the front end people are so excited and happy with Elm like and you know we're doing rails over here and like keep in mind like Ruby is a beloved language it's not like you know we're doing COBOL and we hate it you know it's like ya know just like we're we feel jealous because of like all the excitement and enthusiasm that the front-end team has for elm it's like I gave this talk and just kind of like walked through you know a more expanded version of the story that I that I just gave on sort of like how we ended up with Elm and it was well-received and as a consequence of that not just that talk but in general hiring actually got easier and what we found was that it turns out there are a lot of people who were like yes I would like my developer experience to be better and so there were a lot of people who were applying like they found out about Elm and they found out that we were hiring for elm developers and were like you don't need to know it just be willing to learn it and they were like cool I'm in so much so that it became and continues to be the number one reason that people apply to the point where now several years later I don't remember how we hired anyone before Alan I mean this did not happen with react like react it was like okay it's fine we're still able to hire people with Emily I don't know if we'll be able to hire people and I would be like I don't know how to hire people to any other way than like having ailment just being a magnet first people who are like yeah I want to expand my craft I'm gonna like try something new like we hire people who are like I did C sharp for eight years I want to do something new were like awesome but please apply and to the point where when we hired a head of talent she said I have never seen an inbound pipeline this strong like usually you have to reach out and like bother people to apply but you guys people just apply or like yeah and it's really it's very clearly because of Elm you look at cover letters it's like ELN is always in there and I should I should give the caveat that like we're a very remote friendly company I don't know if this strategy would work out as well if you're like okay in Columbus Ohio we're hiring elm developers local only there might just not be enough people interested in that but for us it's like we go from like West Coast us to Central Europe like anywhere in between we have people in South America like it's it's really like given that we have such a wide pool to draw and like yeah it's it's been amazing so an example of this our most recent hire Katie Hughes from Oregon so she said it's been weird transitioning to a language slash framework that I can just trust I don't really need to move to the browser and see if everything's secretly broke so you can just like like work with the compiler and most of the time that compiles it just works like this is she's comparing this to her experiences react which is what she was doing before Elm and again Mike just learned it on the job totally fine this experience by the way I actually ended up giving a talk about that cuz I was like I don't think people like can know what that experience is like so I giving a whole talk about basically like coding in the dark essentially like like working building you eyes without actually opening the browser and it's based on a real story where I was on a four-hour flight with no Wi-Fi it couldn't actually like do any browser development cuz the page had to load HTTP before I could do anything I was still productive the whole four hours it was pretty cool so I did something like live coding and kind of demonstrating to give that feel okay so to make a long story short what's the experiment success yes really big success I mean that's this is probably the most successful experiment we've ever done like by pretty substantial margin I mean it's really difficult to overstate and and really it was like we followed the same formula both times let's find a low-risk project it's a good fit for the technology get it into production then either expand incremental your back out so as a consequence of this you know following this same procedure in 2013 we introduced react 2014 kind of expanded our use of it I started doing L on the side and then 2015 really cool it's introduced a little bit of Elm then eventually Elm kind of took over and at no point did we say we're gonna be an Elm shop it was just this total gradual like incremental experimentation we just kind of let things evolve based on what we thought was best and and so the key was just low risk and then see if it grows and so far this is what ended up happening also in 2016 based on how well this is gone we decided to actually bite I can't take care of this my boss decided we should hire the guy who made Elm and kind of his theory I was like look this has been so great for our hiring like how do we maintain this advantage when more companies start using Elm which he was right now there's a way more companies using help back then I was like there's like five companies using Elm now it was like hundreds thousands I have no idea but basically he was like hey let's let's hire the guy who made it because he's a scarce resource so we'll continue to stand out so he's still working here he only works on Elm that's all we pay him to do so we're basically making a very direct financial contribution to open source like we're really giving back in not just a token way but in like that actual like you know this is like this guy's whole job and that's all we pay him to do we've also done some other experiments along the time so I don't want to give you the impression like every experiment we do is a smashing success so terraform was something that we tried out we thought it was like very declarative infrastructure ap I thought it would be a good fit based on stuff that it worked out well for us in the past didn't end up panning out so we're actually in the process of backing that one out graph QL did work out it's like not not been like the wild success that Elms been but it's like yeah it's good we're gonna keep using it and elixir was sort of somewhere in between where we had started using it we got to elixir services into production like really small sort of special-purpose ones and we decided I think that's that's enough we're gonna we're not gonna back them out like they're they're still running two years later they're totally fine but we basically were like yeah this is not what we're gonna make are like new default back-end technology the way that Elm became our new default front-end technology by the way you might be wondering like hey lik sir that's a back-end technology it's kind of a lot like Ruby like what's the deal were you looking for a new back-end technology to replace Ruby and like kind of yeah so you know again back-end team feeling kind of jealous of front-ends like someone we asked ourselves this question like what do we want our back-end stack to be in five years like there came this point where we crossed this threshold where we're like hey we're not a startup in survival mode anymore we actually like we made it in the sense that like we're not gonna die which is like first start if you ever worked for one it's like an exciting thing to realize because usually by default most startups alike yet we're gonna run out of money in this many months but we can across the social we're like oh actually we're like we're good we're gonna be around for long ago we make enough money that we don't have to worry about that and so we were kind of like thinking like five plus years ahead do we want to every year be expanding our rails codebase and having more and more of that built up when we've already identified kind of a several problems that we've already experienced do we want to double and triple down on that or do we want to try some experiments and see if we can find something else that we'd rather invest in for the long term so elixir was the first thing we tried and was like yeah you know we like it but but it wasn't like it didn't nail it for us the big thing was that whereas with Elm one of the things that we really liked about it was the maintainability benefit like the the type system that really really helped us out especially with big reef actors that was a problem we were having with our Ruby code and elixir has this thing called dialyzer but it's really not the same thing as like a being built around a type system like elm toys so you know we were looking at this in man I mean the first thing we did we were just like what has worked well for us and it was like okay declarative / imperative like react Elm sequel all technologies that we've been very happy with obviously type pure functional programming with Elm that's worked out well also build time schema checks with something else we'd like so there's this elm graph QL library that basically says okay we can connect your graph QL schema to your front-end and make it so that if you're trying to talk to the server / graph QL and there's something that doesn't line up like your types or mismatch like there's a field you're asking for that it doesn't understand that actually fails at build time rather than waiting for it to crash and cause a problem in production so we were happy with all those things were like what what can give us that same kind of experience on the back end is there anything and we looked at everything I mean really anything was fair game like it even stuff you may not recognize all these logos I'm very familiar with them at this point but like anything was fair game I mean even more obscure stuff than this but you got to remember the more obscure the language the more the risk right the more the trade-offs the more benefits we need to see on the other side to outweigh those and really at the end of the day it came - one kind of obvious choice Haskell language that I'd sort of like started out being interested in like way back in 2013 and so the reasons here basically it's a strongly typed pure functional language like Elm in fact actually Hellman House will share a lot of syntax there type systems are pretty different but they they have a lot of the same characteristics as far as like strong runtime guarantees also it has a sizable pure functional ecosystem so a lot of the other languages we looked at it's like hey F sharp like F sharp is a functional programming language but really the ecosystems mostly c-sharp so it's sort of like well soon as you start reaching for other people's libraries you're getting a lot of like Oh a mutable code that's like really not what we want to be working with and we didn't really want to be fighting with that like one of the things we liked about Elm was like yeah there's a fewer number of elm packages than NPM packages because there are a quadrillion NPM packages I think at the last count that might be on the low end but at the end of the day like all the ones in Elm land they follow all the same guarantees so like as our elm code base does so they're really really reliable and if you're looking for a type pure functional package ecosystem nobodies is as big as Haskell it's it's the biggest one out there bite like by a huge margin and also it has these really cool build time schema checks for the database this is something that seemed really exciting and I'm gonna show a little bit of code of that later nevertheless obviously there were risks so again much smaller ecosystem that then any of the alternatives you're looking at learning curve even higher than Elms like Haskell is notorious for having a high learning curve relative to other languages and of course the the same question how will we hire people this worked out really well with elm would it work out well with Haskell we didn't really know by the way one of the questions I sort of asked myself like reflecting on our experience with Elmen with react it's like our bigger ecosystem is always better my conclusion was no I think it's more that there's like a minimum sort of viable size so for example we do not want to be writing from scratch a Haskell PostgreSQL database driver that sounds like a really bad idea not not how we want to be spending our time and some of the language we use a lot about we're like yeah they don't have that like that's kind of a problem we don't wanna be writing a web server from scratch but at the end of the day it's like you know an elm we ended up having to implement an elm roll bar library to like log errors to roll bar took like a day you know I mean how much did that cost us versus being able to pluck that off the shelf with like NPM well about a day in the grand scheme of things with as many developers as we now have in as much time as we invest in our tools yeah it's kind of a drop in the bucket so kind of my conclusion was like all right as long as there's like a minimum level of stuff where we're not gonna be spending like a month writing some package that we really need to do our jobs like I don't really care I'd actually rather prioritize the ecosystem being really high quality and really cohesive over it being necessarily bigger and bigger and bigger like yeah NPM has a you know a billion packages do we use a billion packages no we use like you know a handful okay javascript is more but but like a nil we use like I think it's like under 100 packages you know out of the whole ecosystem so so really I think there's there's some strong diminishing returns that only doesn't get talked about that much when factoring in technology choices so some of the rewards are expecting certainly easier to maintain complex business logic again this is like our biggest pain point with rubies there's a lot of code where it's like yeah making changes to the stuff is scary like we we're like I hope the tests are gonna save us but we do not have anywhere near the level of confidence in making changes it's a lot of this really complex stuff as we do in elm and we don't want to keep doing that we want to start investing in tools hopefully that can help us have confidence when we're making changes to complicated business logic a more reliable back end that doesn't crash as often you know Elm no runtime exceptions hospitals not quite as hardcore as Elm is about that but it's it's definitely like it's unusual for a Haskell program to crash whereas you know with with Ruby it's sort of every day and again growing as developers right Haskell is on a lot of people's bucket list is the language to try it was certainly on mine and so at the end of the day we're like yeah let's let's do it let's do a controlled experiment to try out Haskell find the lowest project that's a good fit get it into production expand and commensal Eeyore back out so for this one we decided to go into sort of like no ratings labs like our internal tools so we have a lot of curriculum people who are usually former English teachers who are designing the curriculum for our questions and so the nice thing about doing a project for internal service is you do have real users real stakeholders but they're very understanding because they work for you or they work with you they work for the same company so if your system goes down because you don't have the infrastructure set up right or something like that they're like okay when you have it back up as opposed to being like forget you I'm going to your competitor or something like that it's a lower risk then again we once again have this question of learning resources now react was brand new when we came out and Elm was also pretty brand new and we came out so there wasn't a whole lot of stuff there Haskell's a few decades old so you'd think there would be great learning resources there's a slight problem though so if you want to learn Haskell your options are number one there's this like style of teaching Haskell that's like theory first and then practice so we ready to chew about monads and mano Ed's at functors and then eventually like chapter 7 we're gonna like print hello world to the screen so that's one style another style is lambda calculus then theory than practice you laugh but the most popular haskell book is that way chapter one is lambda calculus like you cannot make this stuff up that's your second option the third option is theory than theory in the category theory so basically if the way that you like to learn is building stuff and then learning theory yeah please come talk to me if you have found a good Haskell resource that teaches that way because I couldn't find it and it's it's really I mean it's a cultural thing like Haskell came from a research language it was not designed to be like used in like production systems in industry it was designed to help researchers collaborate on computer science stuff and it just ended up being used in industry so I understand why it is that way historically but at the end of the day there's a huge opportunity here if someone wants to build that resource like hey teach people how to build half build Haskell programs by starting from building stuff and then working backwards to the theory I think there'd be a lot of people who are really interested in that as evidenced by the fact that I know a lot of people in fact when I've been telling them the title of my talk they're like you know I tried to learn Haskell several times and it never stuck but it turns out there is a way that we've found that's effective in teaching Haskell which is teaching each other a pair programming we actually have several people on the team who know Haskell well unlike before where it was like just me teaching everybody Elm now that we're bigger we actually have like multiple experience Haskell ORS and they're teaching other people and now they're capable of teaching other people again pair programming it works it's a good thing so hopefully there will become more learning materials in the future that are sort of more practice first and then theory but in the meantime hey at least for this is something that's worked out so yeah 2017 we got we got Haskell in production and so some things that we learned about it is one is Haskell's like the opposite of omakase so this is a rails term this is something that the creators of rails have used to describe it so omakase is a style of sushi where you go to the restaurant and you say I would like to omakase which means that the chef is going to decide exactly which pieces of sushi you're gonna get and they've chosen them in a particular order they're gonna bring them out they're gonna make them it's like this will be a great meal for you but you're letting me make all the decisions you're not saying I want this and that no no no no you're saying do what you think is best and that's kind of the rails philosophy so what I mean by Haskell is the opposite of that is the first thing you decide is which language features you want so Haskell being a research language you can toggle on and off which like language features they like like what string literals mean in the language is like something you can configure now again for researchers makes great sense for practical people were just like what's the one that's good I don't know like there's strings so we have to decide this right when we were doing our initial experiment also you have to choose the standard library there is one point of consensus here which is you absolutely should not use the standard library that Haskell ships with that's the one thing that everyone agrees on you should pick a different one so we did we picked a different one and we've been happy with it and then of course then you need to start doing normal stuff like choosing your server framework and whatnot so so really about as far from rails as you could possibly get which is not always a bad thing but definitely something that you know was was an unexpected thing that we learned this is Michael Newton from England as a language I've really enjoyed it it being Haskell there are a lot of knobs to twiddle no kidding so it felt important that we've done the Rd project first so it was good that we had like this small initial project and it was like why we experiment this way where people could like figure things like that without having to get into an argument like a 30 person team it's just like okay these three people they're just kind of big decisions we're gonna run with it and that's worked out pretty well it's it's not quite as nice as you know having rails that's been vetted by this enormous community but you know it's good enough for us something that s Akeley by the way Tessa is is American but I thought it would be appropriate to put the New Mexico flag because Tessa is has extreme New Mexico pride so when I showed her this slide she was like yes that's how it should be so something we did well with Elam that we haven't done with Haskell yet it's like identify a challenging area and then make it less challenging so this is something we did with them where we're like hey we've noticed like this pattern that we do and like not everybody gets it when we start out so like let's see if we can find a way to just to make it like a little bit easier and make it more approachable we haven't really made those same kind of investments in Haskell and I think that's something that's like an ongoing area of improvement for us comparing compiler error messages I thought this was a good treat from Chris Jenkins is an experienced Haskell who's like here's how beginners he hassles every message is line number but integer I know that word and then a bunch of you know a bunch of gibberish hassles error messages are not as nice as Elms let's just leave it at that and as a consequence of this like Michel glass who lives in Berlin said people get stuck more than an elm in Haskell but also people don't cause regressions which is very different from my experience using rails when I was just getting into it I didn't know anything and rails is pretty opaque a lot of the time it's like oh this did a thing why did it do that thing I I don't know I just had a lot of surprises and I definitely caused my share of regressions maybe more than my share of regressions so one important difference is that yes okay it's it's it's not as user friendly as Elm but at the end of the day the guarantees that we have are really nice and that helps people like so as they're learning the language like avoid you know stepping in pitfalls and causing problems so here's an example of this this is the the type Postgres code that I mentioned earlier so here's what this is doing is we're calling app dot modify exactly one we're passing in a log and DB so don't need to worry about what those go the interesting part is here so this is essentially kind of like a macro this is built into the tight Postgres library and what it's saying is write some sequel in here and I'm gonna execute it now so far that might not sound like that interesting like yeah I can do that in active record give me a string I'm gonna spit it in there but this actually doing a lot more than that so one thing it's doing is it's actually going to check the syntax of this to make sure it's valid sequel okay all right that's pretty nice another thing that it's doing is we're actually doing interpolation here so these are variables that are in scope like name is a variable in my Haskell code deaths like description is a code of my Haskell code and it's actually good it's not going to do string interpolation it's gonna do the right thing like buying the the parameters in there so we don't we're not vulnerable to a sequel injection attacks that's also pretty cool the really cool part is that this is actually connecting at Build time to my database and checking the schema against the types in my code so if name is a string but this column in the database is an int this will not compile at Build time like we have a complete connection between our database and our code like as we're writing it that is awesome and or as Giuliano who has an amazing beard actually his facial hair like like grows and contracts like right now he's completely clean-shaven but I've seen him do this over the years so I'll just like grow it out as much as possible and then like well like one day just like cool mustache like all the beards gone it's just like that's all the left and then anyway he's from Brazil he's awesome he's like hey yeah like the PostgreSQL type library is my dream come true for an orang like thing he didn't see sharp for many years before draining our ink and he's like yes this is what I always wanted like I can write plain sequels so when the performance gets bad I can connect it drop down to the lowest level thing and yet it's all checked and it all works nice so how was the experiment all things considered yeah definitely a success we're continuing to use it no 2019 two years later we've only expanded our use of Haskell some more recent experiments we've done we've been using the NYX package manager which is really cool definitely recommend checking that out kubernetes probably a you all heard of that one we're just like kind of trying that out in the same you know using the same procedure that we have everything else our infrastructure folks are hoping that we'll solve some problems we've had and post graph I'll which is a pretty cool technology for sort of automatically connecting a post Postgres database to a graph QL schema making it so that you don't have to write queries by hand you can just say this is the data that I want you write the query for me and for a lot of like really basic queries it seems like that'll save us some time and of course we're proceeding with them exactly the same ways before low-risk project into production expand incrementally or as the case sometimes is back out okay so what all of this has gotten us is looking packed all the way back to 2013 where I was like man do I want to work on that product or do I want to work on that stack like I have you know conflicted decision to make now and 2019 I'm just like hey I'd like to work on that product and I'd like to work on that stack so I've been very happy with my decision to do reading and this is probably a good time to mention we're hiring we hire remotely I work remotely from Philadelphia and the headquarters in San Francisco obviously have people all over the world you know Europe South America all over the US and yeah if any of this stuff sounds interested to you like no matter what your background is please come talk to me thanks very much [Applause] [Music] [Applause] we have some time for questions okay you started out with Elm on the non rendering business logic and it looks like now react fading out and being replaced by Elm accurate do you use them in tandem or as all rendering done in Elm yeah pretty much everything is on an elm now so we have about 300 thousand some odd lines of elm code are powering our front-end and JavaScript is now just like a tiny blip so basically like if you're doing front-end programming at no red ink that means doing Elm we really haven't done like expanded our use of react except kind of in that transition period or sort of like okay if you need to make a small tweak to a react thing cool but like if we're making a really big change or just like yeah we'll just redo an elm so it sort of evolved in a more and more L Mike direction certainly all the renderings in Elm now yeah except for I mean we still have some legacy react but that's about it are the questions yeah great question so if typescript was around when we were switching to Elm do you think we would have gone in that direction I certainly think I would have tried it so I actually know a good number of people who use typescript at work and Elm on the side and it is not the same but you know knowing what we did at the time I'm honestly not sure it's hard to say cuz I mean back then in 2013 I think typescript existed but it was like really really obscure at that point so I wasn't really as something we really even considered to be honest I'm just gonna go with audience questions cuz I think we got one on slide oh so yeah you had a lot of like you know constant pipeline of new projects like you can see the gradual migration in actuality you know do you actively yeah question was do we actively transform our old react code into Elm or do we just like wait for new projects and do them in Elm we don't actively transition our old stuff so we actually still have some CoffeeScript left in the codebase and we had like a question at some point we're like hey should we just like get this out of here just like compile it to Jas and just check that in so we don't have it in our build pipeline anywhere in its some part like I don't know it's not really hurting much so I'll just leave it there I think our philosophy is mainly like we're more concerned about like building new code than sort of like going back and messing with existing code that's working okay if we have a problem with it if it's like causing us significant headaches then that's a good reason to do it but we're not really like cleaning things up just for the sake of making them cleaner maybe there will come a time when we change that but for now it's more focus on building new stuff oh I mean so our older stuff is like mostly react but there's still some like jQuery and I think even some like angular one like in some dusty corner that may have gotten been gotten rid of but I think it might still be there and whereas an elm it's like we just pretty much use it out the box so we don't really use they're really like elm frameworks ty nove like that anyone really uses I think I heard of one person once made an elm framework and like I'm making an elm framework and I was like okay but I don't think anyone really uses it so yeah so what's so like what's the Haskell security story that's a good question so as I understand it the the way that we're doing security in Haskell is currently as far as like authentication goes is because we have this big rails monolith we're actually pretty much delegating that to Rails at the moment so there's the possibility that in the future we'll split that and milega it so an authentication service but basically it's like when the user logs in we're just like hey kick that out to the rails monolith and then let like do the authentication then just like pass back a token that the Haskell service then it's like a model if is this is this valid or not so pretty much for now it's all delegated but at some point in the future I can see us you know migrating more of that but you know that's part of the incremental approach oh there another could Elm be used on the backend oh great question um yeah so this is actually like a it's it's it's this is such a frequently asked question that it's on the like Elm FAQ like road map and the short answer is that like basically Evans the creator of Elm his view is basically like if I want to do LM on the server like I want to do a really good job at it I don't want to just be like hey it's like Elm but now it's back in here he's like I actually want to like think out like hey what's the best like language I could design for the backend and maybe that looks like L maybe it doesn't but that was he's like that's how we got the result of Elm on the front end was just saying I want to design a language to like solve these problems and he's like that's a huge project and like we're not done with the browser yet so I appreciate that focus so in theory yes but I think like not anytime soon like that's I think the phrasing he used was even if we started today it would be years away so not something really thinking about it react has millions of approaches to Styles modules plain CSS CSS injections how is this handled in L so L is like react it's like concerned with rendering the Dom so it's it doesn't have like styling built in you can choose your own alternatives we use LM CSS which is basically like CSS and L like there's like CSS and j/s it's essentially the same basic idea so you write your Styles inline using plain elm code one nice benefit of that is that LM c is actually like type checks them so like if you try to say like I don't know display hidden or something like that or like I display that one sounds plausible um so a float hidden than like a mole type check so basically the the approach is up to you that's the one that we use but plenty people use like you know before that we just continue to use SAS and just like head separate style sheets with so that's fine a really cool project that I cannot recommend enough is elm UI so elm you I actually gave a talk about this it's basically like imagine if you didn't have CSS like you weren't even thinking in terms of CSS it's like matt Griffiths took this this like goal of like I just want to make a system for layout and styling that's really good I don't I'm just like CSS is a compilation target I'm just gonna rethink all of this and like it doesn't use flexbox that does I mean I could compile the flexbox but it's like you don't need to know flexbox you need to know CSS cascading rules anything about you don't need to know any CSS at all to use this thing and it'll lay out your whole application and it's it's awesome I really like people love that thing that the elm slack channel 4 LM UI is just like goes bananas cuz it's just like there's so many people who love it so we're not like actually using that because we have a really big CSS code base at this point but I think if we were starting over today like I would absolutely start with that so I won't worry yeah great question yeah so so question was like how do you decide to like that you're gonna do an experiment like this with the new language and new technology is that something that like senior managers do and then it's like top down or is it like Engineers do it anyone can propose it I mean it's it's really like anyone can start the discussion but like we have the discussion as a team it's like hey is this something that like we plausibly want to get into is this like do we want to make the investments do we want to do the experiment if the experiments successful do we actually see ourselves adopting this so that's more of a group discussion but yeah absolutely anyone can start these things so awesome thanks so much [Applause] you

Channel: ChariotSolutions

Views: 53,324

Keywords: elm, functional, haskell, phillyete

Id: 5CYeZ2kEiOI

Length: 52min 18sec (3138 seconds)

Published: Thu May 09 2019