 Okay, so I want to welcome everyone to this month's meeting of the Houston functional programming users group. And before we get into our talk today. We have Blanca Gonzalez from Microsoft here to talk about the teals program so Blanca this is your time. Okay, thank you so much. Hello everyone if you just joined stand up. Oh yeah. There we go. Okay, great. Yeah, I'm kind of sure. That's the camera here. Okay. So hi everyone. I've joined you know if you just joined I'm Blanca Gonzalez. I am a former computer science teacher. And I have been out of the classroom for a year I now run the tools program for Microsoft here in Houston. And what the, what the tools program is is we pair industry professionals people such as yourselves with high school computer science classrooms. We want to make sure that students that are learning computer science, get a chance to meet and interact and learn from people that are in the industry. As a former computer science teacher I can tell you that no matter how many times I told my students that learning computer science is something worth their while. They never clicked in their head until they met someone that was, you know, from, you know, improving or or from Microsoft. And it can be anyone from it from any, you know, IT department to come into the classroom and tell them hey, you know you're learning, you know conditionals you're learning loops. This is stuff that I do at my job every day it actually is something that you will work with so what you're learning is definitely worth your time. So, if you know anyone that likes to work with students. If you would like to give back. You know it's twice a week for about 45 minutes at a time and it's before work hours between the hours of 7am and 9am. And you can do remote or you can you can come in person to the classroom and make the difference in the students life. So, yeah, that's all I have for today. If you would like to contact me. I've given Claude my contact information. You know, ask me any questions I'm here to, to answer, you know, anything that you know you'd like to ask me about so I'll post your contact info on our website. When we post the video. Sounds good. Thank you. Thank you so much for your time everyone else. Great meeting you all. Thank you. Okay, so today I want to welcome Jonah Bedford to the group. As you all know, I use OCaml myself a number of years ago at this point, at least from my perspective, Jonah sort of exploded onto the OCaml scene. Things with OCaml is, it's, it's always been very unix centered and its windows story is not great. The core OCaml works fine but the environment ecosystem is not very windows friendly there are some problems with the core OCaml as well. And Jonah sort of came on and he had a post he's like, I fixed this. And since then, his participation in the community, he's one of the people that when he speaks I listen. And I don't think we actually interact that much online because he's doing stuff far more sophisticated than I am. But yeah, he's one of the people that I'm always going to pay attention to. He's super nice super kind and but also just incredibly clear when he's either asking questions or giving answers or providing advice or whatever it is. He's a huge member of the community right now. And so I'm really excited to have him here. And as I mentioned that we're both on the program committee for the OCaml users and developers group attached to ICFP the International Conference functional programming this year and it'll be in Seattle he's in Seattle I'm planning on going to Seattle so we'll actually be able to hang out in person. And I'm looking forward to working with you. So, now it's when turn it over to you Jonah. Okay, well I thank you for that introduction that hope I can live up to at least a third of that. Okay, so let me see I'm Jonah. And I'm going to kind of give a, a story about what I've done over with OCaml. I'm going to be using a narrative arc and that actually means that I'm going to go through acts as if I'm writing a story. So my first act I'm going to be coming along and setting the scenes I'll be introducing sort of myself and the company that I started basically answering the question why am I even talking about OCaml why did I why do I even why did I even use it. All good act ones have start sort of introducing some some conflict and you're going to see that in the beginning of act one, and then act two we're going to see the conflict really really blossom. And you'll you'll you'll you'll hear about how OCaml in Windows. How I a lot of challenges with it and what got solved there and how I grew in change in response to that. And then finally, all good books they have this act three happily ever after I will come along and give a sort of a broad view of the status of OCaml status of what I'm doing over on Windows, give a couple brief demos but that's not really the point of the point of all this. And then finally what remains. So why don't we start out with that. Let's go into act one right now. And setting the scene is me. So, we're in a functional users group and what functional backgrounds did I have when I started out with OCaml. So, you know, I've been in touch on 20 years ago. I happened to work very briefly on the window side of chicken scheme. And I don't know how many people are familiar with that but I have chicken scheme out there. I'm sorry, did you hear that. Oh yeah. Yes, I remember chicken scheme. Yeah, okay. So I briefly worked on the window side, and also the, the swig side I think that's still actually around the, the interface to see. But I was very brief and that was it 20 years ago. And all the languages of sort of use since have just been the sort of dominant languages. So, in the, in the 2000s, I was predominantly in the fraud and the credit analytics industries. So that was lots of data, lots of security with that data because it's credit and fraud. A lot of machine learning. The consumers are generally work with telecom companies credit card issuers health insurance, those sort of the big people who need the fraud and the credit. And my environments were C and Java, in terms of the programming languages and then back in stuff. So, I'm going to take Solaris IBM Linux, and I only use Windows for GUIs and one of the things that you're going to, you're going to hear through this is, well, you're distributing OCaml on Windows. I'm not a Windows expert. I'll explain about why I actually ended up going and doing doing Windows but I am absolutely not a Windows expert. And then in the actually before the 2010s I joined, I joined Amazon. I sort of work sort of in the same kind of areas I did fraud. I did data warehousing sort of the data background, and I ended up going over to computer vision that was sort of a natural segue from machine learning. I ended up as a principal engineer over there in the, in the Amazon Go department. Amazon Go is the just walk out store. So heavy CV slash AI. And again it was a lot of data, a lot of security, and a lot of machine learning and now some deep learning. So my programming environments back then Java, C, JavaScript slash type and Python. And just like probably most people, the transition happened from Unix over to Linux and I followed as well. So Linux servers, and even in embedded hardware you do for computer vision. So I had even less Windows. And that I had before, I'm still doing Windows but it wasn't as much as I had before. I think right now is a sort of a natural time is I'm just going to comment that anytime that I say something I go too fast, just put up your hand raise a question I'll go I'll go answer it. Unless it's like a really long question then I will, I will punt it towards the end of the, the talk. So in 2020, I've been over at Amazon for 12 years. But I decided to actually leave Amazon shortly after the George Floyd's incidents over here. I started a company called the scuff. I wanted to take the things that I had from my background. I had basically spent 20 years doing data security computer vision. And I wanted to make a suite of personal safety products that combine both hardware and software. One of the things I sort of identified really quickly as I was kind of going through some of the designs of the products was I haven't released yet by the way, was that I needed to have some way for people to communicate with each other and it, having a lot of requirements that I couldn't find readily available in the, the industry whether open source or commercial. So the first product that I really decided to build was chat. My version of chat, but chat. And I started out by forking signal, the single messenger. And so I forked the front end and the background so I had my own back end servers. And I ran into some problems. One of the one of the major ones that I found when I was when I was forking signal was they had no server code. And they decided not to release any server code for over a year while they were trying to not reveal that they were developing a cryptocurrency mobile coin into their into their application. So I worked around that. And one of the lessons though that I got out of that was if I'm going to come along and ever do something called open source I have to make sure that it's not just release code and infrequently go and maintain it, actually make sure it's actually runable by by users and maintain it as well. Also, after that, I, they had the signal app has a high velocity of change. So, I was forking it, and they had a high velocity of change and it was really really difficult at first to keep my fork in line with the, with the changes that the signal was actually doing. So, I ended up developing some tools over in Python. Okay, I'm always not even a part of the vision yet. And to maintain my code in line with a, the, the stream of changes coming in from signal. And I got another lesson out of that which is, if I'm going to go do something. I need to make sure that I don't have to go do this again, I don't want to have forking forking is just way too high cost, especially at that point I was by myself in my in in discover. So, you're going to see that sort of later on as I as I kind of started talking about some of the windows tooling that I do. I did with okay. Hopefully, and this is a big one I'm going to spend a little bit more time about this. That front end code that the actual app itself was very lock heavy lock mutex. It was Android which is what I just started out with so it was Java slash Kotlin code. Very, very lock heavy and actually that caused messages to be lost in ways that were weird so I'm going to kind of show a little bit about what what what I mean. One of the reports that I had actually filed over with was signal was based was was saying that I'd send out a message, and it took an hour for it to be received by other people, and other people reporting the same things, but what you can do to get around it was just go and put your application in the background put it back in the foreground and help pops a message. If you had it done that that you don't see any message. And as I'm alluding to the central causes for all these is locking. And so what you do with on your phone is you'd have somebody go and register their phone over with signal. And once they've registered they go send a message. After that, the other person goes and accepts hey this is a new person. They reply a message back to you. And then you just wait. You wait for hours and the message just just doesn't come through unless you come along and you flip your app your app in the background and back to the foreground you close it. And there's a cute little picture of dog have to have a big picture of a dog waiting for some response from from their blush owner. And where did that go I'm missing something here. Oh. So, the question that I was building a fork of this, and I was asking myself, like, how do you actually know that you're not getting your messages. You could be out in the field actually having to support this, you, you, you go and release this to the public, and you have no idea that people are losing their messages. And, and yeah, so that was sort of my central question, and I ended up actually doing a little hacky solution to it. It's, it's if you're familiar with Java at all you're going to understand what I'm doing here. I'm just notifying the monitor locks that they should unpause themselves. So it ended up being a five line hacky solution to a really, really broad problem over in the signal application. And that hides the complexity of how hard it was just to deal with locking issues in that one application. So, just, I'll just briefly go go go on on this. So, this is sort of like the normal code that they had. And you have synchronized methods over in Java synchronized keywords synchronized keywords, you have a loop that's just waiting for some condition to be met. In this particular case, they were asking for five conditions make sure that they were met, but the code was not guaranteeing that all those conditions were like whenever any of those conditions change that they actually went and unblocked this weight loop. And I was forking my forking the code and actually adding more behaviors on top of it so I ended up in this in this weird thing where I have locks in and ready in an application, and to introduce my own behaviors my own layers of abstractions I had to put more locks in just so that I can continue interacting safely with with with the apps. And ultimately, because I had to keep on acquiring these locks, which you have to do in front of an application because you've got events coming at any point in time that you can, you can order, you end up having to put more and more locks into your application. And when we get to a camel and talking about the decision making for this is this played a big part in why I decided to sort of scrap some of the languages that I had known already, and pick other languages. So I got a lesson out of that, which is avoid locks at all costs, and preferring cooperative Freddie for shadow. Okay, so I went I got through those problems I had an alpha launch of my of my heavily heavily customized application chat app. And it's all the problems but I was limping over to the, to the starting line there. But at the end of the day I had six months into it, I had a demo available I can start collecting some feedback whether or not it worked. And from a startup perspective because I will start up with that particular point. That's a great timeline or six months in you got a product you're starting to get feedback that's a good thing. So everything's not are going rosy. And I had made sure that was over on Google Play Store. I was in their alpha testing which is an invite only kind of mode that they have. I'm getting some good feedback in terms of what what it actually built. But that was just before I was about to release a public beta lines and I did say I was set this out in acts and act to is about to happen so that was the seeds of conflict and we're about to see where the real conflict is actually coming from. So active Google enters the picture and Google sends me an email on May 9 2021 saying this is a notification that your Google Play publisher account has been terminated. Wow. This is not a lovely thing to to hear Sunday night. And what you don't tell you is that they locked out the entire Google Google Cloud account. So it wasn't just the play the play the Play Store, but all the databases and compute and whatever I had over in Google Cloud was completely locked out. And they told me the reason at least what they considered to be the reason which is there's some violations of some agreements and they outlined it in some previous emails they sent. Just the reality of it is they didn't send any previous emails that's just a standard form letter that they had sent. And yeah, they didn't give an explanation about why they terminated. So they gave a little bit of an out. If you've reviewed the policy and feel this termination may have been an error. Please reach out to one of our policies for team so obviously I'm going to do that because it's really the only option available and they make it clear that's the only option available because we will not be restoring your account at this time so it's the only option that I had available. Um, so I did do that appeal. Sorry I just want before I move on to the next one so just make note of the date it's May 9, 2021. I sent out an appeal. And this is literally what I wrote I didn't write anything else I have every reason to believe that the app is in full compliance with the policies and the agreement. But I've received no indicate email indicating what the policy violation was. Instead, I received that thing that you just read. However, I have not received any prior violations and any previous emails. And that was it both. So, how long did I wait for response one month, exactly one month later so May 9 is when I, when they terminated, and then June 9, they send me a message back saying high developers that discover just me at that point. Thanks for contacting, and then give some generic thing about due to due to work schedules at this time you may experience longer than usual processing times. This is a month by the way. And after further review we've accepted your appeal and reinstated your account. And at this point I'm just like what what what what is what is happening here. And they go on a little bit further. But the thing that I caught my eye a little bit was that towards the end they were saying, kindly keep in mind that any new policy violations may result in your accounts permanent termination from Google play. I was definitely, definitely just overcome. They were so kind to me that after 30 days, actually 31 days, they, they, they, they were, they were going to permanently terminate my account. So, I looked at that, and I had three things that that I was looking at one has got no warning. Two, I had no explanation in three. I had a business inaccessible the thing that I actually developed was inaccessible for a full month. And I was putting my name behind things that what I would be deploying products in the field personal safety products and safety sort of the key word. And I couldn't imagine myself actually doing that, and putting my name behind something and then having it just take it off the market for a month with no explanation. So I just developed at my point in time just never grand this is never going to happen. So, I ended up with some requirements and my little heading here enter okay I can't let's come into this picture now. When I'm writing a web application, a mobile application I need to make sure that I have some way of which to easily switch over to a web application of a vendor ends up messing with what I'm with what I'm doing. So that was sort of my central requirement I needed that way just quickly just come along and and have a fall back in case something, something like that happened over again. In addition I had my own personal technical requirements. I wanted to make sure and it was hard for me to characterize it at this but if I was adding a new piece of code like a new thread, it didn't have to come along and worry about its side effects on all the other code. And I wanted to make sure that now especially that I've spent so much time, and then have it possibly taken off off the market that it was very quick for me to deploy the rest of my products over to where I wanted to go embedded devices for the division desktops and iOS which I haven't deployed to at that point in time. And last, because it wasn't that I am in a personal safety space. I wanted to make sure that it was easy for at least the parts of the software that I was developing that I really needed to care about that I could prove that it was actually safe. So those are my three sort of top requirements that I actually had it on top of making sure that I had a wet back end that could complement a mobile app. So, let's just start with that first one which was my never again reform and just being able to start jumping real quickly with the question. Absolutely. What, what are the, the personal safety applications that you're looking at developing my products. Yeah. Yeah. So, I haven't released them yet I'd love to actually talk about them when they're actually released. So, but yeah, I'll say the space in which I come from computer vision data and security. I think you could probably get some picture of what I'm doing in that space. Okay. Okay, thank you. So, yeah, so this was this actually particular requirement about a bill to switch over to a web application was when it down a lot of the languages ended up just really ranking. So, JavaScript obviously it's it's if you if you're on a web application you just use JavaScript, but you can also use JavaScript on the mobile apps and some other domains as well. At this time is when I actually figured out that OCaml was actually a really good option here for generating JavaScript code. And last, which is just generating WebAssembly from residency. So there's more options in there but those are the three top ones that that sort of appeared to me so that drastically went down the field, and I, I focused on those. I had my own personal requirements that I that I went through so I focused just really on the cooperative fretting and JavaScript and OCaml came up in the top there. See obviously doesn't have that at all rust has some ability to do it. I'm not written a line of rust code, but I had done a little bit of research, and it seemed, at least from my outside perspective, that it was going to be difficult to do a single-threaded tachio. And my second requirement was be able to deploy to a bunch of different targets, embedded devices, desktops and iOS and mobile. Here is kind of easy. Rust and C are sort of the ones where that's pretty easy to do. And I was really focused on the, at least for this part anyways, like what is the things that would impact me in the short term and what is the things that impact me in the long term. So I didn't really see any blockers for residency. I saw obviously a blocker with OCaml. I had to learn something I didn't know anything about. And JavaScript had its own blockers. It's basically because it's not sort of natural in all those environments in which I actually wanted to target. And then last, and this probably showing you, I put OCaml way down at the bottom and you're going to see why here. The long term impacts of choosing a particular language. I didn't see very much friction with just keeping C. The long term sort of drag that I'd have with JavaScript is I'd have to worry about interrupt between JavaScript and whatever, like Swift or embedded sort of API you need to deal with that was a drag. Rust again I hadn't written a lot of code but I just heard that it was harder to write rust over time relative to most other languages. And then there was this drag with OCaml, which is like if I'm if I'm getting to a point where I'm certainly hiring people. I would have to deal with the fact that there's very little supply of OCaml engineers. So those are that's how I ranked it out for for OCaml. And just a slight little segue in terms of the rest thing that that sort of impression that I had from my research which was just really looking at mailing lists and things of that sort. There's actually a roadmap for rust in that they talk about for next year. The typical onboarding time for rust engineers, it's around three to six months, but even so, many people report using having a high cognitive overhead using it and a long term. So, I think I feel like kind of indicated a little bit that my research wasn't in vain there. But it it it I'm not going to like knock it it has it has its it has its benefits. And then last, my last personal requirement was being able to prove the software that I developed is safe. And the OCaml actually just came up pretty bubbled up pretty top quickly up to the top. I had not heard about cock and some of the other tools that OCaml is very similar to what the word is in harmony with. But yeah so OCaml come up bubble up to the top it was a GC language so naturally it's memory safe rust obviously is memory safe as well in a different way. In addition, it has resource safety which is sort of an undersold thing for rust I feel and then sees down over at the bottom. So, I ended up doing my little framework, and I had all of these different languages and considerations and nothing was really coming up to the to the to the forefront. What I did was sort of evaluated whether or not some of these things were soft requirements are hard. And this soft sort of thing here I ended up being was that OCaml, like the long term drag on it, I can kind of mitigate that if I come along and make sure that it was easy to adopt OCaml I can mitigate part of that, that down, down, that downgrade on OCaml. So, I'll skip through this just a little bit. I ended up picking OCaml after I, I really made sure I prioritized my number one feature here which is the web applications. I made it somewhat prioritized, proving the safety of it, and after rejecting that OCaml came to the top. The sort of the big thing I want to just call out here was, it wasn't like a unanimous this is a slam dunk. I knew that I picking up camel would have its risks I would actually have to incur some risks and making sure that I can have it easily adopted in my own company. I had to deal with the low supply of OCaml for my own company's perspective, and making it easy to adopt for people who were using my tools. And last, it was sort of alluded to this, I knew there was there was poor support for Windows, but my fire interaction with OCaml which is this cool tool called unison unison file sync. I had compiled with OCaml doing that I knew supporting system on Windows. So, I knew there was a way out with that. So, my strategy was a typical one just get with the top risk first which is Windows in the long term thing and while I'm spending my time doing that development of those tools. Well, I think I know they go and release it and preferably fund some of the development work that you that that I've done. So, really, it's sort of at the end of the day. I, the, the low supply and the Windows risk since that was the top risk for me. It was pretty easy is I'm going to come along and make sure that I can build OCaml projects for my own products on Windows easily. And my focus then was just on my own company because I knew it was going to get some employees in. And I also knew that I was going to get some contractors and to do a particular part so I wanted to make sure it was easy for my employees which is kind of an easy thing. And for contractor which is a little bit actually quite a quite a quite a bit different level of difficulty. But my end goal, my vision was they just build to open up a project, run some Windows script to install OCaml, edit the OCaml code if they needed to press build, and it would just work. That was sort of my end goal. And I got to that. But again, my focus was employees and contractors at this point in time I had not really suited the public at all. I went through several issues just get into that point. I'm going to very quickly go through this I'll leave some time at the end but my number one issue was Visual Studio was like most libraries are pretty libraries that Windows are for Visual Studio OCaml. The predominant usage if you were going to use Windows with GCC. And they're simply not compatible we'll think they're compatible but they're not. And as an example, Libby UV which is an eventing a popular eventing library behind Node.js has its own support matrix. Windows is tier one. So it's free as BST for example but if you use the GCC the MNGW stuff, it's tier three. And when they say tier three, they say these systems may inadvertently break. And it's really not a good position to be in if you're trying to build a product line. And then the second issue was Unix commands like Unix is just heavily embedded in much of the OCaml ecosystem. You would see things like when you're when you're installing OCaml itself like you can install packages with a package manager. And just implicit assumptions that there was a POSIX shell to go run and configure scripts. I just littered through many of the packages it's getting actually a little bit better but this one in particular doesn't have it. So you needed to if you're going to come along and run over on Windows you'd have to bring some Unix shell along with it. And I ended up solving that by providing a little proxy that well beyond just installing the Unix subsystem, MSIS 2 over on Windows. Just having a proxy so that if you ran for example OPAM which is our OCaml package manager, really it was my little proxy script called with dkml.exe. And it would just look for the dash real, the real application in the same folder. And before it launched it, it would just put all the Unix binaries like the POSIX shell in the path and it would just also put the Visual Studio environment variables in the environment as well. So that solved actually both issues and that's a kind of useful little trick. And I think that sort of applies even outside of OCaml itself. You may be able to use this if you have these type of problems in your particular language that you have for life. So the last issue was the maintainer, I think almost 10 years, there was somebody who was actually doing the GCC port of Windows and they said that they were going to stop using, stop supporting Windows. So I decided sort of at that point that, hey, I bet my, I have pot committed. I know my Texas folks will understand what I just said there. I've pot committed myself over to OCaml and I can't get Windows to die. So I'm going to come along in my own self interest, go and release the scripts that I have for building on Windows, because I didn't want Windows to die. So I did that. And that was okay. I mean, some people started adopting it, but it wasn't very much. And then the OCaml software foundation sort of approached me and asked if I actually supported in a meaningful way. So my existing support was, let's make sure it doesn't die. And they didn't say this directly, but I'm going to summarize it as, as they wanted to be the point where Windows is actually thriving on OCaml on Windows. So people can contribute to it and you can actually promote it as a real thing to the newcomers to OCaml. Okay, I had to make some decisions here about like what's going to be open source and what's not. I ended up breaking my sort of product strategy a little bit and DKML which is really the subject of this talk here is just pure OCaml its purpose is to learn really quickly and develop one off executables like what you'd use OCaml for today, and all the built tooling would just be conformant with the OCaml standards. And then anything on the commercial side the right hand side, it would be more in the mixed environments I knew I wanted to see a lot in my in my commercial stuff. And I wanted findings to Swift and Java so I can run on mobile. And so it wasn't just development environments development environment and libraries to help people like me, who were really concerned about the risks of a vendor or technology just disappearing you don't know where their particular reasons were. And just from a from a tooling perspective instead of using OCaml it would orient most of what it does around the C standard built tools. And we'll see a little demo of that if we have a little bit of time. So I did agree to that. And what the first project is sort of we worked out was a just download click windows installer. And I made sure that I like my own development on Windows. And the great dog put it in. I caught a lot of bugs early. And I used the, the environment that that that thing installed. So I can do development over and OCaml. And the biggest drawback of it is it's slow and still slow today to a two CPU VM takes 90 minutes to go ahead and install from scratch. And Mac OS, for example, I just timed this yesterday takes 15 minutes. So you got a six X multiple here. And it's not a fair comparison because I'm comparing Apple Silicon versus like a two CPU PC, but even still the windows is just slower. And that's sort of the overhang of just first class support for Unix and second class for Windows in in OCaml broader ecosystem today. And sort of the biggest advantages from my point of view and very much aligned with my goals is it's really not not very hard in which to go and install it and actually get running productive. So, if you were doing it on Unix, and maybe this is normal for Unix, but it's definitely not for Windows users. You'd have to end up having five different commands, one of them would ask you a bunch of questions, you'd have to do a bunch of reading. And you'd have to deal with what we call OCam switch is which is for not familiar it's very analogous to Python virtual environments. And as a big like you need to have this stuff, but as a beginner coming into it, or just in my, my, my world, a contractor coming in, they shouldn't have to learn that just to be able to to use your particular school. So, it's literally just go to an installation page. They, they review just some, some comments about what will happen during the installation. They click the installer. It downloads. For now anyways the Windows defenders going to show up saying hey this is unusual file to actually want to continue, continue running it. And Windows users are habituated to just ignore this and just continue on anyways. It goes and just does its installation. The one of the first things it does is you take it for granted on Unix that you have easy access to a compiler. You don't have my windows. So, all in a visual studio installer. And that takes like 10 minutes just there. And then you have to do the same thing with Git. So you pull that in. And one of the little weird idiosyncrasies of OCamlis today is you actually have to compile, recompile all of your code, including the compiler itself, if your directories. If you're, if you have a, if you don't have a nonstandard, if you have a nonstandard directory structure so on Unix, you can place things in slash user slash bin. I can come along and go pre-compile my code and then copy that over to some other Unix machine and as long as my password is exactly the same, all the tool will work. That doesn't fly in Windows because every single person has their own directory structure and their own usernames and that's usually where things are installed. So you have to go and spend a lot of time and just go and compile things. So this compiling is done at installation time. That's a big contributor to why it takes an hour and a half to go do the install. But at the end of the day, you don't have to do anything. You just wait for it. And when it's done, you can just close out of the installer, go and go to your start button, run the command prompt, cmd, press enter, and then type another four letters to get into the OCaml interactive terminal and start your first OCaml expression. And that's it, right? So it's clicks, it's a few clicks, you wait, and then you can come along and have a fully functioning environment. And that's sort of one of the first good, easy simplification deliverables that we got with Windows. I had a lot of issues with it. I think probably I'm just in the interest of time and I'm going to go through many of them. One of the ones that is sort of endemic though, I'll just focus on this one, is spaces in directories. That is still a problem today. It's just, I guess, I guess on Unix, you just, it's just rare that you have spaces in directories. It is extremely, extremely common, especially for people's usernames to be first name, space, and so many tools on the Unix side of the world break in that context. macOS actually has spaces in many things as well. So it's not an anomaly. Okay, so now on to Act Free. So that was delivered. A nice simplification. It was long, but it's a much easier install in spirits for Windows and beginners are able to just immediately go and start OCamling 90 minutes after they click that install. So I'm just going to give you a little status of where things are right now. The biggest missing feature is being able to have a version of that installed. It doesn't require a C compiler. One of the nice little things about OCaml is not only does it target your native code, but you can just have it run by code as well without having a C compiler. It's so you can have a really, really small experience as long as you don't pull in C code. So yeah, that would be great for students and beginners just to quickly go and use OCaml. The other part is just basically delaying as much as possible any virtual environment, the switch. Like you do need to install packages, but if I install more packages up in sort of the main global area, our new users won't have to. They can delay installing their own virtual environment. And then OCaml itself. OCaml sort of had a big change in the last year or so they released a multi-core OCaml, OCaml 5. It's not ready for Windows right now. There is a variant of it out for GCC. I don't know how well supported it is right now, but there's not really going to be full support for OCaml 5 on Windows for at least a year. I don't really have any involvement with it. I just need to wait for the compiler pieces to be ready for that. Today right now, the distribution that's my company, the distribution of Windows that I have is the recommended way of installing it on Windows. But I have been upstreaming a whole bunch of my changes in Windows over to the package manager and the OCaml team has been really good about adopting them and adding a whole bunch of other features as well. So the next major release of OCaml should be like the recommended way in which to actually install some Windows. And I love that idea because then I'm not on the hook for all Windows users forever. And I'm going to kind of just skip here to sort of the things that just aren't going to fly. They don't think they're going to be really fixable. And there are many packages and people who are just familiar with makefiles. And makefiles just, they kind of work and they don't work if you have any full pass in them that have spaces. And there's nothing that's really going to fix makefiles in that sense. So as long as people use them, there's limited ability for it to work correctly on Windows. And probably more pernicious is OCaml's really good integration with C, but the way that we predominantly do it in OCaml is using package config. Package config has the exact same problems. It can't support spaces or it supports it very poorly. And worse about it is there's no Windows package config. So, yeah, so that's just going to be sort of a drag on Windows until those are resolved. And I actually don't see a good path for either of those two. But at the end of the day, I still find it's quite reasonable to actually go and develop. I develop myself on Windows. I develop four Windows. I also develop on other machines as well. So I've got a routine where I come along and spend a week over on macOS and then switch back to a week over on Windows. I do that because it's really hard to context switch with your keybindings when you go from macOS to Windows. So it just, it helps me out. And I just want to make sure there's no bit rock between the two. But I'm actually developing OCaml using the OCaml tools that I'm releasing. I'm talk footing. And the commercial, I think, tools that I'm building. I'm developing my chat. I'm developing. And I'm just like briefly going to talk about that right now. So the commercial tools that I've been developing, it's development environment in libraries so that you can de-risk your technology and vendors. And I'll explain that just briefly. So, like, myself, I'm building a chat app. It's going to be a real chat app that gets deployed. It's going to be a mobile app that has a back end to it. I need to have it. But since it's like there's a zillion and a half chats out there, I'm just going to release it. It starts good when it's actually ready. So you'll actually be able to see it. It's going to be a good demo of the SDK that I'm building. And chat apps, it's actually kind of normal. Like what's sort of made it popular is to use actors, the actor framework to basically distribute it objects as a way to build your chat back end. And right now, I don't really think I need to have the, the, the, the, the, the actor sort of the bigger actor frameworks. Early node DP is the big one. And then ACA for Java is the other alternative. But I might need it. But I don't think I actually have to make that choice right now. I'm voting in a way that, that I don't have to make that choice and people who adopt my SDK don't have to make that choice either. So I shouldn't have to essentially commit to one of these vendors early or ACA so early, in terms of my product place. They don't need the complexity right now. But I don't want to come on and build a whole bunch of code and then realize, oh, well, I can't scale or something of that sort. And I can't adopt any of these people later on. And the SDK and OK, I'm actually provide enough power for me not to be able to do that. So, so yeah, I'm not adopting those. I am using things that I'm comfortable with. I did spend a long time, 20 years of my life working with a lot of data and a lot of transactions. I spent. So I'm quite familiar with how to build large, high TPS kind of systems and top of distributed in memory. And Redis is sort of the chronicle thing that you do outside of a particular company. So I'm building part of my actor framework on top of Redis. And I, my, my, my guess is that other people are going to actually find Redis sort of a familiar thing much more than Erlang or Acca. They're going to, they're, they're going to probably have more familiar Redis in there with either of those two. And they may not, they may be in the same situation as me where I don't need to have all that reliability and and deployment guarantees that come with some of the more complex frameworks. I'm actually just going to show a little bit of, of the, the IDE experience. It is just taken from the Acca sort of page. It's got a hello world with three actors in it. And let's see, where are we here. So this is C-Lion. Redis is a C-based, obviously it's a C-based program. That's not obvious, but it's a C-based program. So I'm using a C IDE for it. I am not going to go explore the code that much. I am just going to come along and make sure that I've got a whole bunch of run targets that are available to me through C and O'Cammell. In this particular case, I am running a pure C program called Actor CLI and I'm using the IDE just to do a bunch of printing of messages. Back and forth. Hello world. Greetings. The exact same thing that you see over in here. Nothing particularly complicated about that. I'm using lightweight threading to go and do that over in O'Cammell. And that doesn't even use Redis. I just wanted to make sure that the O'Cammell experience was sort of. And that lines up with what you do over with Acca. You get the same output slightly. It's ordered different, but it's the same output. And I guess the real important point is like I'm not tied to CLI and I can come along and use another IDE. And this particular case, I'm on Windows. I can go switch over to Visual Studio. Whoa, what just happened here? And I've got all my CMake targets available with the CMake plugin over in Visual Studio. And I can go and run it. Just the same thing I was doing over in CLI in and I need to make sure that then I might say have some options here too. I can see the output. And same app, same program. Same source code. Just running O'Cammell program through a different IDE. And I'm really trying to make a meta point here, which is, it doesn't matter what your IDE is, your IDE supports CMake, then this thing will work. This SDK will work. And so there are the big IDE. So Visual Studio, Xcode, I already talked about CLI and Visual Studio code. I'm maybe missing ones in there, but they all support CMake as sort of a first class target. So as long as you support CMake, you support all of those particular IDs. And a build tool is not very good unless it can actually target things. So I can, I have a, I'm using GitLab right now for doing continuous integration. Could be GitHub and I'm targeting Android 32-bit, Android 64-bit, the ARM variants and the Intel variants, targeting 32-bit and 64-bit Linux. Targeting, in this particular case, because I'm on a GitLab, Intel macOS and cross-compiling the Intel macOS to the ARM64 variant of it. So that's a cross-compile. And then obviously, let's talk about Windows, 32-bit Windows and 64-bit Windows. And like, it does the same things. If I go look at the output, it actually runs in that particular, the exact same thing, Hello World. So then in this case, it's the OCaml code that's running after it generated a Windows executable. So just, yeah, so the SDK lets you target all of those things and it lets you use the IDs that you're familiar with to go ahead and do that. And it lets you do it for OCaml and obviously it lets you do it for C as well. And I guess the nice thing that I happen to like about it is it lets you combine those two things as well. So in my particular case, you can come along and go to a contractor and they're just familiar with SwiftUI or they're just familiar with doing an Android Jetpack application. They can copy some lines of code in and press build in their ID and EuroCaml interfaces are going to be available for them. Assuming you have a binding between the languages. And if they need to edit something, for example, they're doing a UI, they see the need to have a new field on something populated in their back end. They can just go and copy and paste some of your code. They may not understand OCaml, but they can probably understand how to copy and paste code. So they can copy and paste code and press build, and it's available for them over in their front end. So that sort of gets around the whole like, well, I've got a whole limited pool of people can actually do OCaml. And I can actually come along and go and scale through people who happen to not know the particular language in question. So just, I think people, it's probably pretty obvious that the type of people who would be gravitated towards this. Basically anyone who needs tech resources and they don't have the expertise in-house to be able to go and do it. So Startups is the classic one and if you're a service organization, you service other people, you're probably in the same boat. So if you want to go visit my homepage, discover.com and there's documentation available to it right now. I'm actually releasing it publicly next Monday. So five days from now, six days, five days it is. And it'll have more complete docs for the docs that are available for you to look at right now. So that's it for the OCaml, like how I actually use OCaml on my machines. And sort of one of the interesting areas, I'm going to conclude with this topic is hiring. One of the interesting areas that I sort of had to deal with is like, actually, what am I going to do for my hairs. So I ended up having my first time, my first full-time engineers, who's going to be coming over in the summer. I had a choice between, because I'm very C-centric or OCaml-centric, a choice between choosing that. I chose to bring in somebody with a C background, and a teaching background by the way, but a C background. And I'm going to delay actually getting my OCaml expert in until full-time employee two or three. That's just the way that I've tried to address this. So, but I've taken on the risk of doing, actually taking in high school students as trainees. And I know, like I had talked about Teal, so hopefully this is up, sort of in the same vein as that as well. So, what I had two purposes with this. One is, I wanted to, well, just get some more people available to actually work on some of the OCaml stuff. I'd work on the hardest stuff and leave some of the less hard stuff over to people that I trained. But I had a second purpose, and this is a really important one, which is I wanted to come along and demonstrate that, and prove to myself, that's proved to others, that if you took the risk of having OCaml in your team, in your company, whatever it was, that it wasn't going to break your team, they wouldn't come along and be overwhelmed with that particular choice. It's not going to, you're not going to have people leave because it's just too hard to do, or it takes too long to come along and go and learn. So, my sort of study, if we want to call it back, is I have high school students who have taken in a trained, they have APCS, a Java background. I have trained most of them for approximately 150 hours, that's been less, it hasn't gotten to all the, for all of them up to 150 hours. And I guess my sort of, my mistake is, if I can come along and train them in that period of time, in a quantified period of time, your team can too. So that's sort of how I come along and look at dealing with the common objection, which is, I don't know this language and it's going to come along and until my team. That justified the risk of actually putting on, getting on high school trainees, and I had obviously had to change my expectations. They weren't college interns, college interns, you know, they're committed for a period of time, high school interns, absolutely not. They have far, far less time right now. Most of the people who I'm working with, like for the past few weeks have had zero hours. So, because midterms, or for example, or finals actually coming up in a month now. And so, it is, time is not in your control. And also college interns, you end up doing very large projects, you have no experience with high school, even if you take him a computer science class of actually doing a large project so you're going to have to help him initially doing the breakdown of tasks. And they may not come back over during summer because that's not a typical expectation that you get with high school students. I did. Oh, I just want to give one little caution, and this is really important. I am talking about minors. So, because I'm talking about minors, I'm not going to be given particular specifics about why people chose to do X, Y and Z just hopefully you can understand that situation. But I can at least give some summary broad level things. So, yes, they were trained for 150 hours, some of them came in and a path where they wanted to be entered some of them came in and path where it was best for them to be end up in a path where they can do code contribution. So basically do a project. That's sort of what their goals were. So, everyone came in with our own course load and the extra curricular so not everyone trained at the same rate. And my outcome of that 150 hours was get to a point where I can come along and say, I give you a task, and you come along and write, you know, 2040 lines of code in an hour, you do it correctly. And I have given you five minutes of structures, I can scale with that. Right. And so, five minutes, I give instruction an hour, they come along and go and do it correctly. And if they're coming in the summer where they have a lot of time. We can start off sort of essentially kind of doing light pair programming that way for a few weeks and then they can graduate themselves to five minutes as a stand up every single day doing eight hours not one hour right so that's sort of that's sort of the goal there. So that was sort of the reset expectations for high school hiring and that was the way I actually train them. Most of them. Okay, let me just give you the results of it. So, only one of them has actually been able to commit all the 150 hours, and I did the separate with them and they passed. And they're getting a summer off. The other three haven't been able to commit all the time but we have a month or two before summer comes around. And I'm very, very confident that most if not all of them are actually going to be able to pass that final test because I've done tests with them before. Well, I'm going to be having in the summer, a couple of people doing return internships and couple of people doing their own projects. And yeah, from from my perspective is absolutely huge success. I'm going to be able to bring people in that are productive I know what kind of expectation I have with them. And yeah. So, I'm going to sort of end off on that and just wrap everything up right now. So, some key takeaways I just wanted to leave out there and I'll open up for questions. I know I kind of briefly went over this but if you're actually supporting windows is the first class thing there's just some concepts that you're just going to have to take care of what one of the most important ones is actually you use visual studio and you don't use GCSE. You don't have room in here to put it but spaces as well as a huge thing. You can reuse if you want just come talk to me offline about using the proxy that I built maybe rejiggering it if you have a favorite language that is very units heavy and you want to port it over to windows. OPM itself which is the OCam package manager, but it's actually very language agnostic so that's a really good tool if you don't you want to kind of improve your package management experience. Talk to me as well about training and hiring high schoolers. It's, it's different but I think it's probably the best way to prove that if you say that, you know, other people can come along and adopt your particular technology and you actually have high schoolers demonstrate that they can actually do it. But there's nothing better than that so come talk to me if you want to go and do that. And finally, if you're sort of in my own situation where you're really concerned about being able to stuck on vendors or particular things that they think are going out of fashion. Consider using DKS decay to solve your problems and just go to my homepage for that. So thank you that I'm going to open up the floor for questions. Thank you so much. Thank you very much for questions. And I just asked, so I know you mentioned that you weren't going to talk about the dealing with the make and, you know, the package package get for whatever for Linux that doesn't really work well for windows. So is open sort of the way around that or is it. No, it's not so that the problem is not so much the OCaml side it's the seaside right like if if you're on Unix, the standard way when you come along and you link with with find your libraries on on Unix is using package config. There is not a cross platform way in which to do that unless you're using like C make or something of that sort that has its own mechanisms for for for building and discovering things. So that's one of the reasons why I think this is actually going to be almost impossible to dislodge. So that's the way I really considers seriously see that being dislodged if you have an alternative to package fake that Unix users can actually use to actually replace package config. And you'd have to get to users to actually use users and see users to actually adopt it. That's a tall task. And I don't have the motivation to go and drive that. But if someone does in great that would actually solve the problem. I was thinking, I don't know. So, when get is is is this available on when get or is it something that's Okay, that's a random aside, but yes, you can call both opium and Okay, I haven't announced that but I will now sit down so opium package manager is available you can just type when get install opium and it will install opium on windows. By itself though opium is not that useful because you need to have Unix environment stuff with it, which is reason why I haven't announced it. And then you can also install all of the the the DKML distribution with when get install, I think it's like a DKML and do that whole installer process that you you saw me sort of demo early in the talk. But none of that sort of, I feel like that's kind of very orthogonal to to the package get things so the package config thing so I'm just trying to think of a good example. You are trying to pull in, let's just say the open SSL libraries. Right. And you need to have a way in which to access to find that library wherever it happens to be on windows and wherever it happens to be on Unix, and yes, it may not be in a particularly standard location but you can at least use package config to go figure it out. Because windows there's no real story for that right. And that's why I started saying like, even if you wouldn't get it your open SSL, we get doesn't have any metadata for you to query to go see where it install things. Or like, here's the standard include path or something about sorry, if it did actually that would be, that would actually be useful. Awesome. I don't want to play. Is there so Visual Studio code has a feature where you can run your code and do your filing all that in within the Linux. The WSL. Is there a reason why you want to build on the windows side versus like in the WSL environment. Okay, so I do use that I think I was using it last week to test out some some Unix, some Linux stuff. The real problem is that you are building Linux binaries when you're doing that. And what you're trying to do is distribute windows binaries to people. You end up you actually have to compile windows to do that. So, I like WSL too is a really like nice thing. I just don't think it it. It solves the need for for windows users who are actually building windows things that completely doesn't. The other thing that I found is using WSL to I cannot remember what I was compiling a last week but I did find that it is so atrociously slow when it comes to compiling things for normal operations like if you're going to throw up a web browser and like as long as you file although you're fine. And if you are you are completely fine. If you are in a fully Linux volume, if you're not on any windows mount, but the reality of the world, at least my world anyways is I need to access windows files. And the second you do that you're just it is literally 23 times slower. It's, it's just not worth it and not point. So, and it's probably a matter of the having lived too long in the enterprisey space, where the only building you're doing on on on your own machine is like for your testing. But any release builds happen somewhere else again, you know they happen on a on a server somewhere. Yeah. So that's a really key what you're what you're saying here. So if, if what you are doing is targeting servers, then you don't need windows like I would like I was talking about redis for example, I would never deploy and I'm sorry if you people want to do this but I would never deploy redis on on windows I'm going to deploy it on Linux. And it's just I'm going to use Linux and or some kind of unix thing for deploying on my service and if that's all you want to do that don't use windows for that. But for deployment aspect, the only part I would say though that that doesn't make as much sense as when you're trying to debug things in, like even in my redis thing like I made sure that I had a windows. I made a windows build of redis, and I'm debugging in windows because, even if, for example windows studio code has a nice integration with WSL to and it kind of works. When it comes to debugging over on windows I want to use either visual studio itself or debugging, or better yet use when debugging and or when debug preview whatever the next version of that is. And those are supporting right, so I don't want to be limited in my options simply because my final environment is going to be unix right I'd rather have all of my development on windows by 10 only if I can. And then makes and then deploy that over to unix environment. That's that's that's the way I feel about it. Right. Other people have different texts. That makes perfect sense. Well, the question I had. Since windows is so important. Why not F sharp. We got a bunch of F sharp people in the room here. It's part of the, it's part of the old camel family right now. I heard camel. Yeah, to be honest, actually, it's actually interesting because I'm, I'm not sure why I Oh, I know the reason why I didn't put F sharp high up on my last. I did know about it. I did evaluate it. For my particular reasons, since I knew that I was targeting both mobile and embedded devices, the embedded devices was particular like I didn't see a very good path or F sharp slash net kind of on embedded now might work. I don't know I just I didn't see a happy path for that. One of the things I kind of look at when it comes to a camel itself is I don't really see a camel's a camel. I see it as sort of like a layer on top of see like, I can compile a camel I can do it from scratch using C. I can almost do that anywhere. Right. Like I felt comfortable enough. I mean, it just started using a camel two years ago, contributing some patches to get a camel working on Android arm 32. There's there's I mean it had arm 32 already but like some more support for that that that it didn't have I felt comfortable enough doing it because it's just like C code and some assembly like it's so close to see that like, I don't have a problem when it comes to the embedded world. I didn't get that story from F sharp. Now, that is my particular needs now if you're not in a, like, if you are, if you are targeting just the front end or just the back end and you know where you're going, I think for F sharp should be a really compelling option and I'm sure people in the in the river using F sharp are probably in that category where it makes a ton of sense. Okay, well I'm going to thank you I'm going to turn off the recording and then we can see if we have other offline non recorded questions and discussions. So I want to thank you very much. This is great really interesting. Thank you.