GStreamer gets funding from the Sovereign Tech Fund to rewrite parts in Rust

One problem with working for the Sovereign Tech Fund is that insistence on paying in Sovereigns. Bags of coins in this day and age . . .

One problem with working for the Sovereign Tech Fund is that insistence on paying in Sovereigns. Bags of coins in this day and age . . .

Considering that 1 Sovereign coin is worth aprox £400 I think they would be quite happy :)

Let's see, at the current exchange rate £400 = €468, so €203,000/€468 ≈ 433.8 Sovereigns. Sounds like a good bag or two to me!

I totally misunderstood "GStreamer"...... I had all these dollar bills ready to go as well.....

Honestly not a big fan of Rust.

It makes writing code ridiculously complicated, everything needs awkwardly added function calls (want a variable? Here you go "variable.wrap().unwrap().rewrap().is_this_safe()?.unwrap_or_else(|..| yes_no?).expect('oh no!') ") and just leads to code that is practically unintelligible unless you understand everything about Rust.
I once couldn't stop laughing when I made a string copy, it's like trying to thread a needle, but with both hands tied behind your back to make sure you won't accidentally poke yourself.

However, its modularity and concurrency safety while maintaining C-like speed is indeed quite well suited to a project like that.
Can't say I blame them.

Oh, and the error messages in Rust are pure magic, very helpful compiler.


Last edited by TheSHEEEP on 17 January 2024 at 9:17 pm UTC

Honestly not a big fan of Rust.

It makes writing code ridiculously complicated, everything needs awkwardly added function calls (want a variable? Here you go "variable.wrap().unwrap().rewrap().is_this_safe()?.unwrap_or_else(|..| yes_no?).expect('oh no!') ") and just leads to code that is practically unintelligible unless you understand everything about Rust.
I once couldn't stop laughing when I made a string copy, it's like trying to thread a needle, but with both hands tied behind your back to make sure you won't accidentally poke yourself.

However, its modularity and concurrency safety while maintaining C-like speed is indeed quite well suited to a project like that.
Can't say I blame them.

Oh, and the error messages in Rust are pure magic, very helpful compiler.

Heh, I laughed surprisingly hard at that first part. I had really similar feelings while learning Rust, though after a while I wrote most of it off as just not-the-way-I'm-used-to-itis.

In addition to those features you mentioned, its easy compatibility with C code that makes it the future. It's (relatively) easy to do things like this, rewriting old parts of a large, mature code base like gstreamer, that seem to have cemented its future. I guess way more of this will keep happening in the next few years.

Heh, I laughed surprisingly hard at that first part. I had really similar feelings while learning Rust, though after a while I wrote most of it off as just not-the-way-I'm-used-to-itis.

Of course you can get used to it and understand it.
Hell, you can get used to abominations like Objective-C. Which Rust thankfully isn't as bad as.

But there are just objectively much harder to parse languages (as in, read and understood even by uninitiated people). Due more complex structures in Rust code than you'd find in C-code.
C++ can get nightmarish to parse on its own, but more rarely so and in cases that can usually be auto'd away nowadays. And pure C code is just very simple to read as it "lacks" (I've grown to think it's a feature) all the bells and whistles of C++.

With Rust, you get a lot more special characters (&|*::<>?!..'+) throughout the entire code outside of calculations, more function calls per thing you want to do and once type specifiers and lifetimes come into play, all hope is lost to the uninitiated anyway ( what's this type do, why is there a ': "Box<Fn() + Send + 'static>" ).

It's not that it couldn't be understood, it's that it couldn't be understood quickly except by experts.
And if I have learned one thing in 15+ years of coding, it's that the most important attribute of code after "it works" is that it is easily readable to people new-ish to the project and/or the language.
Because code is hundreds to thousands of times more often read than written and lack of understanding leads to way more problems down the line.


Last edited by TheSHEEEP on 18 January 2024 at 7:40 am UTC

Honestly not a big fan of Rust.

It makes writing code ridiculously complicated, everything needs awkwardly added function calls (want a variable? Here you go "variable.wrap().unwrap().rewrap().is_this_safe()?.unwrap_or_else(|..| yes_no?).expect('oh no!') ") and just leads to code that is practically unintelligible unless you understand everything about Rust.
I once couldn't stop laughing when I made a string copy, it's like trying to thread a needle, but with both hands tied behind your back to make sure you won't accidentally poke yourself.

However, its modularity and concurrency safety while maintaining C-like speed is indeed quite well suited to a project like that.
Can't say I blame them.

Oh, and the error messages in Rust are pure magic, very helpful compiler.

That's not how you write actual Rust code though: most of the time, you use constructions like `let Ok(var) = ` or variable?. The sbippet you showed looks like you haven't really looked at how to write actual Rust and just tried to write C in Rust which doesn't work. I also used to write Rust like that, but when I watched this video it clicked a lot more. In other words, Rust seems more messy at first but it has has a lot of ways to make code more readable. And yes, it does take longer to get used to, I struggled at the beginnijg as well. It is a trade-off: Rust surfaces complexity in syntax, while others hide it. This is why Rust can be so fast, secure and stable. The errors you need to handle in Rust are also ones that can happen in other languages, they just hide that complexity and crash when something like that happens. These are languages like C or Python. There's a place for both, but Rust is a really good language to use for fundamental libraries like Gstreamer because of these properties.

The sbippet you showed looks like you haven't really looked at how to write actual Rust and just tried to write C in Rust which doesn't work.

Not at all. I know Rust and been working with it on and off in projects. I wouldn't consider myself an expert, but I can work with it just fine.
Obviously I exaggerated in that example, but you'll find code akin to that in every single project, simply because of how Rust works. Rust's safety comes at a hefty cost.
There's just no denying that, at least not if you are being honest.

I am in the nice position that I work on many projects with many languages and many people of different levels of knowledge in the languages, so I have the advantage of not being too tunnel-visioned when it comes to a single language that I couldn't see its downsides anymore.


Last edited by TheSHEEEP on 18 January 2024 at 8:56 am UTC

One problem with working for the Sovereign Tech Fund is that insistence on paying in Sovereigns. Bags of coins in this day and age . . .

Considering that 1 Sovereign coin is worth aprox £400 I think they would be quite happy :)

Much better that kind of Sovereign than the Mass Effect's one

One problem with working for the Sovereign Tech Fund is that insistence on paying in Sovereigns. Bags of coins in this day and age . . .

Considering that 1 Sovereign coin is worth aprox £400 I think they would be quite happy :)

Much better that kind of Sovereign than the Mass Effect's one

Yeah one of those is one too many!

I once couldn't stop laughing when I made a string copy, it's like trying to thread a needle, but with both hands tied behind your back to make sure you won't accidentally poke yourself.

 
    let string1 = String::from("Hello, world!");
    let string2 = String::from(&string1);

    println!("Here they are: {} {}", string1, string2);
You can write spaghetti in any language, Rust enforces a couple of pretty basic rules and most times when you are actually having to thread code through unwraps and whatnot you are dealing with nullability. And sure, languages like C and C++ will let you just bulldoze your way through that, you'll probably just catch a segfault at the end. :)

I once couldn't stop laughing when I made a string copy, it's like trying to thread a needle, but with both hands tied behind your back to make sure you won't accidentally poke yourself.

 
    let string1 = String::from("Hello, world!");
    let string2 = String::from(&string1);

    println!("Here they are: {} {}", string1, string2);
You can write spaghetti in any language, Rust enforces a couple of pretty basic rules and most times when you are actually having to thread code through unwraps and whatnot you are dealing with nullability.

Maybe I should have mentioned it was in an Option in a Result and also containing a Mutex (or another permutation of that situation, I worked with in a REST project back then, don't fully remember), it wasn't just the simplest possible case.
Working with only base types is fairly rare in Rust, at least in my experience, which is doing more high-level code and not so much low-level calculations (low-level is generally the most "pure" and easiest to read).
Usually, you have at least one additional layer around things, and that can quickly spiral, too, where you might end up with Lists of Options of Results of different types from several different libraries you are using in tandem but need to tie together somehow...

And sure, languages like C and C++ will let you just bulldoze your way through that, you'll probably just catch a segfault at the end. :)

Unless I'm working on something that must never fail or is highly concurrent, I'd rather have a segfault that I can quickly fix than always writing more code than I feel I should need to.
Besides, I had plenty of runtime crashing with Rust, too. Sometimes in our own code, sometimes in libraries we used. It's not like Rust code automatically has no runtime errors.
The "error safety" of Rust is somewhat overrated. It's certainly safer than C, but far from "safe" safe.
So you still have to do all of the testing routines you'd do in any other language, not really saving you much time there.

Again, I'm not saying Rust is bad.
It's pretty good. It has very clear advantages and disadvantages. Depending on the project, I wish I was working with it instead of what it is I'm forced to use.
I'm just somewhat annoyed by (some) Rust fanboys seeing only the good bits and brushing the downsides off as "you just don't know what you're doing", is all.


Last edited by TheSHEEEP on 18 January 2024 at 2:25 pm UTC

Heh, I laughed surprisingly hard at that first part. I had really similar feelings while learning Rust, though after a while I wrote most of it off as just not-the-way-I'm-used-to-itis.

Of course you can get used to it and understand it.
Hell, you can get used to abominations like Objective-C. Which Rust thankfully isn't as bad as.

But there are just objectively much harder to parse languages (as in, read and understood even by uninitiated people). Due more complex structures in Rust code than you'd find in C-code.
C++ can get nightmarish to parse on its own, but more rarely so and in cases that can usually be auto'd away nowadays. And pure C code is just very simple to read as it "lacks" (I've grown to think it's a feature) all the bells and whistles of C++.

With Rust, you get a lot more special characters (&|*::<>?!..'+) throughout the entire code outside of calculations, more function calls per thing you want to do and once type specifiers and lifetimes come into play, all hope is lost to the uninitiated anyway ( what's this type do, why is there a ': "Box<Fn() + Send + 'static>" ).

It's not that it couldn't be understood, it's that it couldn't be understood quickly except by experts.
And if I have learned one thing in 15+ years of coding, it's that the most important attribute of code after "it works" is that it is easily readable to people new-ish to the project and/or the language.
Because code is hundreds to thousands of times more often read than written and lack of understanding leads to way more problems down the line.

The first ~four years of my professional life were largely coding Perl.

There's really not much more to add.

Maybe I should have mentioned it was in an Option in a Result and also containing a Mutex (or another permutation of that situation, I worked with in a REST project back then, don't fully remember), it wasn't just the simplest possible case.

 
fn make_copy(value: Option<Result<Mutex<String>, String>>) -> Option<String> {
    if let Some(option) = value {
        if let Ok(mutex) = option {
            let string = mutex.lock().expect("Failed to acquire lock");

            return Some(string.clone());
        }
    }

    return None;
}
Even in this pretty pathological case where you are nesting containers like this, it isn't exactly complicated. And all of these steps are going to be necessary anyway, you might be allowed to read-write a mutex without locking it or attempt to read a null pointer in other languages but it almost certainly is not correct. And if you are developing something that can fail then you always have the choice to `.unwrap()` or `.expect()` your problems away. As a bonus when those fail, you'll get told exactly where it failed rather than needing to go through your the core dump from your segfault.

The "error safety" of Rust is somewhat overrated. It's certainly safer than C, but far from "safe" safe.
So you still have to do all of the testing routines you'd do in any other language, not really saving you much time there.

You have to always do testing, but it's debatable whether you have to "do all of the testing routines" compared to other languages. In some cases you can just API design some error scenarios to be wholly unrepresentable, whereas in Java or something any object can at any point be null and you either test for how your system deals with that or you let it die. Not to mention the nature of the beast by default limits the scope of entire categories of errors. Runtime errors exist, sure, but outright crashes are rare.

Again, I'm not saying Rust is bad.
It's pretty good. It has very clear advantages and disadvantages. Depending on the project, I wish I was working with it instead of what it is I'm forced to use.
I'm just somewhat annoyed by (some) Rust fanboys seeing only the good bits and brushing the downsides off as "you just don't know what you're doing", is all.

I get that Rust fans can be annoying, like all programming language fans, but I disagree strongly with the notion that Rust makes things necessarily "ridiculously complicated", especially with the kind of hyperbole you were throwing around. Yes, I understand that you can write some real spaghetti with Rust but as a language it's not unique in this regard. And after a bit of time with the language you'll start to see why Rust was giving you trouble with a particular approach and you'll learn approaches that work out better. And often those approaches involve less nested containers too.


Last edited by Samsai on 18 January 2024 at 7:12 pm UTC

To anyone dissatisfied with Rusts complexity I recommend looking into hare.
It's a really nice, minimal systems programming language. In some ways it's even simpler than C
Its tool-chain can already be found in repositories of some of the distros, also bootstrapping it is a breeze.
Despite sparse documentation it is not that hard to pick up and the source code of the standard library is very easy to read and understand

Whatever happened to Vala? That always struck me as kind of a neat concept, assuming it worked.

To anyone dissatisfied with Rusts complexity I recommend looking into hare.

Can't mention hare without mentioning zig. Similar to hare with some compelling features of its own like comptime and powerful C/C++ compilation tools.

I would say zig has more traction than hare but Drew DeVault is great!