Backend Banter

# TJ Devries - Writing Elegant Code in OCaml

**TJ:** [00:00:00] shipping to production for OCaml, mean people are using your code and shipping to production for Haskell means you publish an academic paper

All the Haskell people are just like, oh my goodness. Side effects. Don't you just want your computer to be a big black box that heats up? Why would it need to change anything in the world

​

**Lane:** tj great to have you with us. Why don't you take just a second and explain to me like why you're such a big deal. I see you everywhere the primo's obsessed with you. Te tell us a bit about yourself.

**TJ:** Sure. At the risk I guess of sounding quite presumptuous, I'll explain why I'm a big deal. That's not normally how I would phrase it, but I'll I'll roll with it. Yeah, so I've been in open source for a while working on Neo Vim primarily. I've written a lot of stuff for Neo Vim, both in core and in the plugin.

Landscape. I was one of the first people, probably the first person to push for L S P inside of Neo Vim. You can go dig up [00:01:00] some old issues about that. And I wrote our first version of the implementation, which eventually was like, went through a few ITER iterations and got merged and then did a lot of work after the merge to make it so that people can use it and enjoy it.

I also spent a lot of time doing Lua integration, so if you like some of the Lua stuff there, I spent a lot of time trying to polish some edges there to make it enjoyable to use. And then I'm also the primary author of Telescope Envi, which is a pretty popular fuzzy finder. And a lot of the stuff that we've done for Neo M and for telescope we've done on my Twitch stream, which has been really fun.

So I'm also somewhat of a, a notorious Meer on Twitter, maybe that's the other place that people encounter me. I just like to have fun and hang out with my friends there yeah.

**Lane:** Awesome. Yeah that's how I ran into you . Okay. So you just used a lot of words that. My guess is a lot of our listeners won't be familiar with listeners to backend banter. We are figuring out this backend thing, getting our first backend job. So let's start with Neo Vim.

[00:02:00] I am a terrible typist, so I've actually never been cool enough to use Vim. I've tried like 10 times. Can you explain to us what Vim is and what Neo Vim is?

**TJ:** Sure. Vim is a pretty old editor that a text editor that has evolved and gotten a lot of really cool ideas and features over, many years. And it evolved out of some. Really like difficult ways of editing code. You used to not be able to view the text file that you're editing.

You used to have to read the line and then overwrite a line or things like that, like that's Ed and things before vi. And so over time VIM came along and it introduced a lot of really cool concepts and ideas into this. Generally it's well known for being a modal editor. That's like where the meme you can't quit.

You don't know how to quit. The reason that is, is because unlike most like programs or editing experiences, when you type letters, it doesn't just send those letters right away. It has different modes. So the mode that you're normally in is [00:03:00] called normal mode. And so when you type something like J or K, you go up or down instead of J or K appearing in front of you.

So that's pretty confusing at first to people, but you get into the. The mindset of it after a while and you can come to appreciate it. And I think Vin was probably the one that really popularized that editing style. There's a lot of benefits to it like that. I like primarily the thing is you have a lot more buttons and keyboard shortcuts that you can add to your workflow without having to do 80 different control combinations.

Sorry, emax users out there. But so then Neo Vim. Is a fork of Vim. So it's not a rewrite or anything like that. It's a real fork. We share a lot of the same code and still to this day, contribute patches back and forth between the two projects. But Neo Vim was focused more on extensibility than Vim, at least at the start.

That's somewhat maybe changed in s in Vims perspective, primarily because computers have changed a lot, so it's now just like more [00:04:00] possible to still have, I think, The kinds of things that people expect from them. Like instantaneous feedback when you're typing all this other stuff that you couldn't do while running, like thousands or millions of instructions before that used to not be the case.

So there's some trade-offs. I think that Bram has changed his goal for Vim in some ways. But regardless, Neo Vims goal has been on extensibility. So Neo Vim added things like, A way to control Neo M via liker remote protocol. It has ways to asynchronously run plug-ins, and most notably, for a lot of people, it added Louis scripting as the primary way of integrating with the editor.

A lot of those features exist in various different ways inside of M or exists now, but that's like the main, you could say it's the main differences. Like for example, an easy one is Neo Vim chips with L S P support. So for those who don't know, L S P is a protocol. Originally designed by Microsoft for Vs.

and it [00:05:00] uh, and uh, it uh, it's basically like a way to solve or at least minimize the difficulties of adding language support to lots of different editors. So Neo Vim supports this protocol, which allows you to do things like go to definition, find references, rename, auto complete, all those sorts of things at the same, level as what you'd get.

In some other editors so that comes by default with neo themm and it's designed to be very extensible and changeable and override by the user.

**Lane:** Yeah, the l s P protocol in general seems amazing to me. I it's correct if I'm wrong. The idea is basically you can write your plugin for your language or ecosystem once and as long as you're following this L S P, this language server protocol, right? Then like any editor that supports the L S P can you use your plugin?

**TJ:** Yeah, basically like instead of call, like instead of calling it a plugin, I'd just call it a server. Like you write a server and that server speaks L s P, right? And so [00:06:00] then editors that also know how to speak it, then you get support for that language. It's. Slightly more complicated than that cuz there's lots of edge cases, but you can get your like 80 20, like you can get 80% of the way there, like really quickly in all the editors without having to do that a bunch of extra things.

Yep.

**Lane:** Tell me a bit about like how your career has progressed. Did you have full-time programming jobs and then you did open source? Do you still have a full-time programming job? Like how has open source fit in with.

Your career as a developer.

**TJ:** Yeah, so I do have a full-time programming job. I work for a company called Source Graph. We we happen to be an open source company, so like you can go look at my code there or like the code that other people are working on at the company. But I didn't always work in open source. I pretty much just stumbled into some stuff with open source.

At first I wanted to change something inside of Neo Vim when I was in college and. I didn't have I literally didn't know what I was doing. I just was like, copy pasting random stuff to get the code onto my computer. [00:07:00] And then some really nice people helped me in my pr and then we got it merged and I thought, Hey, that was really cool.

I just wrote some code to change something that I use every day. I like this I could do, I could see doing this again. And so then I did, and then, over time, particularly like relating to the LSP stuff I was trying to push. That to be inside of Neo Vim directly, cuz I really believed and still believe that's a huge win for the editor.

And there's a lot of mindshare and a lot of standardization you can do by putting that into core that just don't ex, that doesn't exist if you have to put it into a separate plugin. So yeah, so then I was working on that a lot and then I was helping some other people with projects and basically someone on the project asked me, Hey, do you want to be.

Core maintainer, like you're doing a lot of stuff here, you would you like to do that. It would be helpful if you could do that and review other people's PR sometimes and merge them when they make sense. So yeah, that's how I got on the Neo Vim [00:08:00] core,

**Lane:** I tell people a lot, like people that are just getting into programming, particularly the self-taught route that projects and open source are a great way to make a splash. Get known for writing good code, right? Like at the end of the day, like I was a hiring manager.

I ran a team of co-developers for a while, and at the end of the day, like when I'm hiring someone, my job is to cut through the noise and find the signal. Do you know how to write code that will solve the problems my company has? And I've always felt like projects and open source are a great way to provide all of this signal upfront before the e like the interview even happens.

Has that been your experience has your open source stuff. Helped in your career getting jobs, interviews, or just, in the interview?

**TJ:** Yeah, I think there's a twofold way that you get helped by doing open source stuff. The first one is, I think, When you actually build something, you accelerate your learning a lot. So by like actually doing you, you learn a lot more than just by reading or taking a class or whatever. Not that, those things often provide you like the [00:09:00] baseline that you need to be effective at building.

But then like eventually you need to move on to building things. And then, so that's like the one side is you do learn a lot of new things. And then the other side is it does open up connections and like it's a way in a lot of ways it's a much easier thing to put on your resume cuz you can point to something that someone can go look at.

Instead of just like saying I worked at Corporation X for three years. I was managing several projects that shipped and delivered on time. And everyone's okay, but I don't know what any of those things do or look like or whether they're still running. All I have is your side of the store, so if instead it's like, someone is out there using your stuff that you make. That's a big signal to say that you're able to ship code that people find useful, which ultimately, like unless you're writing Haskell you, that's like a goal of the company, I think.

**Lane:** Okay, so you mentioned Haskell. Explain what is Haskell, what is OCaml? I brought you onto the podcast partly to [00:10:00] talk about functional program. Could you explain your comment.

**TJ:** Yeah, so the big meme that I've been doing lately on, on Twitter to people because I've started really liking OCaml and people often ask why, why OCaml over something like Haskell? For those who aren't aware, they're both similar in a lot of Both like deep and superficial ways.

They're very similar. But the joke oftentimes that I like to do that someone told me on Twitter was like, shipping to production for OCaml, mean people are using your code and shipping to production for Haskell means you publish an academic paper. And there's Like a good nature joke that a lot of times Haskell's very focused on being in academic language, which is like very useful.

And people, I think underestimate how many things and features and language ideas were inspired by Haskell. So those are like huge wins to the programming community as a whole, not just. People writing Haskell, like people get inspired and they say, oh, that thing in Haskell is really cool. I want that in my language too.

Or I want, [00:11:00] we need to figure out how we can take this idea and do it. But but, so regardless, there's like this feeling oftentimes that haskell's a very academic language As opposed to OCaml feels very much an industrial version of Haskell. So just as a very simple example is Haskell is a pure language, which means you have to declare when something has a side effect, pretty much like side effects being oh, you print a standard out or right to a file or things like that.

I'm not a Haskell expert, so I'm sure there's some language extension that changes that or whatever. I don't know, but in, okay, will you? It's not a like a hundred percent pure. Language as in you can just write to standard out anytime you want. So those kinds of things that are like they're trade offs, right?

In that you can have escape patches, which I personally like, cuz sometimes you just wanna get something done and move to the next phase, especially if you're exploring or you're gonna delete this later, or you just wanna like debug something. You might want those sort of escape patches or imperative [00:12:00] things or writing something of mutability, but those are often they're not the default path when you're in OCaml.

So it still feels different than, you can write pure code in C, right? Or so like it would be what someone, you know could say or whatever, but. C doesn't lend itself. It doesn't make those things the easy and default thing. Whereas like for OCaml, it still feels like the default thing is to write pure functions and to use immutability and stuff.

So there's, that's like kind of an example of a difference between Haskell and OCaml that I tend to prefer for a lot of projects. The, like O Campbell side.

**Lane:** Yeah. That sounds super interesting to me. I learned a lot about function functional programming in school and over time, working on the backend primarily with data, like you could almost, most of my career is actually mostly as a data engineer. I'm taking data from someplace.

I'm doing some sort of transformation on it and putting it somewhere else.

**TJ:** Yeah, that, that sounds like a function.

**Lane:** Yeah, it sounds exactly like a function, right? For those who are listening and are not familiar with this kind of purity thing that we are talking about I'm [00:13:00] gonna do my best to define it. Correct me if I'm wrong.

So a pure function is a function that has, some set number of inputs and produces some output and it does that deterministically every time. And it doesn't affect, like other parts of the program. Like it doesn't pull in variables from like global state, make changes to them. Like all the changes that it produces are.

Effectively returned as the functions results.

**TJ:** Yeah, I I don't, I wouldn't say deterministically because like, all like side effects are also deterministic. But, Because writing a standard out is deterministic in the same way. I, I would, but so you could say that it doesn't change any state would be fine. Or that all given the same set of inputs, it will always return the same set of outputs.

It's like a pretty easy way to think about purity.

**Lane:** So like determinism is a requirement, but it like impure things can be deterministic too.

**TJ:** Yes. Like print is like print, you sure it's possible that your system [00:14:00] runs out of memory and like in the sta you, but like less, those kinds of things, which also like technically can happen in a pure program as well, right? If in the middle of it you have to allocate on the heap, but you out of memory.

Okay, sure. But those are not when we're talking about it, we're not really talking about that kind of thing.

**Lane:** So the nice thing about pure functions is like, For one, they're really easy to debug, right? Like you can write a little unit test for your pure function. You don't have to like dependency, inject, and all this crazy stuff to get it working. It's like really simple. And immutability,

**TJ:** depends, injections easier for pure functions. Because. If what you have is you wanna write something to the database, then you take like the store as one of the arguments, and then, so there's no implicit like global database that you're connecting to, you know that you're gonna write to the database because the database has to get passed in as an argument.

So not only is it like so it's possible to write to it in a functional style. But those things like get [00:15:00] passed in, so you can actually do like dependency injection a lot easier if you're into that kind of thing.

**Lane:** Yeah. Yeah. Okay, cool. And then the other big one on my mind, at least when I think about functional programming is like this idea of immutability, right? Like we are creating constant variables. We're creating constants and then we're not changing them later. Which again, can be really nice because you don't have to worry about, things like different threads, updating the same variable at the same time, overwriting memory.

But my perception from afar has always been like, okay. We have these like core tenets of functional programming and my perception has always been I'm going to like, do as much of that stuff as I reasonably can in the language I'm working in, which usually happens to be go and that tends to produce better code.

But yeah I've played mostly with Pascal and it's it just gets in the way. It doesn't let me print easily like, like disor stuff. So, So if I'm understanding correctly, OCaml Gives you or makes it the default to do the pure stuff, but the escape hatch is easier to access. Is that?

**TJ:** Yeah, and I think [00:16:00] so like for example, in OCaml you can make Structs and they're by default like the. Itself and all of its fields are immutable. You can't possibly change them, but it, you can mark certain fields, for example, as mutable fields. So this is really nice. For example, if you have a struct, like a user instruct and you wanna update, the phone number, it's dumb.

You probably would just create a new user. But like regard like regardless, right? So like the user ID, you can mark as not mutable, there's no way to possibly change. That user id, right? But you can mark phone number as like a mutable field and you can update the phone number, and that's perfectly like acceptable.

So that's like an example of a escape. An escape hatch, right? Where you can say like in general, by default, when I just write a struct, every single field is immutable. You can't say that and go, right? If you want the field to be accessible outside of your current package. Then it's public.

**Lane:** right,

**TJ:** Okay.

And then it's not super clear, sometimes when you're [00:17:00] passing something around and go, if you've passed it by reference or by value, right? So then all of a sudden you thought you updated something and some like receiver, oh, but oh, I forgot to change the receiver to take it by reference. So now I updated it in here and it didn't actually change anything.

And then, oh my, and then right now you're like, Trying to figure out why your updates aren't syncing between your go like instructs and then you're sad, right? But like in OCaml you can't have that problem. Like you just either return a new one, which is good, or you can mark certain fields as mutable and then you can change those.

That's a really powerful construct at the language level and like by def default. And the other cool thing is you can look at the type and you can just tell what things can change. You don't have to go see what functions are available to you. You just go look at the structure and say, oh, Phone number's mutable, but the other ones aren't.

Cool. Now I know. Or none of 'em are mutable. You're like sweet. None of them are, none of them can change out from under me. As soon as I know one, then I, or as soon as I know this value, it can't change, which is really like very helpful. The thing that I like a lot about these concepts is it makes it much simpler to reason about [00:18:00] as well.

So like when you're dealing with, if you have like, A uh, like a list or a slice that gets passed in go, right? You don't know if the caller's gonna change your list.

That kind of sucks. That, that you like have to go read all the code. You know what I mean?

**Lane:** I just got finished writing like an exercise in our learn go course. That's like, okay, here's this append function. You need to use it in this way all the time because if you use it this other way, like bad things are gonna happen. So just never do it. But like the language doesn't enforce that, right?

You could, you can do it the dumb way.

**TJ:** And there's no way at like the type level to tell yourself whether that's gonna happen or not. So like in Rust, it's pretty nice that you can know whether something that's getting past a function can be mutated or not. Do you pass a mutable reference to it or do you not pass a mutable reference or do you pass it completely?

And by value, those are all like must do. Pipe level things, not convention, not read the function name and hope that it's not lying to you. The compiler [00:19:00] tells you for sure whether those things are right or wrong. Now, that adds some overhead. That's more learning. There's some other, there's some other trade-offs that exist.

Between that strategy and like in go, I recognize that, but the, it's so much easier to reason about when you know for sure and you look at a struct, oh, I can't change these fields. That's really good feeling. Or I can't change this list that I passed in. It can't be changed. And compilers also like that knowledge too.

**Lane:** Yeah. Can make it more efficient. I, so I feel like there's this gradient out in the programming language world of you have like really strict languages that like don't allow you to do frankly, dumb things. And you have languages like JavaScript that just allow you to do any old thing. And so as a go developer, I get to dunk on JavaScript a lot, but now, like I invite you on the podcast and I get to get dunked on by OCaml so

**TJ:** and all the Haskell people are just like, oh my goodness. Side effects. Don't you just want your computer to be a big black box that heats up? Why would it need to change anything in the world? That's, so we're all getting dunked on in a big circle, and then the [00:20:00] JavaScript guys are getting, they're dunking on the PHP guys, but then they're all laughing at us because they're driving Lambos, so it's all the

**Lane:** Lambos. Exactly.

Because it turns out we can make money writing to terrible programming languages.

**TJ:** Yes. Yeah, it's true. It turns out people don't really care. They want the, their problem solved. Yeah.

**Lane:** Yeah, exactly. Okay. I think like when I was in college, it was explained to me by a professor, like I write c plus plus. Because it gives me so much power. I can do anything. And so when I was in school I thought, oh okay, the best developers use tools that just allow any old thing because they're so good that they can write, safe, fast performance, clever code. Like my thinking on this has completely flipped. It's no in, in production. I want tooling that actually restricts me as much as possible from doing really dumb stuff. The example I use in Go is like error handling. So one of my pet peeves when I'm working on JavaScript code is I don't know if this [00:21:00] function throws or not.

Like how do I know from the function signature if I need to wrap this in a try-catch if this is a safe function to call. Whereas in go, even though it's not like I actually do really like the way rust handles errors, at least go, makes me think about every single error and it's verbose and it's annoying, but like I know that I've handled.

All of my errors, whereas in, in JavaScript that's not the case. How does this work in OCaml land? Do you get that same feeling of when my code compiles, I'm reasonably sure that I know where the faulty stuff is.

**TJ:** Yeah, so there's in, in OCaml it has exceptions, but most people write code that doesn't use exceptions. So like in general, OCaml uses, actually I should say Rust, uses the style that OCaml has because Rust was first written in OCaml, so So there's a lot of inspiration in the rust world from OCaml.

Like in general, you would write code that returns results or options in OCaml, which pretty much just means that instead of [00:22:00] returning a value, you return something that holds a value or an error. And then to continue operating, like on stuff you need to handle both cases. So you would, you can use a match statement and you can use pattern matching and all that good stuff.

In OCaml, very similar if you've seen it in rust or some other languages as well. That you can do that. So in general, most people don't write code in OCaml that uses exceptions because it's not very like functional style. But it is nice that for things that basically, once again this is like an escape hatch thing.

It's nice for something that like is very exceptional. That could happen where you could just raise an exception and basically crash out of that thing or out of that thread or whatever it's going to be. And then that's okay, and you don't have to manage all the additional like results and options in all the other places where it's oh, I see that we're not gonna have enough memory.

Or it timed out in this really weird way or something will raise an exception. [00:23:00] Because it's actually exceptional, not just like it failed, right? Because it's pretty dumb when you know that a function can fail pretty often. For example, like reading a user from a database, when you're given an id yeah, it could be nothing, right?

Like it could, you might not have this user.

**Lane:** Yeah.

**TJ:** That's not an exception. You know what I mean? That's just yeah, there's two possibilities and it's pretty likely if you just send me a random ID that we're not gonna have this id. So then in that case, you would return an option, right? And so then there might be some user or none, and then, okay, we will force you to handle that case, like both cases.

**Lane:** Yeah. Yeah. Okay. No, that makes sense. When would you not, I, is there a case where you would not use OCaml? I know you're really liking it right now. Like what are the trade-offs in the real world? Where do I write OCaml code?

**TJ:** Yeah I'm still like exploring that myself to figure out where I think like the best places to use OCaml are. It's quite interesting because there's a lot of projects in the OCaml [00:24:00] space right now that let you do really cool stuff. So one that I was just playing with last week's called Alanche, which is like, The spice from Dune, but it's also mixture, in French.

So the build tool for OCaml is called Dune. So if you see like random dune references that's why, I mean it's, I think it's called Dune, because OCaml is like camels, right? So they're walking in like in dunes, but regardless. But people are like, dune. I really like the book. Which I do too.

It's a great book. Or series I've already read the first one. Sorry. I know I'm gonna get yelled at now. It's a series. There's more than one. You're just a filthy casual. I'm aware. Okay.

**Lane:** everyone go dm, dj, and

**TJ:** Yeah, exactly. Dms open. Go complain about it. I also liked the movie, so there you go. Huh. I'm a filthy normy.

I get it. But. But there's this project called Melange, which lets you write OCaml code and it gets compiled the JavaScript, so you can like literally just write OCaml and then you could put that into a JavaScript project. Like it'll just, it'll go there. There's [00:25:00] also other projects like, I think they're called Reason ML and Rescript, which will let you like write OCaml syntax, and then it gets compiled to JavaScript as well.

So there's like some interesting stuff going on where people are writing OCaml or OCaml ask code for even front end stuff. That I think is like gonna be really interesting to see where some of that goes in the next few years. Because I like the type system for OCaml. I don't like the type system for type script.

Like I think type scripts, type script or like type system is like really weird and you can lie a lot and you can cheat and people write code. That relies on exceptions or relies on other things, and so then you don't know. I'm not a huge like fan of it. I feel often I don't know if things are gonna work or not.

Whereas when I write Oak AML and it compiles, I think, oh, not I'm pretty sure it's gonna work.

**Lane:** My, my feeling about TypeScript is like I, I like it better than JavaScript, but I really hope it's not the future

**TJ:** Yeah. Yeah.

**Lane:** it is. It has inherently bundled all the [00:26:00] garbage that I hate about JavaScript into the language. Like by nature of being a super set

**TJ:** yeah the trade off was that they wanted it to be JavaScript, right? Which is like a pretty good idea, like from their perspective, even if I don't, enjoy writing it all the time. But so there's some stuff that's pretty interesting in that space, like for OCaml, where you could write basically like full stack OCaml.

And your front end is also OCaml and you're sharing type system and types and all this other stuff. That's a really cool,

**Lane:** Camel's everywhere.

**TJ:** yeah. Ca just camels on camels,

**Lane:** Camel's all the way down.

**TJ:** But that stack's gonna be a lot slower to develop in today just because of the inertia and the tooling and a bunch of other stuff in like the JavaScript space.

Like you can just log on to next JS and just have a website up in five seconds and installed 30 N P M packages that do all these random things for you. And then sure, that's maybe not The, your end product, but maybe that gets you your first thousand customers. And I'm like still over here.

How would I access a database most effectively in OCaml?[00:27:00] So I think, there's some trade-offs there, but in terms of things that people do use OCaml for a lot it's really good for writing. Other languages, which is funny. So there's a lot of languages that at least had their first implementation.

In OCaml, it's really good at writing parsers and other tooling that like needs to handle a lot of cases. But also,

**Lane:** Neo Vim plugins.

**TJ:** yeah. What.

**Lane:** So Neo Vim plugins, right?

**TJ:** Yeah there is a way to write neo plugins with it, and I might explore some more of that later too. But so basically there's it's a general purpose programming language, so anything that you could write like a backend for you could do that.

And there are people who are writing whole companies like. In OCaml. There's also lots, some really like very popular projects like sere, if you've ever heard of sere, which is like basically a way that you can search for vulnerabilities in code,

**Lane:** Oh, okay.

**TJ:** that's written in OCaml. Yeah,

**Lane:** grip. Okay.

**TJ:** I think it's Semantic Press grip, but yeah,

**Lane:** Oh, okay. I guess

**TJ:** I don't remember offhand, so don't quote me on that.

There's other [00:28:00] tools like combi is a really cool tool that lets you do syntactic grip. So it's like a way that and like search and replace. So it's a really powerful tool for doing that. And that's written in. Okay. So there's lots of things, there's like a huge range of what you could write it in.

I'm not a hundred percent necessarily sold on you should put your whole company on this unless you know you're not gonna do it or be motivated to do it because you're frustrated by problems and other things. So I like, I'm not super interested in launching. A product in like TypeScript, JavaScript land because like I don't have any fun with it, so I know I'm just gonna stop.

Which maybe that's dumb. Like maybe I'm leaving money on the table for myself. Certainly. Because like I certainly could launch something. But I'm not gonna finish it cuz I have other things in my life that I enjoy more like,

**Lane:** Yeah. Honestly in my experience It like it takes a long time to get any products like up and running and working and making making revenue and if you're not having fun, like that is actually a pretty [00:29:00] huge failure case.

**TJ:** Yeah. People don't really like, often wanna grapple, I think with the human side of these problems and the fact that, like you said, if it's gonna be a year and a half of you hacking, by yourself, at nights or on the weekend occasionally, or when you've got a spare hour if you're not having fun you're not gonna last a year and a half.

It's just not really realistic. So I'm not sure I'm still exploring it. I like OCaml is definitely like a general purpose language. You can write. People have written a huge range of things for it. People even, you can even write hardware in OCaml, like it has a way that you can output vhdl or Verilog.

So like you can go all the way from writing custom stuff for your F P G A to like a React front end. You can do all of that in OCaml.

**Lane:** Okay. That's pretty cool. All right, so now we're getting to the part in this podcast where my secret motivations are revealed. And I actually brought you on so I can get some free consulting in regards to oak. OCaml. Okay. So I'm a huge fan of the, I let me back up. BD Dev is a place to learn backend development.

And [00:30:00] our approach is you have to actually work hard and this is going to take a while, as opposed to this is an eight week thing and you're gonna be making a hundred K next year. I'm really interested

**TJ:** Isn't everybody, I thought it was in a whole year. Don't you mean six months? You know, like,

**Lane:** Are getting paid.

**TJ:** yeah. Right. Exactly.

**Lane:** Yeah. So like, this is gonna

**TJ:** too real though, since we talked about open source,

**Lane:** yes. Okay. I'm sorry to hit you where it

**TJ:** Yeah.

**Lane:** So this is gonna take a while and I'm interested in like actually producing really good developers, like at the end of this learning path. And so while I fully recognize that you don't need to be an expert functional programmer to get a job as a backend developer it'll actually be a lot easier if you do understand this stuff.

And I think you'll stand out a lot. I want to redo my functional programming course. And you just mentioned like the most interesting thing to me, which is that there's this thing called Milan and I can compile OCaml to JavaScript. So the way BD dev works is like all these languages that you write on the platform, it's an interactive coding thing.

I run them on the front end, so I either compile them to web assembly or JavaScript, [00:31:00] depending on the language. Is OCaml a good choice for my functional programming course?

**TJ:** I think it's pretty nice. One thing that's cool about it is like, because it has a mix of like pure functional aspects as well as like you can write imperative code. It can be nice to write, I think like a side by side. Cuz you could like literally write it in the way where you use a for loop and then you're like that's how you would do it in a for loop.

How would we do it with a recursive function?

**Lane:** Yeah. Okay.

**TJ:** like how would we do those two things? Like how do we make list dot map, right? Let's write it. The first one is you make a list and then you keep append to the list as you're iterating through and you're calling F on each function.

And then you return the list like, that's cool. Okay, now do it recursively where you match against the head of the list and you call F, and then you. And then you like talk about Taylor Recursion and how the compiler knows how to turn these into the same thing. But now you're it's like that's the functional style, right?

You can you can play with that. Last time I checked, I, I think yeah, like you can actually go on [00:32:00] autoaml.org/play right now and you can run OCaml code, like

**Lane:** Ooh,

**TJ:** just straight up. I don't know exactly how they're doing that, but like they, they have it. You can write it, you can,

**Lane:** can be done.

**TJ:** Can be done is being done currently.

Yeah, so that's really cool, I think. So I think that lends itself well to that style of you wanna learn it, but, and you're familiar with more like imperative traditional backend languages. You wanna compare them you can actually just write both versions in OCaml and then you can also start to, in my mind, See the elegance of the functional style, right?

Where you like are just constructing these things with immutability and you're just passing around functions and all your inputs and outputs and you create these STRs. And Okayl also has some really powerful things with modules that are really like elegant, I think, and very cool. It's one of, its like primary features.

So yeah. So I think like all of that stuff is very cool. And could be done like quite iterative [00:33:00] iteratively in the browser. Yeah.

**Lane:** I love it. Okay, one last question. Is OCaml, as an ecosystem like growing, does it have a bright future?

**TJ:** Yeah. So I think so I'm still new in it, so like for me, I find out new things all the time. But there's some really big companies that use OCaml, Meta uses OCaml for a ton of stuff, and like for things that they're not gonna drop anytime soon, would be my guess. Like a lot of their, like Python tooling,

**Lane:** It's not meta

**TJ:** I think it's fire,

**Lane:** gonna be shut down next month.

**TJ:** is it?

**Lane:** No. Google Stadia. I don't.

**TJ:** Oh yeah. No. Yeah. But meta, they've got pire I think is theirs. And that's a lot of it's written in OCaml or they've got like hacks, which is their, like language that compiles to a bunch of other languages or something like that. That's also written in OCaml. So Okay. There's at least one huge

**Lane:** Very cool. Yeah.

**TJ:** spent like many millions and millions of developer like dollars on that.

There's also like Jane Street, which is a really like large financial firm that does all of [00:34:00] their stuff in Camel and they help push the language forward. Okayl just released Okayl 5.0, which has this really powerful idea of effects. Which they're called algebraic effects, I think is the right way to talk about it.

But it, it's like a generic way. This is gonna be super simplified, like a generic way of building into the language, the kind of thing that you would do to write async a weight or try-catch or, so it's like a larger, more generic version of those things. And now that's built into the language so you can write your own effects, which is really cool.

And you can like, So it allows for a really powerful code and it's super high performant, like multi-core stuff. And because the type system, it's really powerful and has all this immutability and things like that, you can prevent a lot of data races or not have to do as many MUEs. So, So that like just happened not that long ago.

So that's a really big thing and it's been in the works for a while. I've also seen some really interesting stuff that's just like in the works. So like people are developing new features [00:35:00] still for the language, like these concepts of linear. Types or like global and local types, which is it'll look very similar to some of the things that you see in Rust where you assign ownership to something which would let you basically so OC camel's garbage collected we didn't mention that, but, so you don't have to manage your memory, but sometimes you would like to tell the garbage collector like reuse this memory.

For this thing, right? I'm gonna call list map. But instead of creating a new list, like just literally override the old list cuz I'm gonna consume that previous list and it's no longer gonna be there. So don't allocate another list of memory, just like reuse it. You could do that with the type system and it doesn't the garbage collector eventually, like the al allocator eventually can become sophisticated enough to handle those things.

That was something that I just saw recently that has me pretty. Excited for writing. Like really performant OCaml for the parts that you need to, that's one of the things that's difficult, like about rust, is sometimes it feels like, man, I don't really wanna have to think about [00:36:00] memory for this huge chunk of the program.

Like this huge chunk of the program. It just doesn't matter. Just act like a garbage collector please. And just copy it. It doesn't, it just is fine for

**Lane:** the like critical path

**TJ:** Or like I'll come back to it after we actually figure everything out. Like I, I don't even know if I have the right structure yet and I have to go add lifetimes everywhere.

And you're like, oh my goodness, I have to go do this. And so then that's like annoying. Whereas it would be like nice and you'd be, I feel like, be able to move more quickly for some of these things. If you could just have effectively like, I think there's a huge space open for rust with garbage collection as like a language which in some ways is like what Camel has.

Although Camel has, like a lot of. Historical things, blah, blah, blah. So maybe it's not that language. That's fine. I like it. But so all that to being said, like I think there's a lot of interesting stuff going on in the OCaml world with like real companies using OCaml and there's like also some companies that you'll run into, like a HFS or a few other ones that I've seen that are like full OCaml stacks where [00:37:00] they're shipping.

**Lane:** I was listening to a podcast from their owner talking about OCaml, like now that I remember. Yeah,

**TJ:** Yeah. Yeah. So there's a lot of people interested in the space. I don't know, like I said, I don't know what's gonna happen with OK Camel. I don't know what I'll do with OK Camel in six months or a year. I'm just finding a lot of the concepts like very helpful and interested, and I've learned a lot of new ways of thinking about programming by learning OCaml.

So that makes it fun enough for me to keep on doing it.

**Lane:** Amazing. I'm gonna be spending the next couple months at least looking at. Looking at OC Animal a lot more seriously than I was. So that's pretty cool. Tell everyone where they can find you. You're a streamer. We haven't even talked about it. You're a YouTuber. You do code in front of people.

Plug your stuff.

**TJ:** Yeah, I'm uh, t dv, so t e e j underscored dv. Unlike all the major, social media places. The only social media place I'm not, that is on GitHub, where I'm Tre. Because GitHub is social media and yeah, so you can [00:38:00] find me there. I live stream a lot on Twitch. We do coding stuff on Twitch all the time.

I'm usually, Like building something. We don't do a lot of, not building stuff on Twitch, which is pretty fun. And yeah, I also pu publish YouTube videos mostly about neo om maybe some stuff about OAM will coming up. We'll see. But I'm I just published whatever I feel like on YouTube.

**Lane:** It's the best way to do it. Go Check out TJ's uh, YouTube, Twitter, check out OCaml and Neo Vim. Thanks so much for coming on the show, man.

**TJ:** My pleasure. Thanks for having me.