So, hello, everyone. I'm going to talk about Rust, which is a programming language. And also about getting Rust into OpenSUSE and the current state of where we are.

So, yeah, so, I'm Christof Egerlund, I'm the architect for HA at SUSE. So, it has nothing to do with Rust, but I'm interested in the language, so this is kind

of my hobby. If you want to get the slides, you can get them from this URL. They will also be linked from the OpenSUSE events page, and I'll provide a PDF later.

So, Rust is a programming language, developed by Mozilla, primarily, as intended as a replacement for C and C++, really. The idea that they had was that they needed a new language, or they wanted to develop

a better browser that wasn't susceptible to security holes in the same extent that the current Firefox one is. They have a big issue with buffer overflows and memory leaks and other problems like this, and they were trying to figure out a way to solve that.

And so, one way would be to switch to a managed language, like Java or C sharp or something like this, which runs in a VM, but that comes with additional problems. So, if you run in a VM, and you have garbage collection, you have a runtime, you have

unpredictable memory usage, memory implications, so, basically, a modern browser is like a VM itself. It's hosting a bunch of processes, one for each tab or window, and it's hosting

additional VMs inside to run JavaScript and so on, so running all that inside a VM again would be okay, so we're starting to get too many virtual machines on top of virtual machines to have a viable solution, so what they wanted to do was be able to have a language that operates on the same level as C and C++ but avoids the problems that

C and C++ have in exposing too much of the machinery of the system, and letting you destroy yourself needlessly. So, the idea with Rust is that it's a language which makes it more difficult to

do things wrong. That's the basic idea. So, today, you can get the Rust compiler on OpenSUSE by installing from the devil languages Rust project, so, basically, the Rust compiler that we have now is a pre-built

binary package, so it's not yet ready to be included in the Tumbleweed because it's not building from source entirely, so to build Rust, you need Rust, so I'm going to get into more what that means, but, currently, you need a specific version of Rust to build

any version of Rust, and that version is not necessarily the version that we already have in OpenSUSE, so, yes, it's a tricky problem. We haven't figured out how to solve it. I'm going to go into more of that, but first I'm going to talk a little bit about the language.

Well, I think I've gone into why you want it, but so, yes, zero overhead, I see no runtime or VM or garbage collection. Memory safety, so a language which tries to prevent buffer overflows or pointer arithmetic so you can't just point it to random memory and cause problems.

You can still cause all the problems that you can cause in C in Rust. All Rust does is make it easier to do things right in the default case and more difficult to do things wrong, whereas C, for example, makes it exceedingly easy to

do things wrong and not even know it, and very, very difficult to do things right, so that's kind of the difference in approach. A side benefit of the way they chose to handle memory was that they also introduced thread safety as a bonus, and I'm going to go into a little bit about

how that works, but basically, the way that Rust handles memory has implications for threads that means that it's impossible to create a deadlock because you just can't write the code that would cause a deadlock unless you actually have unsafe blocks in there, or so, yes.

And, yes, the other thing is you want C-level performance, so if this, and easy operability with C, so if these are things that are interesting to you, then Rust might be interesting as a language. I know that there is maybe a little bit of a trepidation or fear because Rust can

be very hostile because it doesn't let you do things wrong, so it's just going to, in the beginning, no matter what you do, you're going to get a lot of error messages when trying to compile, but I'll get into that, too, in more detail.

So, here is a very simple Rust program. It looks similar to C if you look at it just like this. Already in this, there are a lot of things that are unique to Rust, for example,

the exclamation mark after print ln means that this is a macro, and macros in Rust are, well, I think they are most similar to macros in templated Haskell or Scheme, if you've seen those languages, and not at all like macros in C or C++, and also not

especially like macros in Lisp or something like this, so it's not as free-form as the

macros in other languages where you can just do anything in a macro, including like concatenating strings into new function calls, but it is quite good at doing some of the things, you know, in a safe way, so, for example, the print ln macro just adds a new line to the end of the string and then passes it to print, and that kind of thing is quite

simple to do with this macro system. To compile and run this, you use the Rust compiler, or you can use the Rust compiler just like you would use GCC, so you put this in the file,

call it hello.rs, you run Rust C, passing it hello.rs, and you get an executable just like you would get from GCC. There's no runtime, so it doesn't link to any big library or anything like that, but it is statically linked to the standard library that it has, so the binary

would become a fat binary. There is no dynamic linking. There is some support for dynamic linking, and they're working on making it better, but that's another one of the issues that we are looking at for packaging for OpenSUSE. We would like to be able to dynamically

link to OpenSSL, for example, and currently it's not that easy. So, to scare you a little bit, here's a bigger example. So, this is a Rust program which creates a second thread and uses channels to communicate between the threads, and has a shared hashmap,

where both threads try to insert into the hashmap at the same time, and then the main thread tries to read from the hashmap. This is the kind of thing that in C or C++ is quite

difficult to do in a thread-safe way, and in Rust, you can't write this code in a way that would not be thread-safe, because the compiler is aware, for example, that the hashmap is not thread-aware, so it won't even compile code that involves multiple threads using a

hashmap directly. So, what you need to do is you need to wrap the hashmap in a mutex, you need to lock in each thread, and if you do the locking incorrectly, the compiler won't even compile the code. You can also see a few other features of Rust here, so

you can use modules, so it has like a full module system, like other more modern languages, to include code from other modules. You can also, so here, for example, I'm calling std colon thread colon on without using use std thread first,

so you can fully qualify module names and access things that way. So, it has some nice features like destructuring, so you can declare,

so the channel function returns both the sending and receiving end of the communication channel for threads, and return these as a tuple of two separate things, and you can assign each to a name in one construction. The colon colon new is a convention for memory handling, so this

is simply putting this memory on the heap, so similar to new in C++ or Java, but the memory is actually managed at compile time, so Rust will ensure that you have the correct number of

allocations, and everything is, every reference is scoped, so this memory is freed when both threads go out of scope, so to speak. There's a few other niceties, like

pattern matching, that I will go into a little bit more. Something you will see a lot when you start looking at examples of Rust is this unwrap thing, so Rust doesn't have exceptions, unlike Java or even C++. Instead, functions usually return what is called result type, which is

an enum of either okay with the value that you were after, or an error, and it actually checks at compile time that you've handled all of the cases, so it forces you to check, oh,

is it okay? Then I do this. If it's not okay, then I do this other thing. So here, for example, it's saying, okay, if locking succeeds, assign the result to this M variable, and then let me access it within the scope of if, and then you can then put an else and handle the failure,

but in this case, it's just ignoring the error, and what unwrap does is let you continue if everything was okay, and panic, as in end the whole process, if there's a failure at this point.

So you see this a lot in example code, because in example code, you don't want to clutter it with error handling, but, of course, in a real program, you do want to handle your errors, and the nice thing with having the unwrap thing is that you have an explicit point in the code that says, okay, this is where it's going to crash if there's a failure, so the thing that

Rust does is make it very explicit where your failure points are, so this makes it easy to find the source of the problem. Yes, I'm not going to go into much more about this example

right now, because it's a little bit too much, but it's just showing an example of a little more realistic code than just the normal example code that you get for things like this. So, this is a little bit about how allocation is handled in Rust. In this example, we have the

main function where we allocate, so this is simply a five, like an integer, and it's put in the box which means that it's heap allocated, but its lifespan is scoped by the block in which it's defined, so box two here, for example, exists until the end of the main

function. You can create like a little scope like this to limit the lifetime of variables, so box three here is going to get created and then immediately destroyed, and then in this function, the box one, this value is limited to the scope of that function.

For example, Rust wouldn't let you create a box like this and then pass it out without handling that correctly, so in this example, we're

... Yeah, so there's a concept of ownership and moving ownership around in Rust, so that's how it's keeping track of memory is that the compiler keeps track of who owns

a piece of memory at every state of the program, so in this case, we start the program and we create two regular variables, and these are limited to this scope, so the owner is the main function in this case. We then create this five and assign the variable A to it, so

at this point, main owns A, so we can actually read from it and print it at this point. If we then create a second variable called B and assign to A, if we then try to here

access A at this point, it doesn't let us because the boxed memory that we assigned to A has now been the ownership has been transferred to B in this case, so Rust will no longer let us access A because A no longer owns that memory. That memory has moved on, so if you uncomment

this line and try to run this program, the compiler will say no, A doesn't own this memory, you can't access A any more. Then, in the same way, if you pass, if you create a variable B, and then you pass that to a function like this that takes a box, the ownership is transferred to

that function, so if you try to use B after this point, the compiler will no longer let you. It will say no, destroy box owned that memory, and at the end of its scope, the memory was freed because the owner of that memory went out of scope, and so it's no longer available. I freed

it. At this point, you would probably say, wow, this is completely unusable. How can I, if I can only use a variable once, how can I do anything? If I put destroy box in the loop here, it won't compile because only the first iteration of the loop,

it will pass the ownership in that intuition to the function, and then free the memory, and the compiler will say, well, I mean, second iteration, there's no memory any more. You can't do this. So, the way we get around this in Rust is with something called borrowing, which is where you can say, I'm still the owner of this memory. I want to call this function

and pass it this memory, and then I let it borrow the memory for a while, and then when the function completes, I'm still the owner, the memory is still mine. So, the way you do this is with the at here, where we're saying that in this scope, well, with the at here as well,

so in this scope, we're borrowing the memory of this point, which is a struct, just like in C, as three members. So, point is the variable, and main is the scope, which owns this memory,

owns this variable. We create a second scope in here, and we borrow it using the at here, and we can use it to look at it, but it's actually by default, the borrows are immutable,

or const, you would say. So, it can look at the values at the end of the scope, the main scope still has ownership, but we can't assign to it. So, to get a mutable borrow, we have to use the at mut, or mut, I don't know how to pronounce that, operator, and here, we can actually,

so the ownership is still maintained by main, but the right rights, so to speak, the right to modify the variable is temporarily transferred to this other scope, this other variable. We can assign to the structure in here, and then at the end of the scope,

those rights are transferred back, so at this point, the main point variable now has the rights again, and those rights are actually transferred when it comes to writing, so there can only ever be one writer to a piece of memory, so the compiler will actually make sure that there's

only one piece of code at any time which has the right to modify memory, and that is the reason why all Rust code is actually thread-safe as well, because this means that no matter how many threads you have, only one of them is at any point allowed to modify the

memory, and at compile time, it will actually verify that this is true, so that's pretty cool, but it's also pretty tricky to write code in Rust because of this. Another aspect of Rust which is a little bit different from other languages is what's called

traits, so the language which I think this is most similar to is Haskell, but it's also a little bit similar to the interfaces that you have in Go, so in Rust, you don't have classes like in C++ or Java. What you have is you have structs just like in C, and then you have

traits which describe collections of functions that operate on a particular structure, so in this case, we're defining a trait Animal, and we're defining a set of methods which

can be applied to an Animal, but we're not actually defining any kind of structure that implements this trait at this point, so there's no base class or there's no like root object that's like the default implementation. What we're saying is that there is such a thing as an Animal. We haven't actually described any yet, and these are not actual

functions that you can call at this point, so you need something that implements this trait, and the way this is done is you define a structure, and separately from defining the structure, you define an implementation of ... Okay, so this is just implementing some functions for

the structure, so it's saying that, okay, so we have a structured sheep, and separate from the structure definition, we define some methods for sheep, and this can be done multiple times, so you can have multiple blocks like this where you're defining methods that apply to sheep, so it's not like a class in that sense that it couples the data of the structure with

methods that can be applied to the structure. You can actually separate those, so you can have a library that provides methods for a structure that is defined elsewhere, and then we can implement the Animal trait for sheep, and implement these functions for

the sheep type in particular, which then lets us use these methods on sheep structures or other structures that also implement the Animal trait, and we can have a function that takes an Animal as parameter, uses the methods of Animal on it, and we can pass in the sheep

to that method, and this is going to work, and this is all more similar to C++ templates than C++ classes in the sense that this is all derived at compile time as well, so at compile time,

it's figuring out which method to actually call for the Animal in question, so the way you would use this is that you would create a variable like this, and here you can see a little bit of the type inference in Rust where it's figuring out that it needs to

actually call the function that creates the sheep because the variable that we're assigning it to has the type sheep, so that's a little bit tricky, but it actually goes the other way, so in previous examples, like here for example, we have a defined type

of an object, so we have some memory of a certain type, and then we just say, okay, let the variable point be that type, and then the compiler figures out, okay, so this is type point, then this also has to have that type, but in this case, it's actually

going in the other direction, so it's saying, okay, we have a generic function here that creates Animals, and we're assigning it to a variable of a specific type, then that generic function must actually be the sheep constructor, and so it can go in that direction as well.

All right, so I also put up, so this is the definition of println macro, so the macros are basically compiler plugins, so what this does is says when it sees the println macro,

it passes the expression that that macro was passed to this code, which is then at compile time replaced, and the difference between this and just having a function is that this is all done at compile time, so you can do, so here it's actually calling print and concat

when compiling, so at run time, the result is just a string constant. If you're used to using something like Ruby or Python or another language like this, that's just total nonsense, because there is no compile or run time in the same sense,

but if you're coming from C or C++, then there is an actual difference. The code execution in these macros happen when compiling the code, not when actually running the programme. So, I think, for learning Rust in the beginning, you don't

really have to use macros at all. It's more a neat feature later on, I guess. So, some of my favourite things about Rust so far is the match and iflet, which is pattern matching, so this is something from prologue and also Erlang, I think has a lot

of this, but it's also coming into other languages where you, at compile time, say, okay, I'm returning either this or that from this function, and the compiler can check

that I'm actually handling all the cases, so, in Rust, there is no null at all, so instead, functions can return optional values, so you will return, oh, it's either this object,

or it's nothing, and, at compile time, it will check that you actually made sure that you got what you expected, so there is no way to write code that is null, unsafe in that sense. Yeah, traits, I talked about, and then the next thing is

cargo, which is the package manager for Rust, and I know Lars is now looking at me like I'm crazy because we already discussed the pains of package managers in languages, but cargo is quite nice, and I will get into the problems of it for us as open suits of people later.

So, cargo is a tool that helps with using libraries and setting up projects, so, instead of using the Rust compiler directly, you can use cargo to manage your project, so the way you would create a new project for our little code that I showed in the beginning

is that you call cargo new hello, and it will create a Git repository for your project, and create a little main function for it, and everything, and set everything up so you can compile a binary from that, and the main definition of a cargo project is the cargo.toml

file, like in the file, similar format, where you would define the name of your project, the author name, the version of this project, and then all the dependencies of this project,

and also, if it produces a library, you would define that here as well, instead of a binary, and then to compile, you just run cargo build, and it takes care of compiling if it's necessary,

and so on, so that's quite nice. Together with cargo, there is something called Crates, which is the packages for Rust, so there is Crates.io, which is like a package hub, like for other languages, and the way you would use it is in your cargo.toml, you define

dependencies, so let's say we use the rand module for random number generation, we would define the version we need, and the dependency, and then we just call cargo build, and it magically, incredibly, just goes out on the internet, finds rand and all the dependencies for it,

downloads, compiles, great. So, yes, okay, so, now I'm getting into the problems with this, and where are we at right now? So, currently, the people contributing to the Rust packaging on OpenSUSE is this list. I think actually there are some more people who have gotten involved

since I wrote this, but the main guy is Mikael, I don't know if you're here. Great. All right. I will talk to you later. So, he's done most of the work in getting the compiler up to date, and getting cargo in there, and so on, but there is still a lot of work

remaining. So, currently, we have two main projects under devil languages Rust, there is the Rust compiler, and there is the cargo bootstrap which is the cargo compiler

thing, and the reason it's called cargo bootstrap is because it's not quite building itself in the right way yet. We're using Python project created by some Debian guys to build cargo without cargo, because the problem is that the Rust compiler is written in Rust,

so to compile the Rust compiler, you need the Rust compiler, and cargo uses cargo to build itself, so to build cargo, you need cargo, and figuring this out is not that easy. Right now, my goal is to get the Rust compiler at least into Tumbleweed by Rust version 1.10,

because they made a big, important change in their policies as of Rust 1.9, which is that they promised that Rust 1.10 will be able to build itself using Rust 1.9, and so on. So, if we manage to package Rust 1.9, we can then use our packaged Rust version to

build Rust 1.10, and by that point, we're bootstrapped and up and going, so we can push into Tumbleweed and remove the binary package for Rust 1.9, and when Rust 1.11 is released,

we can rebuild it with our 1.10 package, so this is very similar to the way you would have to package GCC from the beginning, so it's kind of a GCC is written in C, so you need a C compiler to compile GCC, so you have the same problem there. It's just a little bit trickier

than it might seem to actually figure out how to do this correctly. Yeah, so that's that. Cargo is even worse, because cargo is a cargo project with a long list of dependencies, so to build the initial version of cargo, we need to have like a fake cargo,

which, or a binary package of cargo, which we can use to build that version of cargo, and we need to get like the package management up and running to get this working, so this is kind of the point where we are at now, and this is the point after that where we haven't even

gotten to, so my idea for the future is that we will combine kind of the approaches of the Golang packaging stuff that the people, I think it's Marguerite Su, and of the project that has done most of that work for Golang to package Go modules as RPMs

and combine that with a little bit of how the Ruby stuff is managed using gem to RPM, which is quite nice, and I've started working on that. In my home project, there's something called cargo packaging, which doesn't work at all right now, but that's kind of

the point of where I'm at right now at looking at packaging Rust and getting it into OpenSUSE, so that's, yeah, then beyond this, there are a lot of unsolved issues with actually using Rust and getting it into SLE, for example, so there is no stable ABI for Rust itself, for example,

which means that if you compile your Rust programme with a certain version of the Rust compiler, that comes with a certain standard library, and if you update your Rust compiler,

you have to recompile your programme, otherwise it won't link correctly if you use dynamic linking, so right now we're limited to static linking, like building everything into one binary, which is not great for security updates and so on. The other problem is that the compilation of Rust

itself and Rust programmes is extremely slow and memory-intense, so to compile the Rust compiler, we need at least eight gigabytes of RAM, and right now I think the VM is defined to have 50 gigabytes of disk, and that's actually failing sometimes because it runs out of disk anyway,

and I don't even understand why, how it can possibly use 50 gigabytes of temporary memory while building the compiler, but there we are, and it also, right now, it needs its own custom version of LLVM to build Rust, because Rust is based on LLVM and they have some patches to LLVM, so that's another issue, we can't just use the LLVM,

which is already packaged for OpenSUSE, we actually have to build LLVM again just for Rust, so those are issues that are remaining to be solved, like the ABI problem is something that we can't solve, we have to wait for the Rust community or do it there, but it's also

one of the problems that I think is really difficult to solve, and the problem is that it's really only a problem for us as distributions, so it's only a problem for Red Hat and SUSE and a few other people, for Mozilla, for example, they don't care about

static linking, they just static link and it works for them, so that's one of the issues we have. Yeah, so my main point is please help in packaging Rust, if any of the people who were involved in packaging Go packages, for example, or Ruby for OpenSUSE want to get involved in

in helping out with Rust, that would be great, because I think, as far as I know, both me and Michael don't really know that much about it, about RPM macros, and this is all magic to us, we just want to get the compiler working, so yeah, any help you can give us, that would be fantastic.

Any questions? Yes, they have a microphone. When do you expect to be able to do the bootstrap of Rust, then, so that you can do the continuous updates, etc? So

1.9 has been released now, like, a few weeks ago, and they're on a six-week release schedule, so the next version of Rust will be 1.10, which will be released sometime in July, I think,

I'm hoping to have at least the Rust compiler ready to submit, or hopefully accepted into Tumbleweed by that time. That's my hope. All right. Thank you. Oh, another question?

Are there already some big software written in Rust? Yes, so there is, so the biggest project right now is the servo browser, which is being built by Mozilla, so this is the next version of Firefox, where next means not the next version, but sometime far, far in the future, so it's a

whole new browser. I think they've gotten pretty far in, like, standards compliance and so on, but when it comes to, like, actual browser features, they still have a long way to go. There is also, I know there is something called Habitat, I think, which is developed by the

Chef people, people who make Chef, which is a part of Chef somehow, which is written in Rust. I don't know exactly, I don't know anything about it, and I may have gotten the actual projects and details wrong. I think there are a few other, like, big projects, but not

anything very open. Like, there are big companies using it, but they haven't released anything publicly, but there is a lot of interest in Rust. I mean, it's still a very new language, it's still being heavily developed, so, I mean, if I were going to develop something for production today, I probably wouldn't use Rust right now, but soon, I think it would be

usable, yes. All right, yes. Thank you.