 Okay, let's start the next talk. So it's from Karsten Gebert. He's been talking about that. He's working together with colleagues that provide, that work on a visual thing. And how I understood that his job is basically to provide services for them, provide, and out of this combination comes the requirement to target the .NET platform. And he's doing these services in F-Sharp and he's showing us how he's using Nix in this context. Yeah, hi. Yes, this is basically, I should probably begin by introducing myself. I'm Karsten Gebert. I work for a company called N-Sync Gamberheim. That's a very small company here in Berlin and Frankfurt, in fact. And I should probably say, if you want to look me up, that's how. So I work for this company and I have a background in not in computer science, but actually in the arts and music. But I later came to realize that computing is much more fun and went on to become a programmer. And ended up in this whole web programming thing. But recently I changed jobs to this company. And basically what we are doing there is actually maybe I should continue. I'm really into functional programming, obviously. That's kind of why there was this little cute lambda thing. Mainly because I went actually to the Netherlands last year for a course in Utrecht to learn Haskell. And that was actually for the excellent experience. Mainly interested in systems for programming nowadays, distributed computing, a little bit of the web, not as much as I used to. And audio visual, that's actually quite interesting to me. And I only recently started to use NYXWA as properly. I tried it out, I think it was a year ago. And then I had to give up because I just couldn't really, I didn't have the headspace to figure it out for myself. So but yeah, so I'm a very new user of this. And so it's very interesting for me to have seen all the talks already. They have been very enlightening. Yeah, so now I'm going to talk about the company that I work for. Basically our main business domain is exponents. Or how do you say it? You have fairs, and you put little pieces of interactive installations that people can play with. And we put together these exponents as well as we make shows in this particularly interesting, but weird little programming language called VVVVV. There you can see a little screenshot. It's visual programming. So you connect the boxes to wire up the logic. And then you can see it uses DirectX to render stuff. Or it can use anything to render, but mostly DirectX. And so my job in this company is not this. It's actually I write or I'm the only programmer. I work on a system that integrates with this programming language to basically create and run shows out of basically. So this was this year's international auto ERR in Frankfurt. It's like the big car fair. And you can see on the screens that was like a 16 machine installation where we ran this installation for Audi, which is depressed with just 15 minutes of full on 16,000 pixels in a wide. So it was quite a nice installation. But yeah, everything in Windows, unfortunately. But this is actually, but now that I know that there is support for Windows, and I have heard about this Nix, it's actually, this looks like the way forward to deploy our things. But anyway, yeah, so this is kind of what we do. And yeah. OK, so what I'm talking, I would like to go over what I'm going to do now. It's basically, I think I propose this as a talk about microservices and deployment. And then I realized, hey, actually, developing with the .NET platform on Nix is actually, you can do it. But it's not integrated into Nix at this point at all, or not much. There is a little bit of work done. But it's somewhat orthogonal to the workflow that I have. And many .NET people have. And so I'm going to, I realize I have to actually do something more about how to integrate the .NET platform into Nix. So such that it is a workflow that might actually work for people who have to develop for .NET. So yeah, I'm going to give an introduction on this, how I went about it. I want to, again, repeat I'm not an expert in Nix or F-sharp yet. So I'm sharing my personal experience and impressions that I gathered while having worked with it so far. And yeah, my approaches obviously have a couple of rough edges. So help me improve it if you can. And it's also my first talk. So criticize me, but gently. Yeah, so what? Let's explore some basic aspects of F-sharp. I think that's quite worthwhile because it's actually, even though it comes from Microsoft, it's actually quite a nice language. It has some really beautiful parts. And yeah, that's something I would like to show you. Then let's really look at some F-sharp code, obviously, that makes sense in this kind of talk. And I think what's more relevant to most people here in the audience is examine strategies, how to package applications in libraries for Nix. Because I ended up doing quite a bit of work on that in the process of preparing the talk. And again, if we have some time, I can show you how I constructed this more service and my little hacky way of deploying it. So yeah, what is F-sharp? It was developed in 2005 with Microsoft Research by Don Simon and maybe others, probably, actually. And it's basically a .NET implementation of the OCaml programming language. It's functional first, strict, but actually a multi-paradigm programming language, meaning it integrates object orientation into it, as well as functional programming patterns. It's a first-class citizen of the .NET ecosystem, so it's fully supported. It can talk to other libraries written in other .NET languages. So the interop is very good, and which lends itself to actually a really big ecosystem of existing code that is quite valuable. What it does, it compiles to bytecode and runs on the CLR, which is the runtime environment. And this is kind of, in so far, relevant as that most of the ecosystem is revolving around these DLLs, which are compiled libraries, and not much is compiled from source when you work with it. Oh, and it has a head-of-time compilation with mono. That means you can actually produce similar to Haskell. You can produce more or less standalone applications. The ecosystem, it's free software. That's really great. It runs on mono and on the Core CLR, which was recently open sourced by Microsoft, and both of which are already in NICS. So it's easy to get started. And it all feeds off the NuGet package manager and repository, which is sort of, I think it's broken in a couple of ways, but it's actually the de facto standard for this development approach. So you can't get around it. What the pros that I found, it has great integration with other languages. That means I can just have actually a mixed project that includes some C-sharp code that I've written now and I've written a couple of months ago, and now I start off rewriting some bits of the application in F-sharp, so I can actually reuse my code. And that's really quite good. There are lots of good libraries, one of which, for example, is the Akkad Net library that I'm now starting to use, which is an implementation of some design patterns of the Erlang programming language in .NET. Or recently, I stumbled across Embrace, which is a project to do cloud computing, make it very easy. And there's the Web-sharp project, for example, where you can compile F-sharp code directly to JavaScript so you can develop your entire application in F-sharp. So yeah, that also leads to the next point. It's a full stack language. You can just do everything with it, basically. And yeah, it's a good plan of principled and pragmatic approaches, which is actually quite nice. So yeah, there are some cons that are found coming from Haskell, where there's no type classes, so that makes you repeat or that makes you have to look for other strategies not to repeat yourself too much. And sometimes a bit noisy and quirky syntax, I have to say. That's one of the main things that kind of made me flinch sometimes. Yeah, and it does introduce some new nomenclature for rather common things like monads, called them computation expressions, for example, which is, well, you have to get around in understanding it first. And it's impure. That means you can basically do everything that you want inside a function. It does not guarantee you that the function will only do what it says in the type declaration. But who cares? It's not a big deal. I think it's good to look at some code. So there's the lambda calculus. So you can see you use lead binding, you use lead to bind top-level variables, as well as functions are declared the same way. And you can tell that this is how you define the input type for value. And this is the shorter version of it, and a partially applied version of that function. So yeah, and this is function application in the end, quite compact. And you can see this is a very common idiom in F-sharp. You will feed X to F in some way. And this is a very, you see this all the time, basically. If you want to construct a tree, that's how we would go about doing that. You can see that it's a recursive definition, basically. And another example of this kind of type, some type, is I use this, for example, in this application that I'm writing to model. You can use this to model for all the states that your system can be in. It's actually quite. And then use pattern matching against that. I'll show a little example of that in a second. This is what a record looks like in F-sharp. You, contrary to how it works in Haskell, you actually, this is not the name, does not become a top level function. But it's used as you would say, if P is a person, then you would call P.name to get to the name, which is actually better than Haskell, in my opinion. Say the, yeah, right. Yeah, exactly. There's a common option type from Haskell as well, and alias for a tuple. So yeah, that's quite. And it has classes. Wow. Actually, yeah, what can I say about this? I mean, I guess you define some fields here and assign some default values to it. And normally in .NET, you have these, or in C-sharp as well, you have these, you define properties which you can get in set, and some interaction with an instance of that class. And pattern matching, which is sort of a very nice way of destructuring values, where you can match on the data constructor of a type, in this case, an option type. And it's in the value that it encapsulates and do things based on that. Yeah, it has modules, also very nice. I mean, just like in most other languages that are relevant. I guess, actually, that's not true. But yeah, the modules, you declare them like this. And then you can have multiple of these in a file. And all you can use it as a top-level declaration. And you don't need all the indentation, but then it encompasses the entire file. And there are namespaces, which is another way to make a top-level namespace, and then have subsequently more modules in there. Yeah, there are a bunch of cool things we could look at. But maybe it's actually that I leave to the reader, I suppose, which are type providers that are a nice way to use reflection to construct type safe, to construct type safe, or to pull out information, for example, from a JSON. You pass it a JSON, and it pulls out information about the structure of the JSON, and gives you a way to create or pass those types of JSONs in a type safe way. But there are many different type providers out there. Monads or computation expressions in F-sharp would be interesting to look at. But quotation in the reflection is actually quite nice, because you can have compile time and also runtime metaprogramming. And units of measure are quite deeply integrated into the language. Also, mailbox processors, which is the actor model of programming that actually comes with F-sharp, which is quite a nice way of structuring programs. And of course, asynchronicity is also something that's very well integrated. F-sharp and NICS. So F-sharp now is packaged separately from Mono, and after some research, this is actually the right way to do it. Even though in Windows, it all gets put into more or less the same folder structure, and F-sharp will have access to the global assembly cache as well. But this is actually not a recommended practice. So it's actually fine the way it is in NICS. It's also been recently updated to the latest version in NICS. So yeah, you can take advantage of that. Yeah, as I already mentioned, usually package management in F-sharp or in .NET is done with NuGet and your favorite IDE. And you don't actually do any of this manually, which makes it a really big pain. Because I don't really like using IDEs. And that made me, I had to switch back to Mono develop in order to get started on a project on a different computer or in order to update the dependencies. Also, the problem with NuGet is that most IDEs manage dependencies on, and I guess I should say a word about how the projects are structured. Usually you have a grant solution, and the solution can contain multiple projects. The projects could be libraries or executables. And NuGet manages dependencies on the project level. And it can manage it also on the solution level, but it's very finicky. And sometimes you end up having, for example, a dependency on a JSON parser in one project where the version is much older than in another project of that same solution, and it's very messy. So NuGet is kind of terrible. And yeah, NuGet is also actually a web service that distributes these DLLs, these libraries of bytecode libraries. But there is some very promising, there's a new tool called Paket by Stephen Fogman, I think. And it's a very good replacement or newer strategy to deal with package management for .NET packages. And it fixes all the problems associated with NuGet, in particular what I just mentioned, but also a bug in NuGet where NuGet would, if it can't decide on a particular version, it would just use the newest one automatically and kind of can break your builds and cause havoc. Paket basically takes over the entire package management for the entire solution, as it does. It resolves dependencies globally and then distributes them to each, and then modifies each project such that it has always a consistent dependency graph across the solution. And I should show you, maybe, I can show you the XML. It's kind of not pretty. But basically, a project in Fsharp usually now with this Paket workflow starts by cloning this project scaffold, and then you run a build command, and it will bootstrap everything for you and set it up. And then Paket will take the Paket dependencies file and look into it, look which packages you want and which versions of those, and download them from NuGet, fix all the versions in the Paket log file similar to the gamphile.log, for example, for Rubyists, or I think there might be similar strategies out there for other package managers. And then it will modify the project file to reflect where to find, to tell it where to find all the dependencies for that project. And also, it will create this Paket template file. And yeah, so then the build tool goes into, it looks into the FS project file and looks where it finds all the references that are used in the project to compile. And it will find, OK, Paket has put them in this place. And yeah, it will be able to do its job. But yeah, but how does this, the big question then, while I was sort of working on this, was how does this workflow, which is the recommended F-sharp workflow nowadays, I guess, how does that integrate with Nix? And at this point, what we would need to do, if we want to use Nix for package management, we would obviously need to create and maintain all the packages for the Nougat dependencies. And I should say, there has some work has already been done. And but it's obviously because Nougat is a big repository. There's a lot of software on it. It's actually quite a tedious task, I mean, to get all of that reflected into Nix packages. And then if we had all those packages, we need to find and do what Paket does and actually manipulate our project files and create the right references to the dependencies in the project file with basically the paths to the DLS. And then also, in order to build it with Nix, we have to disable the automatic package restore, which is part of the build process, which Nougat does. So as I mentioned, some work has already been done. But at this point, very few packages exist, unfortunately, and the problem because there is no automated way to manage these references in the project files, it's at this point, this approach is kind of orthogonal to how people, or at least I guess I'm talking for myself, but how I would want to work effectively. So there might not be enough incentives at this point to do this, especially because the problem is that we'd need a tool to do all of this automatically, basically. And yeah, then when I was working on the example project for this talk, which I'm probably not going to be able to show to you, but I figured that, hey, I could look into Paket and see what does Paket do, what kind of APIs does Paket give me in order to maybe actually automate this whole process. And yeah, this is the, I guess I already said this. So I discovered that I could do this with Paket, and that's why I created this tool last week that automates the process. So what it does, it uses the Paket metadata that in the paket.log file that Paket creates once you've downloaded and installed all the dependencies for development. And it basically grabs all the dependencies out of there, the specific versions. And then it also discovers the projects and pulls out their metadata, i.e. for example, if I have a solution with a central library where all my domain logic lives and my types. And I have, for example, in currently, I'm doing the rewrite for our application. And they have a module that uses WebSharper to compile to JavaScript. It discovers that there are libraries and executables, and it will be able to discover that and create different NICS derivations for each, in particular, just basically creates a wrapper script for executables. Yeah, so that's what it does. It generates NICS expressions for all the dependencies. And one NICS expression per project. And then it creates the wrapper scripts in the... So maybe I should show you this. But OK. Oh, no. I might need this now. Let's make it a bit bigger. So this is the project. You can see the project layout. Here is the central sort of build file and source and tests and so on. And all packages land in here. So that's what Parquet does. And Parquet.NICS has some dependencies. I can show you quickly. Parquet.Dependencies. And you can see, yes, I depend on Parquet Core. And I had to pin the version because there are some additions to the public API that I needed to make in order to get this working. Yeah, and maybe show you in the source for the Parquet.NICS executable. You can see there is a reference as file. I don't know. Parquet.References. And what I use is I use Parquet Core. Obviously, that's my main dependency. And F Sharp Core because actually I don't need that in strictly speaking anymore. And this Parquet template file, which is also in every project in a solution, there's some metadata specified for that particular package. So if I went on to NICSify this project, then what I would do is I would build it first, obviously. And there's all kinds of stuff happening. Hope it builds. Ah, OK. Yes, I don't have internet. That's bad. Oops, sorry. Then this will actually fail. I'm sorry. Because what Parquet.NICS does is actually it goes through all the projects, gets all that metadata, and then it goes on to the NuGet repository to download all the packages and create the Shah 256 sums for it. But yeah, I can't access it. That's unfortunate. Wish I could have shown you. But anyways, and once this process is done, there's a NICS directory with a top level NICS expression that I can execute to install the project into to build and install the project and its dependencies into the store. Yes, so actually, and this was the main outcome of my research for this talk was basically, OK, I shouldn't really talk about necessarily about how to create a service, which I did know, and I can show you. But make this proposition that this could be actually quite a viable way of working with .NET on NICS. And it could be an approach how to start getting the .NET platform, getting better integration for the .NET platform into NICS, which I think is good because sometimes you have to write software for it like I do. And it's not too bad, and I think there's some value to it. But yeah, I think since I wish I could show it to you, but since I can't, maybe I can show you quickly the example project, the example project was the sequence of events was that I built first the example, and then I thought, oh yeah, now I just need to create a package for it and think about how to deploy it. But then I realized that it wasn't actually as easy to get it into the store as I thought it would be. So the project was built around the idea of using full text indexer and build a little API to search into all the nice functional programming papers that are on my hard drive courtesy of Oli, actually, he has a very nice level of papers. And so yeah, I built this little indexer, and we can quickly show you what it does. Source, papers scraper is the name, and it can show you the types first. Or actually, maybe I should show you the tool itself. It uses recall to index the papers, and there you can see this is how you would use it from the command line. And it has this kind of output. Normally, there's a GUI that you use with this, but so I modeled this in terms of a result row, which has, and I just focused on the abstract file name, MIME type, and the location of the file, and the overall query result with some metadata. And yeah, so I had to implement a parser for it, and this is also something quite nice, I guess, is that there is a really nice parser called F-parsec, which modeled after Haskell's Parsec library, roughly. And this is what a parser would look like, and in the end, I just skip ahead a little bit. In the end, this is basically parsing the result here. It just goes ahead and says, OK, look for an abstract line, look for a file name line, a MIME type, a char set, and a URL line, and then feed that into make row. And that is a function here that returns a record with all these fields. And then down here, there's just some wiring up where I start the command line process and return a list of that type of the result. And I just show you what it does quickly. There is a service, and now I need to get this across there, I guess. That's actually, let me do this, do this here. I need to start it again. And then here, I can use curl and say, OK, I want to search for everything, for example, and feed that into a pretty printer. Python, and JSON, and you see, you have a little API for the full text indexer into all these papers. Yes, I think since I couldn't, I think the takeaway that I would like to probably propose is that F sharp is actually a really nice language, in my opinion. And quite a few other people exist that think the same. And I think it would be nice to have better support in Nix for it. And I'm looking forward to feedback, but also to improving my approach to it, maybe, with your feedback. And if you have any questions, maybe now would be the time. OK, so we have only one and a bit of a minute left, so we can only have one question. Yes, so you created this packet to Nix generator. I think that's great work. I was actually curious on how you, for example, deal with the DLLs, because some time ago, I also tried supporting the Visual Studio infrastructure on Windows with Nix. And one of the things I found particularly tedious is how to load DLLs from arbitrary locations in a Nix store. Have you also dealt with this problem? Yes, it actually automates this. It uses packet to discover what the dependencies are and automates the process of creating Nix derivations for each of the dependencies. And because packet actually manages, packet basically puts everything into this packet package directory and the derivations for the program that you wrote expects, has a section where it references each dependency in that package directory. And what it does is that it creates a package for the DLL and then sim links that into this package directory at build time. And that's how it works. I wish I could show you. It would be nice, but I thought I'd have internet. But yeah, that's how it works. OK, thanks for the talk, Carsten.