Rust

[croquette@sh.itjust.works]

Where would you say Rust isn't the right solution?

We always hear how great Rust is, but I'd be curious to know where it isn't.

[jkercher@programming.dev]

I don't think you would get much traction on C developers' existing projects. C gives you the option to do everything your way. If the developer's paradigm doesn't agree with the borrow checker, it could become a rewrite anyway.

Most projects don't use the newer c standards. The language just doesn't change much, and C devs like that. This might get a better response from the modern C++ crowd, but then you are missing a large chunk of the world.

[stingpie@lemmy.world]

I struggle to learn rust because the semantics and syntax are just so awful. I would love to be enthusiastic about rust, since every seems to love it, but I can't get over that hurdle. Backporting the features into C, or even just making a transpiler from C to rust that uses annotations would be great for me. But the rust community really does not seem interested in making stepping stones from other languages to rust.

[pheggs@feddit.org]

I learned a bit of rust and I think it's just about getting used to it. It's fairly subjective, and people say the same about C++. I also prefer the C syntax because I find it's simplicity extremely elegant and prefer it to have fewer features. And I like it for it's consistency, on linux the FHS is based up on C, and it just somewhat feels ugly to break that consistency.

But I also acknowledge the advantages of rust.

[neatnit@discuss.tchncs.de]

Never used Rust but I'd like to point out the YouTube channel Low Level which covers security vulnerabilities (CVEs). He ends each video with "would Rust have fixed this?" and it's pretty interesting.

A very recent one is this: https://youtu.be/BTjj1ILCwRs?t=10m (timestamped to the relevant section)

According to him, when writing embedded software in Rust (and UEFI is embedded), you have to use Rust in unsafe mode which basically disables all the memory safety features. So in that kind of environment Rust isn't really better than C, at least when it comes to memory safety.

That's not to say Rust isn't still a good option. It probably is.

Again, I never used Rust so I'm just parroting stuff I've heard, take all of this with a grain of salt.

[ilikeboobies@lemmy.ca]

NT kernel also includes Rust.

[9point6@lemmy.world]

Oh really? I had no idea Microsoft was doing rust at all

[rumba@lemmy.zip]

Rust provides safety and protection.

Rust isn't as rapid as other options, has less library support, and porting existing code is relatively difficult.

IMO because of the workarounds you need to do to handle the memory safety, you end up with a lot more hard to solve bugs than you do with conventional languages. It should be noted however that the bugs don't end up being security vulnerabilities like they do in conventional systems.

If you have something that needs to be structurally sound and/or you have enough talented people willing to work on it, it's a great option. If it needs to be fast and cheap and you don't have a gaggle of rust developers on hand and it's already written in another language, it might not be the best solution.

[banshee@lemmy.world]

I've personally become pretty fond of the syntax and incorporation of FP features. In all fairness though, I haven't written much C or C++ for the last two decades.

Rust incorporates some of my favorite features from FP with handy green thread ergonomics. I'm not a fan of Go, so this gives me a great option for microservices when I can avoid Node.js.

[anonbd@techhub.social]

@rumba @Croquette They're is a lot of people scrambling to rewrite existing c projects in rust for what?
for example ffmpegs rust rewrite is slower than the c version we need more maintainers rather than creating new rust alternatives that have no purpose

[_stranger_@lemmy.world]

Old programs everyone agrees do exactly what they should are a perfect target for "black box" porting to a new language, where the only criteria for success are "it should function exactly like before, just more efficiently, while being more maintainable"

[rumba@lemmy.zip]

If you want to ignore re-making things out of memory-safe technology as an advancement, we don't really have anything to talk about here.

[anonbd@techhub.social]

@rumba making new projects in rust sure cool but when big projects that most of the world relies on etc ffmpeg crucially need maintainers and contributions rust isnt needed and is a waste of resources when C can do it better, faster and easier rust is a fast fade that will likely remain in the shadow of C. Tbh your glazing rust without looking at both sides of the argument so the picture op posted really is true

[greenknight23@lemmy.world]

a community that allows squatting to happen and does nothing to resolve the issue is going to be plagued with chaos in the future. it opens an attack vector for supply chain attacks and altogether breeds distrust in the platform entirely.

on the flip-side, a developer that squats on common library names in an attempt to garner support to resolve an issue and is ignored tells me two things;

1. this is normal enough that the community doesn't feel the need to address the toxic behavior
2. the issue of squatting isn't perceived as a high enough threat and they will take no action

in my case both of those observations tell me the community at large isn't mature enough or forward thinking enough to allow me to use it as a solution. it also forces me to assume that the matter of toxic behavior will only continue to fester unchecked within the community.

[calcopiritus@lemmy.world]

Rust doesn't have "safe" and "unsafe" modes in the sense your comment alludes to.

You can just do the little unsafe thing in a function that guarantees its safety, and then the rest of the code is safe.

For example, using C functions from rust is unsafe, but most of the time a simple wrapper can be made safe.

Example C function:

int arraysum(const int *array, int length) {
    int sum = 0;
    while (length > 0) {
        sum += *array;
        array++;
        length--;
   }
}

In rust, you can call that function safely by just wrapping it with a function that makes sure that length is always the size of array. Such as:

fn rust_arraysum(array: Vec<i32>) -> i32 {
    unsafe{ arraysum(array.as_ptr(), array.len() as i32)}
}

Even though unsafe is used, it is perfectly safe to do so. And now we can call rust_arraysum without entering "unsafe mode"

You could do similar wrappers if you want to write your embedded code. Where only a fraction of the code is potentially unsafe.

And even in unsafe blocks, you don't disable all of the rust checks.

[croquette@sh.itjust.works]

I come from embedded C, so what you describe doesn't feel alien to me (minus the security vulnerabilities haha)

I much prefer working with Rust restrictions than a higher level language without hard types because I am used to it.

[croquette@sh.itjust.works]

I am glad for your comment because I work with mcus and embedded solutions in C, so Rust, in that case, wouldn't be neccesarily safer than C.

I will have to look into it. I need to do 30h of training every two years, so I will learn Rust regardless, but I was thinking about eventually switching to Rust for embedded projects. Might just keep Rust as my scripting language because it is easier for me than Python

[croquette@sh.itjust.works]

I know Rust superficially. I use it to create simple tests for my embedded projects, so mostly just serial terminal with keyboard inputs.

It works a lot better for me than python because Rust is a lot closer to C than python.

So I cannot comment on Rust shortcomings. I was interested in knowing for what kind of projects Rust wasn't good.

[lessthanluigi@lemmy.sdf.org]

The 1% of ultra-rich linux users that we need to take their money from in order to fix the economy

[canadaplus@lemmy.sdf.org]

Yes, but with 0 blocks already, it only needs 62 more for total domination!