 All right. So I want to welcome everyone to this month's meeting of the Houston functional programming users group. And this month, we have called bigger speaking. He is the former Federer CEO developer of circle CI. And he is now developing the dark programming language. And I'm just going to turn it over to Paul to what dark is, why we care about it, how he developed it and anything else he wants to talk about. Well, thank you so much. Thank you. Thank you folks for having me. You were doing interest a few minutes ago. So my my functional language intro is for a beneficial programming language. Developer for 12 this year is if we don't count what I did in college. Closer at circle CI and then at dark we've done everything from we've done Elm we've done a camel we've done a shark rescript rescript when it was called buckle script lots of lots of different things and have sort of settled in. Well, we'll talk more a little bit later about where we've settled. Let me figure out how to get the screen share. Okay. Looks like people can see the screen share. But I can't, I can't say. Okay, well, great. So, I'm here to talk about about dark and dark. I've actually started calling dark playing in the last couple of years, but it's a very hard habit to get out of because dark is like one nice little syllable. But dark is functional programming language and I call it a functional programming language for the cloud because it's it's doesn't really exist in the same way that lots of programming languages do, which is you install them on a server. We'll talk about that more in the future. What we'll be talking about is what why did I make dark line. I'll show you a demo of it. Talk about the main features talk about the functional programming aspects of it. And then talk about a back end rewrite, which is from one functional language to another. So it's kind of interesting and then talk about where dark is and then a new secret exciting thing, which you can still regret. I don't care, but you know, it's not going to be an answer for a couple of weeks. My background, before before all this obviously I was at CircleCI but before that I did a PhD at Trinity College Dublin in compilers and static analysis. And then since 2017, I've been the CTO of dark and since 2020 I've been CEO and that's that's a whole story that we'll get to a little bit later. Okay, so now what why why did we start? Why do we start building dark so when when I was at Circle. I found it like it was very, very difficult to build internal tooling and it's just like any time that you want to build some internal tooling it's, it's not like it's not easy to build things and applications are, are very difficult to build. And it's just like any time that you want to build some internal tooling it's, it's not like it's not easy to build things and applications are things that are built in the clouds and there's like tons of like different tooling and complexity around to build anything. You know, we would have to staff up a team it has to become a project there's maintenance there's just a lot of ongoing stuff. And the words that I use for this is accidental complexity, you might be aware of accidental complexity it's it's discussed in the mythical mad month and in this, in this article called no silver bullet which is like pretty, pretty influential. But it's also like a term from from our style that there's the accidental complexity which is sort of the bullshit that you need to do to build your application, which Aristotle obviously had a lot of problems with. But also the, the essential complexity and the essential complexity is the real thing that it means to build an application. So, in terms of software, the essential complexity is just like, you know, receiving data processing data storing it and sending it out to third parties. This is what we actually want our software to do when we, you know, build Docker containers that we put onto Kubernetes and run through a deployment pipeline and write git commits and all that sort of thing. You know, a little bit, you know, that sort of like the theoretical essential complexity but the actual essential complexity of an application. You know, I want to do something like tell, tell the application that the user presses send a message and then the message is actually the, even if we lower the essential complexity to you know something that's just like this there's another layer beyond that of, of essential complexity which is the thing that the developer actually wants. So if you look at how we're actually developing things today this is the couple of people in the audience mentioned DevOps you're probably feeling a little bit chill down your spine right now. This is the cloud native computing foundation cloud native landscape. And what this is is just like a list of all the icons and this is from 2019. So it's not even it's not even up to date. All the tools that exist in the cloud native space so if you're building applications in the cloud which majority of us of us are building applications in the cloud today. These are the tools that the sort of areas that we need to consider as part of our as part of building and none of these are the essential complexity of our applications these are the. These are the tools that we need to do in order to build the essential complexity in our code base that we then need to use this to get into into production or getting it in front of our users. So that's kind of one aspect of the accidental complexity the other external part of accidental complexity that I like to think about is the is the CI CD says so the process of getting code from our machines where we write it into production where our users are able to use it. And that's CI CD DevOps, you know, info as code managing releases all this sort of thing. And what we see here is a typical CI CD pipeline where you make the change, you run some tests you commit you push you go through like CI CD run, maybe multiple times after code review. And then when you merge it you go through it all again and then it goes into, you know, gets put into a container and the container gets deployed to container registry, and the most Kubernetes and just like all these different steps. And the interesting part of it is that once you get to the end, you know, if you if you were doing sort of modern practices of deployments maybe you did it with a with a feature flag. You know, at the end you get to go back and remove that feature flag and then it goes through, you know, the whole thing again. And so this is, you know, a lot of accidental complexity and complexity that people do not really want to do when they're thinking about like oh what does the user need today what does, what does the tickets that I wrote in Trello say what does the product manager require and what what does a user actually need like, you know what they don't need is, is, you know, Kubernetes to be, you know, updated in a nice little way or whatever. So, let's let's quickly show you how we do it in dark. And so what I'm going to do is I'm going to open a dark line. It's an application that that has never, you know, never existed before just just create it as an ether. And we're going to create just like a Hello World application. So we'll just make a HTTP handler, and we'll just return the string hello, and we'll open that in a new tab and you can see the URL there will zoom in a bit. You can see there's a URL here that you can go to, you know, open your phone or whatever go to all hyphen hfpg.builtwithdark.com slash hello, and you can hit this, you know, this thing that is live on the internet already. And the, the idea here is obviously this, this is a language that like, you know, it exists somewhere here, but it doesn't necessarily exist in sort of like, you know, code that is put on on get that is put on a file system somewhere where a HTTP server is started. This is just something that that's like pushed straight into the cloud immediately as soon as you type. If I type, you know, something slightly different. You know that that too is, whoops, that too is live in production, you know, no, no steps are involved, no CI CD, no servers, no provisioning, no, no containers, etc. I'm just going to give a little bit more of a demo here. I'm going to, we'll change this to, we'll change this to have a name. So let's go open that hello that doesn't exist anymore. Let's go to hello Paul. There we go. So what I'm going to do here is just a quick little bit of sort of functional programming. We are going to create a data store. Our data store is going to be called users and users are going to have name which is a string and date. Which is a date and will quickly create user equals name is user and date is date now. And what you can see on the left here is you can see the actual values that we're using in production. So you can see John story here made a request to that URL. We'll come back to that in a minute or what that means. But for now we are just going to store. We, the things that are that are pure functional are executed and visible at any, at any time, things that are not. We can execute with this little icon. And I'm just going to add this to the database so we'll set user in the database will use the key. I have overridden that user. And the data store is users. And then let's quickly return. We'll just return the count of users to be came from the users table. And let's run this whole thing. So we can see now that the trace returns one trace returns to someone else must have pressed refresh. So quickly open that. And then we can see the thing records two and three and whatever. So, you know, roughly what we what we created here is in that very quickly we created a data store. We created a HPP handler, all of these, you know, available live on the internet. And this is our sort of like built in debugger of tracing so it comes in with like observability and all that sort of thing, which I will which I will talk about a little bit more, a little bit more later. So, let's get back to. So, now that you have a sort of a sense of what dark is we'll talk a little bit about these these sort of like built for the cloud features. So, there are there are three kind of important features and we saw we saw all of them there. There are a couple of months to read just things. And we saw all in there so the first one of them is is what I call invisible infrastructure so you can sort of think of this as serverless but it goes a little bit on it beyond serverless with serverless. You're still thinking about, you know, we're running this HPP server on a, maybe a container maybe maybe an app engine thing or you know whatever. But there's there's none of that here there's just you write the code you say where it lives and it goes immediately into production. And so, you know, from the perspective of all this cloud native stuff like there's none of this cloud native stuff in it all you don't need to think about cues or you don't need to think about what so you don't need to think about like Kafka, or you don't need to think about. That's my Kubernetes again because that's that's my least favorite thing. And instead we kind of write applications like this so this is a full application that's written in dark that's, you know, just receives events sends an email you know pretty pretty pretty simple thing. You know, a table or a strong job the background worker. A heat CDP request just like, you know, not not very complicated stuff. It's not very complicated up and what you get to see is essentially, you know, the essential complexity of what it takes to build this application. And if you were to try and build this in, you know, some other framework, you would probably spend the first hour trying to get it set up into production somehow. You know, with, you know, get repos and even if you took something simple like for a period, you know, still gonna be like, I'm sorry. Your audience was jumping in and out. That was even that connection. Is it us? I think it's fine here. Yeah, it's fine now. Great. So, in in dark infrastructure is is instant and it's it's invisible you never need to think about it there's no provisioning no, you know, terraform infrastructures codes no configuring and most importantly there's no waiting, setting up data stores setting up shoes workers everything is just like right there to start and the way we do that is that we're running this, you know, a multi-tenant system in the cloud with these data stores and everything running. So, coach lives in the cloud in a sense is the kind of what I mean by by there's a, you know, a functional language for the cloud. There's no idea that you're creating a binary that runs on a computer somewhere. Obviously, you know, there are computers involved because that's that's how things go there are there are servers and load balancers and all this sort of thing behind the scenes. But you're never thinking about, you know, a little bit of gets or, you know, you know, even thinking about like the existence of a file system Linux doesn't exist in the model of how you create software in dark. I'm going to give you a little preview of something that we're working towards in the future this is sort of a, a view of how we think software should be organized. Most of us today organized software in directories in a file system that we then put in repositories. And then we have an organization of repositories. But when you think about how applications are like if you think about when you start out a new job and you go talk to the senior principal engineer what happens is they take you to a whiteboard and they start to draw the diagrams of how the data flows around and what happens. And this is I think a better model for how, for how we should think about our software we shouldn't think about, you know, what are the files for the modules we should instead think about like, you know, what is what is connected and this is a hypothetical view of what, you know, simple SAS architecture would be like with a bunch of data stores and and HPP clients and some, you know, delivering of requests and that sort of thing and this is sort of what we're trying to work towards getting away from the idea of software being text in files on disk on Linux or whatever. So that was, that was the invisible infrastructure the, the second idea in dark is deploy list and that's that's what we call the, the instance deployment so whereas before we have the, you know, there's a CI CD system and it goes through many stages and runs many tests and that sort of thing. We've built dark from the ground up to be something that's that's safe to be able to deploy so in dark, all you do is you make the change behind a future flag. Any change that you want to make you can make behind a feature flag you can you can edit away, and then you can preview that change is no need for like preview environments or that sort of thing. So you can, you can put that that behind a flag so that only you can see it or only your team can see it, or, you know, depending on your particular deployment model that you prefer maybe, maybe it's something that that only particular header can see only particular clients, etc, etc. You make that change behind a feature flag, you know you validated however you need to be validated maybe it's a conversation with the rest of your team or whatever. And then that feature flag you converted to 10% 50% 100% and this is sort of getting down that that deploy to be just the minimal essential complexity because sometimes you do want it to go out, you know very slowly and be able to like validate that it works and sometimes you know you're just going to, you're just going to press the deploy button you're going to go straight into production who cares, and you can edit it live in production. You know I did there on the demo. Most people we feel are going to prefer feature flags. Other set of deploy list features, such as such a database migrations and function versioning every, every function in dark is versioned. And that's just more ways of sort of having this immutable code, so that you can be sure that when you're making changes you know exactly what changes go into production. And that's sort of the idea behind behind this deploy this this changes or instance there's no, there's no deployment, no, no GitHub, no, no pull repress that sort of thing whatever you want can be can be built on top of that of course. You need things like, you know permission to deploy that can always be retrofitted into it but the, the idea of it is like how do we get our deployments down to less than one second in order to do that, you really have to design a language and a system from scratch to be able to do that and that's exactly what we've done. That I showed you. It's a question about the content to ask it if it's a question about something else come back later later. Okay. The last thing we saw is what we call trace driven development and trace driven development is this idea that without instrumenting your code without recompiling your code, you can get debugging access to to live values that your users have made of any variable in your program. So you don't have to do, you know, there's two kinds of ways of doing debugging today there's there's a debugger and there's like printf debugging, and both of them suck in their own little ways. Printf you obviously have to have to recompile you have to add it into the place a debugger have their own problems, generally you have to restart it and get the condition back to where it's going to be. And both of these are kind of horrible. And so what we do and you can see that a little bit when when I did the demo. This is this is some dark code here and you can see that the cursor is on the letter I. And so what we're show or on the variable I. And so what we show you in on the left is that 10 is the last value of I and you can put your cursor anywhere and see what the result of that is and you can do that anywhere in the application. You also see the results of the whole thing which is the at the bottom of the screen there the one to fizz. And so it's this idea that you shouldn't need to do anything to be able to get this sort of amazing debugging ability. So the reason that we're able to do this is because we've brought everything together, we have, you know, we run the infrastructure, we run the editor. We wrote the programming language we wrote the runtime to enable this. So it's, it's really like an incredibly powerful way way to debug and I miss this every day when I don't write dark. Can you show the trace trace is coming out. Just at the end where it says this is right. We can't see it. Sorry about that. So it just says this trace returns and then it's a list. Just like listen to access open square bracket one to one to fizz for buzz fizz seven eight fizz buzz close square bracket. So that's, you know, why we built dark what dark is kind of main features dark. But this is the functional program group so let's let's talk about the functional programming side of it. dark has all of these functional programming features it is a functional programming language. It has options and results as as the main, you know, error checking there's there's no exceptions there's no panics nothing like that. So it has strong static types so everyone disagrees what strong really means in terms type systems but it's it's definitely on the strong side. There's no cast corrections and integer is not a float does not the same thing. First off functions and immutable data. It is expression based like most functional programming languages, and it supports impure functions like like some programming languages. So the sort of, I'll get back to specifically what what those are but I want to talk about our influences a little bit because we are influenced by an awful lot of other programming languages. So closure was the first program languages that I used an awful lot. I'd written some camel and some classical before that but but closure was really it and struggled with closure with knowing types, just knowing what could be the type of anything in the pre spec days. And also, you know just found nulls absolutely everywhere, and particularly because our database was was Mongo. And so there was, you know, really there could be any value at any point anywhere in your program and it was a real challenge to build software so I really didn't know I loved closure, but I did really not like the side of the type stuff or the lack of static types. And we experimented a bit with type disclosure and funded that a little bit but that project didn't really didn't really go anywhere even though we used it for a couple years of production. The Elm used quite a bit the first version of the client was an Elm so it's very similar to Elm in terms of like language features and what you're doing in it. You can do things like, you know, call random number generator without passing the entire state through through the application. The original version of dark was built in OCaml. And so it grew alongside our learning of OCaml. So it's kind of like OCaml with a little bit of better syntax. And removing the sort of the bits of OCaml that no one really uses like the object system and that sort of thing and just maybe a pure, a more pure functional version of it that OCaml our front end is written in our front end is written in Rescript. So it's pretty similar to Rescript. No surprise because Rescript was OCaml minus all the stuff. And a little bit, I know Rust isn't really functional, maybe we disagree on, on exactly how functional it is, but it's pretty similar to Rust in that there's options and results and there's records and there's enums and that sort of thing. If Rust was a functional languages, higher, much higher level, and of course garbage collected, which is a super important, probably the most important feature in programming. As far as I'm concerned. And for the F-sharp people, it's like F-sharp without .NET or without, you know, C-sharp interoperability. So, looking at this code that we saw earlier, you know, it's, it's generates a value, it puts it into a pipeline, it maps across it. There is expression based if statements, you know, very similar to what you expect in any, in any functional programming language. So, why, why did we do all these things? Well, static types, I firmly believe that static types are one of the easiest ways to reason and have correctness about your software, knowing what the types are is often sufficient to know what the code is going to be. And I found that static types are not perfect at removing bugs from software, but they're probably the best tool that I'm aware of for removing bugs from software. So, static types was always going to be there. Obviously, options and results, we don't use the word monad, because it confuses users, but you know, there's this monadic kind of stuff in there. First class functions, expression based. And then I think the most important one is immutable data. I think immutable data is just, it just simplifies how we write software more than almost any other tool that we haven't. It can be difficult to use immutable values all the time. You, you have to use folds instead of for loops and that sort of thing. But in terms of, in terms of writing software, I think it's like an essential feature. And I think it is the most important part to my mind of functional programming. Despite the fact that it's not, you know, it's not even in the name. It's not the thing that people think about most of the time, but for me immutable data is, is the thing that makes software easy to reason about. And it is also the thing that allows traces. So those traces that we saw in the application, you know, most of those are not actually storage during execution, we don't store anything that is an immutable expression anything that's a pure function, doesn't need to get or the results of the impure function. So if you're calling date now if you're calling DB fetch that sort of thing, we store those as part of traces in order to be able to, to debug later. But anything that's, you know, relies on this immutableness, or we rely on this immutableness to be able to make that tracing system instant and efficient I suppose. Yeah, so that's, that's functional programming languages. Let's talk about dark status so dark started in 2017 as this sort of like hot new startup, you know, founder of circle CI starts next thing raised three and a half million which 2017 was a reasonable seed around 2021 that was a small seed around but today, I guess that's big again. We did that for bed for bed three years were a little bit of hype, and then things went bad we we didn't manage to raise a series a hadn't got the product to a place where people were really able to do it very effectively there was a lot of issues with it. It was incomplete among among many many other other problems and so we kind of hit that oh shit moment where, you know, even getting a little bit more money we didn't have the money to keep going. And so the team went down to just me sort of trying to figure out how do we build this ambitious programming line words slash platform slash editor in, you know, in the in the circumstances. So 2021 was spelled, it was spent on a rebuild, removing a lot of technical debt on the back end during a rewrite from a camel dash shark, and then 2022 we sort of refocused with the idea of like built we're building for the community we're building this thing that community can use. And focusing on how do we get a thing out there that that becomes sort of like community owned the sense. And then finally of course 2023, we are doing a secret new thing which is not going to be that much of a secret for too long because you're going to tell you in about 10 minutes. But first, the 2021 this was the the back end rewrite. So we we had this initial version which was written into camel. The version was written in python but that lasted for about 800 lines before I discovered I couldn't really your factor anything. So that got rewritten to a camel. And then until 2020 it was, it was a camel. We considered going to rust I did a, I did a spent a couple of months like evaluating rust and see whether that would be a better place to write in. We had spent several years when we're building on a camel saying when we do the rust rewrite will do this properly and this properly and this properly. And so basically I was evaluating, you know, is this going to be fast enough is this going to be like fast enough to to right not just performance but but what is it like to write code and in rust and determine that I did not like it I like functional programming languages and it is not one of them. And so instead ended up going to F sharp. So, not as performance as a camel, but much better ecosystem, a lot more tools, a lot more libraries a lot more SDKs, surely because those things exist in the dotnet ecosystem. And they do not in a lot of other ecosystems. So spent what I thought was going to be six months ended up being 20 months on this rewrite which went out in July of 2022. And it went out pretty much bug for bug compatible. So all of our existing users were, you know, the part of the thing about dark and part of this like deploy this idea is that applications should never change. We should never break people's, you know, our users code in, you know, kind of in the way that that often happens when libraries or when programming environments upgrade, you know, Python to Python three broke everybody broke the entire ecosystem for a decade. So that's not the sort of thing that we want. So it went out bug for bug compatible which may have been may have been a choice may have certainly was a choice may have been a good choice hard to say. Okay, so F sharp. Is it good? Yes. Love def sharp. So compared to compared to rust rust, you know, it's it's not immediate. It's not an immutable language. It's a very low level language is no GC. And it doesn't really have the libraries for immutability that we needed for for dark in particular didn't have you know built in garbage collection. So writing it rust would have meant that we would have had to build that immutability some of it was there but not not that much it's hard to do. It's hard to do async and recursion in at the same time in rust but F sharp has no problem with it at all. Our experience with that sharp has been pretty excellent. It is slow to compile, especially relative to camel. That is probably the biggest weakness in the in F sharp, which is to say actually maybe maybe it's only weakness. I don't find the dot net web stack to be particularly interesting because it's kind of written for for C sharp it's a, it's confusing this ASP dot net kind of shit, but there are functional wrappers built on top of it which which we don't use which is, you know, for better or worse. The other thing about it sharp is that it's built on top of dot net. I have always been a, you know, in the Linux ecosystem I've never been a dot net programmer, but I joined in the, you know, the dot net rewrite where it's done it's called dot net. But it was called dot net core and sort of a grand up rewrite of F sharp. And honestly that has been that has been amazing the ecosystem is phenomenal the tools get faster all the time. The language gets faster. We've been really happy with with the dot net stuff and really happy with F sharp. So our future with dark you know what we're kind of thinking of over. Or what we're doing with language over the next few years, we're focusing on this sort of idea of how do we keep dark being sustainable since it's not, you know, hot new startup anymore it's this this new way of programming that we want to exist in the world and that we want to exist in the world for the long term how do we do that. Well, part of the stuff that we're doing is we're building in public where we're trying to empower contributors to help everything everything is public all the code is public the there's a discord which is where we do all of our communication. There's there's, you know, this dark has sort of three employees now but every employee stuff happens in the discord channel. So we're really trying to blur the line between sort of employee and contributor, so that people who build things on dark can feel empowered to, to, you know, solve their problems if they exist within, you know, the dark runtime within the dark standard library etc. And of course adding a package manager so that they can, you know, create their own packages and share them with the ecosystem. This is the first time rolling out sponsorships you can go dark.com sponsor, I think we have $0 now so I told nobody about it and only put it up at the weekend, but that's something that will be announcing to our, to our community in in probably probably tomorrow I might write that email tomorrow. So one last thing to talk about before we're done and that is the new secret that so I say please be cool. I honestly don't think that that dark is interesting enough to the world for for all you to share it on Twitter. And for people to be to be super interested about that but the reason I'm saying please be cool is that this is an area that people are a little bit iffy about their not super sure about it and be interesting to gauge your reaction. But what it is is that we are going to integrate dark with a GPT based system. Not necessarily chat GPT I see some reactions here this is this is interesting, not necessarily chat GPT but I'm going to use chat GPT as a placeholder for some LLM GPT based system. And the reason that we're there were, it's going to say looking at this but really we're looking like very restless this this is this is all that we're spending on our time on now is that you're from using co pilot and looking at chat GPT and looking at how it generates code. I'm, you know, kind of wondering, we're building this system for writing code, and we're a couple of years away from it being really good and you know taking over the world if it does that. But like, in three years or five years are people really going to be writing our seasonal code or we are going to be typing on our on our keyboards to put the code out there and I'm not super sure that we are stuff that I've seen from chat GPT and my own use as a co pilot has made me think like, hmm, this is like this is the first version of it, you know there's going to be more versions of this and people are using we are using to write code and obviously there's a lot of problems with, you know, where did this come from and and all that sort of thing and you know it's it's a liar and it's you know manufacturers or hallucinates things and you know writes in the style of the 12 grilled but it's very good at writing code. You ask it to write code and it doesn't. And that's a very interesting thing if we're writing software that is intended to reduce accidental complexity. So we are going, we're going all in on this we are going to have a system where you tell chat GPT what you want, and it builds it live in production so taking the usage of of darks, you know, liveness and all that sort of thing. All the trace chosen development and things that can be fed back into the model. I think it's going to be quite interesting relative to to you know just talking to chat to BT but we are super early. And there's, there's a lot, a lot to go with this and you kind of don't know where this is going to go but we are we are kind of all in. That is that is kind of everything that's you know why we built it demo functional programming bit of it and the new secret exciting thing that that is spending that I'm spending an awful awful lot of time thinking about these days. So thank you. Thank you so much. So we will open things up to questions and we already got a hand on so I think I'm wondering is if you don't have kids and you don't, but you don't have more than this. Every single function is good. I'm having trouble, I'm having trouble making it the question I wonder if you could slow it down a little bit. The audio is not great in your room. How can we roll that. Yeah. Yeah. So how, how do we roll back. Yeah, so you know the you press command Z. And then it is rolled back you know it's it's it becomes undo is the obvious thing. So you have a more robust version control system right now which is one of the reasons that you know it hasn't taken off. But the conceptually, every, every change that you make to dark programs is is an operation. And so I don't know if you're familiar with with CRT is or operational transforms. But you know it's just a list of changes that you have made so you can go back to the previous change and the previous change and the previous change. And our observation is that like, people don't really do do this in practice. People tend to do an awful lot of rolling forward instead. But you know if you want to roll back there's there's no reason that you can't. You just make another, you know, feature five or, or, you know, at the moment you literally press just like commands and then you're back deal version. So, so can I pull up on that so you're sort of having centralized version control. You asked, are we reinventing centralized version control. We are no no no we are, I suppose you would say we are we're imagining it. What we're doing is, we're saying so dark is is an AST based lineages no text stored anywhere. So basically the change all changes that are made to dark are essentially diffs to the code. So we are putting the version control within the editor, where it's sort of, you know where it sort of belongs because it doesn't make any sense to have this separate get system, this you know file based system on top of dark so honestly it's going to work pretty similar to most people's get workflows obviously it's not going to be a distributed version control system but you know there's, there's going to be branches that are in effect that they're already are, but we use we use feature flags for all these things so you can just make you know a branch is a feature flag. The grid of that branch is deleting the future flag, merging the branch is merging the future is making the future flag that a false and going back to it is going through the undue stack to find, you know, where that was merged down to down to go back to it. I think this might be might be me now. First, Paul thank you for this is very, very interesting. Just a quick comment this actually a lot of the things you're saying remind me of what I've also seen in a language called unison. So if you if you're unfamiliar with that you might want to Google it. Two quick questions for you. The first is this seems very interesting and super power for small scale so a single developer or maybe a pair of developers who sit together who want to bring something out Do you have any thoughts on how a larger scale team might collaboratively produce something in this system. It's question number one and then question number two is in my experience, a lot of complexity for children that looks like hard to understand the state or to debug them actually happens over time it's a change of the system over time, especially in the context of resisted state that's in your data store. So without having a clear get like history. What are you doing to enable someone or a group of people to be able to debug and understand the current state by understanding the changes to the system over time. Yeah. And really good questions. So I will go I will go backwards, because that's on my memory works. So, you know, what are we doing about sort of like, you know, being the system of record for for how code like the archeology of code. You know, we are just just to restate we do we are building version control. You know, I say that that the, you know, a feature flag being merged is essentially equivalent to a pull request, but that means that in order to have a feature flag merge, you know, you need you need a you need a discussion. You need a back and forth you need you need the code changes that are happening within that pull request to be to be part of the system so one of the things that that we observed about how software is being built is the we'll we'll call it comments right comments are everywhere comments are in get commits they're in pull requests they're obviously in the code, but they're also in slack they're in Trello they're in, you know, Jira, they're in email, all that sort of thing so we we want, you know, thinking big for the future. We want to system where we actually have that entire history built into into dark in some way so that any change that is made has that sort of like archeology based into it. And we are very much thinking about dark as a sort of as a project for as a tool for big for big companies for big users. And it is, it is not good for that use case today but a lot of the things that we are, we're designing that so like deploy this for example. You know, we're the features the essential features of it things like database migrations and feature flags are sort of like a best practice that are used by larger teams more than they are used by small teams. We're building all of our stuff on top of those because those are the really powerful ways of building of building this sort of like systems, regardless of whether you're you're a small team or large team so we are very much focusing on that. Do you also asked about about unison. We made a comment that this a lot of the concepts remind me of concepts that are also exploring using the first question was, this seems like a superpower for development for maybe an individual trying to bring something out quickly. But a lot of software in industry is built by large teams that are distributed and work on different parts of the system at the same time. So I'm curious like what are you doing to kind of make that reasonable in this kind of world. Well, I think I accidentally answered that and part of my first one it's, you know, if you the we are using sort of, you know, the tools. We generally don't like to reinvent too much like we're doing a lot of reinventing and kind of the core things beyond that these things are like well solved you know the using things like you know team is organized into separate repos into separate group separate permission structures that sort of thing you know there's there's no reason that stuff can't exist within dark. You know even even if the default is that you can you can instantly deploy, you know obviously that doesn't work for larger team. But you need, you need features like you know the permission of, of, you know, to code reviews or something like that in order to go out there's there's no reason that that can't be backfilled into into dark as it exists today. Only difference being the merge button doesn't you know kick off a pipeline that puts the container into etc, etc, etc. I'm talking about the unison thing though so very familiar unison have been have been following their projects since about 2017. One of the interesting things that unison is this sort of content, what's it called content address hashes or functions. We have a thing called function versioning which is sort of similar when combined with this other feature we have which is called locking which I didn't really get into. But basically when you have code and production, it locks and it can only be changed by making feature flags and that's to sort of have this safe thing. So if you version things unlock them that it's essentially the same as content address functions. But we do have sort of the same problem that you get from content address functions which is that when you are changing something that calls it or something that calls it something calls it the whole way down. You have to, you know, change some you have to change the whole stack. And so without that is actually how it's not exactly how it works now in dark but how it is going to work in dark. So if you want to put a feature flag that's like three steps in that creates a whole call stack for new functions, which which is fine. You know these that is that is sort of how it's supposed to work we don't want. We specifically don't want to break any existing stuff in production things should only break by deliberate changes that were chosen to be merged. So regardless of whether those are those are instantly merged. We want that to be true and going back to your question about like large teams. We think this is a feature that is especially beneficial for large teams, because if you go make the change in existing function. In a large code base, you have a very small chance of like understanding what the ramifications of that are in terms in services that you, you know aren't intimately familiar with. So we don't want people to you know be changing foundational libraries or you know the utils package and suddenly everything is broken. We want to make a new version of that function that has that bug fix, and we want then all the teams to choose to opt into that we have a deprecation system built in, so that we alert you when things are deprecated. That's all. Okay. Um, john question. Yes. Sorry. I. Oh, John. So, just real quick. This sounds like it's going to cost me a lot of money. If I wanted to run a big application of it, like, how are you going to charge me. How do I know how much I'm going to have to pay for. Great question. Well, you know the obvious answer is that that it is, you know, several years away from being suitable for for a large applications, but we'll go with the theoretical answer instead. Our intent is that it should cost, you know, roughly double what it would cost to build yourself. So if you were running yourself something written in, you know, node or go or something like that. It would cost significantly more, you know, obviously there's a premium, but not, you know, not a 10 x premium. And part of the ways that we intend to do that is that because we kind of have control of the system we are responsible for the optimization of the system. So, you know, if you want to lower the amount of observability that's happening you should be able to do that yourself to save costs. But, you know, if you wanted to go faster, or to be stored in a more appropriate data store for your use case. That's something that we want to own ourselves. And we want to, you know, kind of optimize the running systems. But again, we're a lot of years out on that. Okay, John story. Thank you. Well, John can now ask my main question. Because because I looked at this and I just said, Yeah, that's kind of cost money to deploy. It's scale. But I do have some other questions. Where are you. I went through your message on profile by the way, congratulations on being Irish wise choice. Thank you. 1100 and you follow 1100 people if you actually read that thing. That's impossible. So, no, it's a nightmare. What I did when I signed up was I followed all my followers. And so now I have way too many people to follow and yeah I don't like the content's really good though so like I unfollowed boring people and now I'm still left with this so I don't know I don't know what I'm going to do about it. I think your answer to my first question was embedded in your previous answer which is, you're probably not looking to let people deploy this on tram are you. That's right that's right so it's, it's very much designed as a system that we are running. And in particular. So think about this, you know, the sort of like upgrading the language and standard libraries and, and, you know, the on disk representation and all the things that we don't want you to think about. We, it is sort of predicated on this idea that all dark code runs on our servers and all dark code is stored in our databases. And that's, that's something that like is another concept, I suppose of dark is that that we draw a big circle around things that that we call accidental complexity. So you know everything from, you know, running the pager to, you know, database upgrades and whatever else. If you don't want someone using dark their first experience be like, oh, now install Kubernetes and then you can deploy this or, you know, get this deployed somewhere and then you, you can start to build it's very much designed around, we run this for you. And, you know, you don't have to think about all the other stuff which we are broadly calling accidental complexity and apologies to people who have, you know, DevOps or ops in their job title who I'm sort of calling accidental complexity here. I understand this. We've had this criticism before. But yeah, we want, we want that to like be reduced to near zero. Most of it by the design and system but a lot of it by just like we run it for you. And my second question and I think I can infer from the timeline and the project. So they're going to be people who want this system badly, but to care less about dark and we're going to use a transpiler from something they're more familiar with that they're right back in fables like you have sharp something like that. Yeah, is there, is there any thought towards a future set of plugins where they can plug that type of functionality. Um, no, no, not not not really the we're not really intending for this to be the system that people use with something else. There are, it's sort of designed in a way that like, you know that there are observability sites out there you know if you want observability you can you can use honeycombs automatic instrumentation or something like that. There are hosting companies out there if you want a serverless net or serverless F sharp or serverless or camel, you know that's that's relatively straightforward with, you know a couple of hours of DevOps but then you have it. So we are not interested in being, you know, one of those things we are interested in what happens when you enable all of this and how do we get like this radical simplicity which I believe comes from the fact that it is an integrated language editor and platform. And a lot of that stuff like trace driven developments like, you know, theoretically you could take, you know, your observability stack, hook it up to your vs code stack, hook it up to your language plugin and run time and that sort of thing. And that sounds like a total nightmare and one of the reasons that we're not as I started. But also, you know, I think that's that's fundamentally hard it's it's, you know, actually building that as a technology would be incredibly difficult whereas what we do is we write an interpreter. And we run the interpreter in the cloud and we compile the interpreter to your browser. And, you know, that's hard enough as it is that's an awful lot of work. So, yeah, not not looking at doing it for for kind of other stacks or that sort of thing. Thank you. But does a hand up in the in the room I guess. Yeah. Right. Number one, I've seen the dystopian future that is service measures, and I also have the help deployment 800 kilobyte state file. I haven't figured it out by the way so if anyone wants to help me with that. I think the deal is I believe the secret, which will then maybe solve the problem or destroy our ability. All right, so that's where I'm coming from I like this. I will just tell you, I was trying to figure out where this fits and I'm just going to tell you you're going to hate this for that. Program programming language about to and integrate it with the ERP like SAP. This is, this is incredible. SAP is so hard. And this, like you don't have to worry about scale because they're already paid through the nose, like whatever. Anyway, I'm going out there just by there was no question. Well, yeah, the idea, the idea, let's, let's, you know, attach it to something like SAP or something that's ridiculously expensive. It has occurred to us. We, we are still in the, you know, making this good phase. I know, you know, SAP probably isn't good anyway so it's probably fine. But we are focused on on the lower end of the market right now until it's good. It does sound like this, this is an opportunity to the test that they think you don't have to make it. I don't know what it means. Okay, so I want to jump in here. All these different features of, you know, programming, so the editor version control all this nice and, and I think it makes me think about Richard him. Light, but it has this fossil working control that kind of into the thing. So it's cool tickets in a way that has tech notes which I don't understand what they are and all. We're having, we're having audio issues I can see it in the face of the other people on the zoom call struggling to hear the question. Yeah, you just got to stand by the mic. Okay, okay, so you were talking about sort of integrating multiple elements of programming so the version control editor or all this kind of thing. And I'm wondering about where do you draw the circle of what should be integrated and what shouldn't. Where we draw the circle of what should be integrated and or what should be integrated and what shouldn't. So, I actually have a graphic for this which I did not put in the presentation. But the, the, the idea is sort of like, you know, as much as possible. If if there's something that you define, or that that that could reasonably be called accidental complexity for building applications, then it goes in the circle. And that at least is sort of the big vision of dark the sort of, you know, cut down vision, you know, means that that at some point we may need to to compromise that in a bunch of ways. But, you know, when, you know, presumably dark takes off at some point and and then we we have revenue and you know, funding and the team and you know all that all that sort of thing. Then yeah we're, you know, we're planning on everything from like security and ops and and you know the everything to sort of live here. And that really all you need to think about is is the code and the we, if you sort of like look at no code startups we think we're in this sort of like adjacent space which we call just code where no code allowed you build applications with without thinking about the deployments without the hosting without thinking about like all this sort of thing. And we, we, you know, think code is fundamental to writing applications but we think they have it right that you shouldn't have to think about like all that sort of thing and that should be, you know, part of what you paid for you know that there was a question earlier, is this going to be really expensive, well, you know, presumably it's going to be expensive but also, you know, you're going to be able to do, well, you know, to have half the team or you know hopefully build twice as much with the team that you already have. John has his hand up, I believe. Yes, so it always strikes me as is. Well, two things. What is a lot of what you're calling accidental complexity is unfortunately evil deliver complexity so. Weird of that. But it also reminds me very much of the experience that I had in 1981 writing basic. Like on a main train, you know, it better traceability I'll give you that. Otherwise, it's very much the same thing which I don't know what that means but that's, you know, there you go. In the sense thoughts that, you know, before you had this like giant mess to get systems and all of a sudden you had this, you know, interpreted language. Code and it tells me what it does. Right. You know, it was a huge advantage over punch cards. Yeah. Yeah, I can imagine that. Honestly, compared to what I live with today. This stuff sounds like almost as much of an advantage over what I have to deal with today, which really today was debugging a PowerShell script that somebody had inadvertently messed up that broke everybody's compilation process in my entire company. Yeah. In the, in the basic metaphor, your CI CD system was was the punch cards compilation process that took hours and was asynchronous and, and instead you just got to type code straight into that. I can say that that's that's a very similar. I have been before you were born, you know, born. Yeah. So, I'm going to make a little comment about the large language models. I'm going to assert that the only thing they can actually produce is bullshit. And that is, I don't know, 15 years ago I read a book by a Harvard professor, who's a philosopher is called on bullshit. And the basic point of the book was that like a liar knows the truth and is trying to hide. Somebody's telling the truth is trying to tell the truth, but somebody who's bullshitting is just telling you something, and they don't care about the truth. Large language models have no concept of truth. Yeah, I mean, if you get a better large language model, it's just a better bullshit. But I'll just do that. Yeah, so the, I'll tell you why why I sort of, well, so you know fundamentally I agree with that right there, they are just text predictors. Yeah, they lie, they hallucinate, you know, they do all sorts of things, it's easy to trick them, you know. But I think that empirically, they have been good at generating code. And, you know, even if the code is a lie, you know, even if it's like, you know, doesn't do what it says in Latin, it is, it is an interactive process with the human and the code itself runs a little bit later. You know, I think that there is a future where, you know, the, the AI, you know, has the state stored in the database itself and we're in like an open AI runtime where we speak to it and, you know, sort of like talking to the user, but we are, we're a long way from, from that. And like purely from a technical perspective but also obviously from a, you know, you want your thing to not be a bullshitter. But I think the fact that it's a bullshitter today is actually fine for the use case of writing code and I think that, that, you know, my own play with it it's like, you know, code it generates code that kind of mostly works which is, you know, a lot like copying from Stack Overflow which is what most of us do for writing code. So it's not, like, do I think that we're going to just deploy immediately the sort of chat GBT thing? No, we need safety and, you know, that's built into like, to the dark deployment model, right? You know, there's feature flags and cover views and that sort of thing is built into the idea. But I do think that, you know, one, it's going to, it's good enough. And two, that it's, that it's only going to get better. And maybe better is still lies or bullshitting, but it is also like working code. Okay, so I want to thank you. I want to stop the recording and then we will go into our non-recorded Q&A, which is often a little more lively. People are a little less restrained, but this was so super interesting and super great and really just really interesting and fascinating. So I want to thank you very much. I appreciate it. And now I'm going to figure out how to stop the recording.