Gage Peterson - Why your ReasonML Evangelism isn't working | ReasonConf 2019

reason comfits brought to you by our cold sponsor as atreus and chain Street [Applause] hello everyone thank you so much for coming to my talk really excited to be here it's been amazing I kind of applied for this talk and was very surprised when they they picked me because I don't know I just like it's amazing to be here in Vienna and this is an amazing conference so I'm really excited really excited a little bit about myself my name is gage Peterson I work at podium which is a kind of like startup in Utah which I'll talk a little bit more about I started using okay ml four years ago from a Jane Street talk that I watched and thought it was cool and she used it mostly maintainer if you can call it that of Reason cookie I barely modified ever just cuz it's like very simple bindings but it anyways not not super compelling but so again we're capo diem this is our little web site and so podium is a customer interaction platform essentially we help customers or we help brick-and-mortar businesses like auto dealerships and like dentists and other things kind of modernize the ways they communicate with our customers they tend to be people that like to call people on the phone in the age of when you're supposed to text people and stuff like that so we're trying to help people that are not tech savvy to be more tech savvy and be more convenient for everyone to be more to come to talk to them so I live in Utah it's very far away from Vienna as you can see you can also see a weird crack in the earth that is rather concerning I'm not sure why that's happening but that's Google Maps sorry yeah so I guess the real question you have probably now is do does podium use reason in production and not yet and I know that's really very awkward you know for this particular talk so the question is why should you listen to me and the main reason I would say is because I've made a lot of mistakes that you can learn from and second reason is because I actually have introduced a lot of new technologies at podium and I think those lessons can be applied to reason amount in the future so storytime many of you probably know what this logo is it's a little go of another programming language that's very similar to reason you know the both kind of inspired by ml family languages syntax is very similar to Oh camel anyways but basically I tried to introduce element podium and I learned a lot of things along the way trying to do that and so we'll talk about some of the things I've tried there may they're probably things that you have fried as well so let's these are kind of different strategies that may be less effective potentially and so the first one is the complainant suggests so this is essentially where you bash JavaScript or whatever programming language it is you kind of just say you know you're programming something and bad and then something bad happens to JavaScript like you get a runtime exception you say you know I have to use JavaScript when almost so much better or in reason it's so much better and you kind of like show somebody how amazing your their life could be if they didn't have that problem or whatever but this is a bad strategy don't do this and the main reason is because everyone just thinks you're a complainer and a baby because not only that they also think you don't know anything about JavaScript because if you did then you wouldn't have all these problems that you're experiencing and the thing to remember about this is well we totally understand that this is it's still really good you know it's it is arguably better than JavaScript in many ways you got to remember javascript is actually very popular and you see that little pink bar at the top those are the people that have used es6 and do not like it and these are the people that do and so it's just a bad strategy because you it's it's very very popular language for the general populace it's not it's just it doesn't work very well and so unless somebody's actually experiencing a problem then yeah I'm not very good and so and typescript is a little bit more mixed reviews you could say but at the same time is also pretty pretty darn popular so also same goes for that so another strategy that I tried was called bypassing the human element or essentially you just it's just basically I'll just describe with this they can't stop you from putting in reason and fraud if they don't know that you are right and in case you're wondering also bad strategy in this case it was Elm I started writing a project and now I didn't ever like ship it or anything I just kind of like started writing the beginning of a project when that I was supposed to be writing and react and and basically you know this kind of thing happened where you know people kind of got kind of got mad about it or like what we do and even if it was like technically a good idea or whatever like it just breaks people's trust more or less because then even if you got it into production or whatever as soon as somebody came across the code they would be completely you know thrown off they never learned the language it's just not a good strategy like it's it's nice you know like if they just tried it then they would like it right that's kind of what you think but in reality it just makes people mad at you and not trust you with their code base anymore luckily I didn't go to Ed Lee but but yeah it's not a good strategy so don't do it another thing I tried it was getting in LA and this is actually kind of a good thing so so basically I just asked somebody if they would like to learn how them because they were somebody who kind of liked me and they liked it they they would like it and they said okay and then luckily they also were a person that was quite a bit more senior than I was and so as such they had a convincing argument to more people that were higher up in the company and eventually you know they said well try it and that's something that was amazing cuz I didn't even have to convince anyone I just convinced one person and then they kind of still other people but so that was kind of cool and so we were kind of like partying we like thought like you know seeing on the Elm SLAC pony amuses even though we didn't ever ship anything or written any yeah but we kind of thought we were going to unfortunately everyone just went back to writing react and never really seemed to care that Elm had supposed to be been proven to be better and they didn't seem to care at all either and so they didn't seem to even you know just kind of went back to writing react let's just what they did and so the next thing the next thing that I kind of did was assume my idea was good in the first place because that has a lot of upsides it's got a lot of cool things like it's got no runtime exceptions which is just still amazing you know it's still really cool as a force semantic versioning that means essentially you can't push a package up and make a breaking change like you can't remove a function or something and then tell people that oh yeah that's just a small change you know it's like I don't feel like it's that big or whatever you do the sentimental versioning as it is and all the libraries have to be documented and there's a lot of really cool things about it they're much more I mean downsides I mean kid there can there be downsides right am i right you know it turns out there definitely is and in fact I was in a meeting and basically we're very full stack at podium meaning everyone writes front-end code and back-end code and you kind of own everything and we elected that a lot and along that line we basically had the decision that every engineers now a react native engineer now so if you add something to front-end you were supposed to add it to the native app as well and I thought to myself Allen doesn't really do native so that was awkward inside my head because that meant that essentially everyone had to write something in react and then or right now supposedly and then rewrite it and react and that just seemed kind of like a really dumb idea and so in the end kind of end up at least in my mind being kind of a failure for me just because it didn't really meet our needs and it totally could meet your needs it's not a bad language it's a really great language but you know you kind of think about it like it's reason I feel yer and absolutely not I mean reason you can use it as react and it has a ton of potential to be very interesting to other react engineers and so so anyways the first step I think along this journey of helping people to use reason is to have empathy for them and the way that they think there's a lot of the things that happened to me previously in the album happened because I didn't really understand how other people think about the benefits of a language and kind of trade them off there's this awesome article I really recommend you read it's also kind of the namesake ulis talk which is why you're f sharp evangelism is working which is interesting because f sharp is actually kind of inspired by oh camel and probably many other languages but and so that was interesting I'm like well this probably applies to me so anyways there's this it talks about this adoption lifecycle which is from a book called crossing the chasm lots of references but essentially they introduce like different types of people and so essentially on the left you have people that are very open to adopting new technologies even inventing new technologies to the people on the far right that literally do not want anything to do with technology if they could ever help it and so there's kind of like the spectrum of different types of people I could go into all the different types but in reality it's a lot easier to just simplify it down to early adopters and pragmatist these are essentially you know we're kind of talked about like who these kind of people are but so early adopters guess what that's probably most of us in here they like to find hidden gem kind of technologies they're like they like to rely on their own intuition to make technology decisions they like to kind of they learn new technologies extremely quickly and they like to program just to program like it's they tend to just like to create things just kind of they're like the art of programming in a lot of ways just for the sake of it and pragmatist they they're very different in a lot of ways they like to get stuff done you know and they want to avoid fads that's a huge thing about them they really want to not invest in technologies that would go away or stop being supported or other kind of scary things to them and they rely a lot on other pragmatist opinions about a technology whereas early adopters don't really they they kind of like rely on their own opinion and they can't they can't all of them can learn about technologies quickly as well but they don't really want to unless they have to and so another interesting thing about this curve a my first let's ask like where do we think reason is along this curve and I put it about right here which maybe it seemed a little kind of crazy or whatever but when you look at this survey and you kind of look at it about 5% or for five point six percent of people actually used it they took the survey I know it's the survey and so it maybe has some biases to it was who took the survey and other things like that there's a lot of things like that but just very kind of like a rough estimate that's kind of where I put it along the graph and so as you can see there's also this weird gap in this bell curve and so we call this the chasm and the main reason it's called the chasm is because a lot of dead technologies sit at the bottom of this chasm that don't ever get from the early adopters over there Google glass I was gonna put Google glass down there but it didn't fit but you know maybe with CoffeeScript and some other things but anyways although you could argue that CoffeeScript actually made across the chasm even though it shouldn't have anyways hopefully you don't like that so anyways the real reason that exists is because there's a fundamental difference between early adopters and pragmatists like they're just very different personality types and so let's go through those differences again early adopters driven by a pleasure of exploring where programs are driven by the desire to get things done like they the technology is just a means to an end for them it's kind of like this annoying thing that kind of have happens before they get something on the screen alright you know it's kind of like the way they feel about it and we don't rely or pragmatist or early adopters don't rely on well-established references like we don't really care that like like some big every big companies using it or not using it we we kind of like just if it's good then we just use it or whatever appearances as definitely do not feel this way they want they want desperately to use the technology that ever one else is using because then they get all the benefits of the community and and for a good reason it's totally a good argument and they really care about trying to weed out fads and not like just jump on every bandwagon that comes along or whatever they also so very kind of like way to summarize the way they feel is they they would rather chew something predictably disappointing over something excellent and proven every time like they'd much rather and this in like they'd rather have the problems that they are comfortable with rather than the problems that they are unknown it's kind of the way that they tend to feel about it and I know all this can be kind of saddening because you're like oh man we're so far back on the curve we're never gonna make it it's a huge chasm now and we're gonna become Google glass and whatever but but don't be sad we can do this together like we're all here this conference and it can we can make it happen but the question is how and I'll do my best at describing it how what I've learned more or less from it and the things I've seen at podium they kind of help with that with different technologies that we've adopted so for high-level but you really want to alleviate pragmatist pain and but the thing about it is yeah we're like yeah I mean I know that and but the thing is you a lot of times we assume people that are in pain when they are not a very good example of this is at least my co-workers and I feel like most JavaScript programmers don't actually care that much about runtime exceptions I know that's kind of crazy to think but like because they cause them lots of grief probably but they in reality they're just kind of like feedback to them they're kind of like as much as they as we have compile time errors they have runtime exceptions they just go when they see one they just need I'll click through the app and then they when they see when they go and find the place in it is in the code and they fix it and maybe it's a little hard to find sometimes or maybe you know customers are experiencing it as long as they don't look too much like bug snag or whatever then you know it's it doesn't seem so bad or whatever a lot of times people are very much pragmatist especially are people that feel that you know they're trying to create a good experience for their customers but they're also just understand that you know bad stuff happens sometimes or whatever so anyways so let's go through kind of a nother story that it's maybe a little more successful and it's how elixir that was introduced at podium so lecture has a lot of cool pros it's functional it's a mutable side effects are okay like you got some pragmatism in there and the after pattern is built in and it's got crazy quick currency it's really fast and it also has macros which is like P P X's and that allow you to write code that writes code maybe not quite as safe turns out none of this matters to practice more or less reason and so anyways more or less like the paint we had was Ruby was expensive to scale and it was kind of hard and we're kind of looking for another language because we were kind of struggling with that and like she were supposed to be faster than Ruby and so why don't we try building something a mixer and so we did and so he built the URL shortener and it worked perfectly and almost too perfectly because we never got to write elixir anymore because they just never need any maintenance and but anyways but the fact is we when we build us URL shortner he really didn't use any of the fancy looks for features that were the selling points of elixir but we still liked it better because it just seemed to be kind of reliable and good and now we were actually the company that probably has the most Elektra engineers from go save a lame we got my call with him he's was really surprised by the fact that we had like you know hundred or so elixir engineers all at one company and so I was pretty cool for us to find out and so it really like elixir to like a pragmatist view is really like it's fast it's easy to learn we tend to have fewer problems and eventually we actually started to appreciate all those other things on the other list like like the concurrency and the reliability and a lot of those stuff but I can't kind of came later it was really just very much it's really just you know like it didn't cause us too much problems and it was and it was you know just seemed overall better so another story I also introduced a concept called event sourcing to my personal team I work this is our website and I work on this little guy it's down here it's on our website but it's also on a lot of other people's websites it's a little third-party JavaScript plug-in or a little script that people include on the website and it looks very kind of like simple and when you use it it's actually very simple as well basically when you click on the bubble it allows you to fill out a form and then it allows it'll text you to your number so that you have the company's texting line and so that it allows it kind of starts that conversation a little easier and you can even works on desktop and other other things but so but the thing is it's actually rather difficult because it has to be an iframe so everyone doesn't attack us with their crappy CSS and everything else so it's an interesting domain but more or less the problem we had was the back end of web chat wasn't scaling very well the main reason is because this was kind of our architecture it doesn't really matter so much but essentially you have website visitors on left and you have the web chat back-end that kind of like proxies request over to the slow ruby monolith that we still kind of have and then that hits Postgres eventually and it kind of goes runs back up and down the line and the problem is at the website visitors grew the ruby monolith kind of was on fire and then it was more on fire and then it was like and at this point they're like okay you have to put you basically have to put your data in your back-end and get off our ruby monolith and you know we're like okay that's fine we got thing we got other things to do though we're you know like I think it's not so on fire it's fine and then it was like crazy bad on fire and so the really like basically had to put it in our back-end and so um so at that time I had just happened to learn about event sourcing from a conference talk I'll describe it a little bit but the concept itself doesn't matter so much but essentially I learned about that my mind was blown I'm kind of like how you feel like when you learn reason and it was really cool the whole he's awesome like fancy benefits like you know databases and you could replay your data to generate new reports because you have like a immutable log of history and it was really cool for that reason and and you can create an audit trail so you can know that any user did anything at any point in time and it was just really cool but none of that mattered as is the trend and and the fact was as anyways this is kind of random but like Ram is 25 times faster than SSD and so more or less the main problem was we we were hitting Postgres constantly and we needed to load we literally have to hit a database every time somebody loads up a website on any customer website so though you added to one customer that has like you know has a million visitors a day or something which hasn't happened yet but it could happen or or traffic would spike like crazy or whatever and so we had to handle a lot of scale so Ram is faster that's kind of what it comes down to and Redis users ramp and all but also caching is super hard and so like this is like the traditional like caching kind of thing so we could just put like our Postgres here and that's kind of like our backup database Redis isn't memory and it could just like crash and throw away all its data so we have to have it in Postgres in both places so you could just write to Postgres and any time you did that you wrote to Redis and then you only read out a Redis and then you don't really know that the Postgres backup is bad until something goes bad this is actually a relatively common model but I found out that with event sourcing you actually have some cool things and basically it just could help you keep Redis and Postgres in sync and eventually you know all those other things out on the list maybe we started appreciating that later but the cool thing is it allows you to write to the event store which is just Postgres for us and then then you can read off the events from that event store and then it we project that kind of interest and then anytime that you add something today with the store it just kind of goes around in a circle kind of like you know kinda looks like you know Redux or something but except on the backend but it actually works super well and but the downside is there's only just me and one on other engineers I had to implement this and but we spent about two days just working on it together and I explained all the concepts that I've learned that's they could and we showed us benefits and we shipped it and turns out that this was taken like this is yesterday so this is our mean response time for requests and so it takes about seven milliseconds to basically load up the data that's needed for a website that's that's hitting rest so it's kind of and that's only got two servers right now and so that's pretty cool I thought another metric for people to care we get about you know two hundred and sixty seven requests or wait I guess that's yeah two hundred sixty seven thousand requests per hour again only two servers anyways but yeah so anyways that's interesting but the things that really made it interesting is just again fancy language features didn't make any difference what really made the difference was the fact that well I learned the concept and I didn't explain any of those fancy features except as necessary to people and I just showed them hey this just soldier problem and and then and then it did and then people loved it and in fact we just decided to use this concept on another project cuz we're like why wouldn't we use it this was amazing here and so but your real question you're asking is what about recent like do you sell any reason to anyone and so this is what I did and so I was trying to think of a simple way to introduce reason to my co-workers and I just made this micro service port lookup essentially all it does is you have a ton of micro servers it's probably more like a hundred or so button or but even more than that now but it's kind of hard to keep like the local host port straight and so like you're like what the heck is supposed to be running on this port this just creates a little search box that you can search for the port and it really didn't take me about long to make I just wanted to make a small code base that people could easily learn and see what reason it was about and cool thing was I just posted it in slack and I had a co-worker that reached out to me like several probably like a week or two later and just said it was amazing help to him and it helped him find out figure out what this one map was and so it kind of helped people and so they liked it and because of that the list eventually went out of date because it was just like a static list in reason and then somebody just up their own free will just downloaded it and added their own thing like that's that's somebody writing reason right there and that's not me I down there and so you know it's not a big thing but it was kind of you know it actually kind of got people interested in it because it solved a pain point that happened to exist at podium and so and so basically summarize if you solve people from people like it right if the cost-benefit analysis of it is better than you know if the pain that it inflicts upon you and the pain that it solves if that you know if you convince people that it actually just solved their problems then it can really be awesome and so I think a really good example of this is like you know the graph QL PPX or whatever like it really is amazingly it basically means that if you change your server you know all the safe stuff it broke on the front end like that's a very easy thing to describe to somebody a lot easier to describe then like variant types and like a bunch of other fancy language features and so yeah that's so if you have any questions I can potentially take them out or and yeah sorry I kind of sprung that upon you

Channel: ReasonConf

Views: 4,813

Keywords: reason, ocaml, react, ReasonML, ReasonConf, Reason Conf, bucklescript, Gage Peterson

Id: byNJSDDsE_M

Length: 26min 36sec (1596 seconds)

Published: Fri Apr 26 2019