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

Quoting: Arehandoro

Quoting: F.Ultra

Quoting: Purple Library GuyOne 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!

Quoting: TheSHEEEPI 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. :)

Quoting: Samsai

Quoting: TheSHEEEPI 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...

Quoting: SamsaiAnd 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

Quoting: TheSHEEEP

Quoting: mattaraxiaHeh, 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.

Quoting: TheSHEEEPMaybe 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.

Quoting: TheSHEEEPThe "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.

Quoting: TheSHEEEPAgain, 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.

Quoting: JörmungandrTo 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!