Rust

[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!

[mcasq_qsacj_234@lemmy.zip]

Do you think Zig can be a complement to Rust in cases where the language cannot solve problems?

[brucethemoose@lemmy.world]

I great example I saw is a dev who was building on a Rust game (with the Bevy engine), and switched to Unity.

https://deadmoney.gg/news/articles/migrating-away-from-rust

Collaboration - I started this project with my brother. While he's sharp and eager, he's new to coding. Onboarding him directly into game dev while simultaneously navigating Rust's unique aspects proved challenging. We found ourselves with a steeper learning curve that slowed his ability to contribute effectively to gameplay logic.

Abstraction - While my initial motivation was the enjoyment of Rust, the project's bottleneck increasingly became the rapid iteration of higher-level gameplay mechanics. As the codebase grew, we found that translating gameplay ideas into code was less direct than we hoped. Rust's (powerful) low-level focus didn't always lend itself to a flexible high-level scripting style needed for rapid prototyping within our specific gameplay architecture. I found that my motivation to build and ship fun gameplay was stronger than my desire to build with Rust.

Migration - Bevy is young and changes quickly. Each update brought with it incredible features, but also a substantial amount of API thrash. As the project grew in size, the burden of update migration also grew. Minor regressions were common in core Bevy systems (such as sprite rendering), and these led to moments of significant friction and unexpected debugging effort. This came to a head on one specific day where I was frustrated with a sprite rendering issue that had emerged in a new release. Blake had run into the same problem at the same time and our shared frustration boiled over into a kind of table flip moment. He turned to me and said something along the lines of "this shouldn't happen, this kind of thing should just be solved" and that triggered the conversation that led to a re-evaluation. The point isn't that specific sprite problem, but that because all systems in Bevy are open to tinkering and improvement, all systems were potentially subject to regressions.

Learning - Over the past year my workflow has changed immensely, and I regularly use AI to learn new technologies, discuss methods and techniques, review code, etc. The maturity and vast amount of stable historical data for C# and the Unity API mean that tools like Gemini consistently provide highly relevant guidance. While Bevy and Rust evolve rapidly - which is exciting and motivating - the pace means AI knowledge lags behind, reducing the efficiency gains I have come to expect from AI assisted development. This could change with the introduction of more modern tool-enabled models, but I found it to be a distraction and an unexpected additional cost.

Modding - Modding means a lot to me. I got my start in the industry as a modder and I want my game to be highly moddable. Over time, as I learned more about how to realize this goal, I came to understand many inherent limitations in Rust and Bevy that would make the task more difficult. Lack of a clear solution to scripting and an unstable ABI (application binary interface) raised concerns. I am not an expert in this area, perhaps these are all easily surmounted. I can only say that I did not find a path (after much searching) that I felt confident trusting.

It sounds like Rust (game engines, and more) could use a higher level scripting language, or integrate an existing one, I guess.

[croquette@sh.itjust.works]

I interface with low level communication protocols, mostly uart, so it fits my use case. But it is nice to see the hurdles people encounters. It tells a lot about the language.

[brucethemoose@lemmy.world]

Yeah. I wasn't trying to imply it's a bad language at all; it just fits certain use cases. They are complex, like people.

Still, it seems like it'd be cool for engine work, with C# or maybe a subset of typed Python as a scripting language.

[goatinspace@feddit.org]

That works great

[oinks@lemmy.blahaj.zone]

No C program is written to satisfy a borrow checker and most wouldn't compile with one, so adding it
would require rewriting the world anyways. At that point why not choose a language that, in addition to being memory safe, also drastically cuts down on other kinds of UB, has sum types, sane error handling, a (mostly) thread safe standard library, etc.?

[tja@programming.dev]

I assume you mean borrow their money? If you just take their money the compiler will complain.

[lessthanluigi@lemmy.sdf.org]

Sure, """borrow""" their money