The irony of this meme being posted from a platform written in rust is pretty great ngl
A platform that is doing a great job so far but which (unfortunately) isn’t as relevant yet to call it a pillar of modern infrastructure. ;)
It certainly is a pillar of my mental stability.
Ah, me a pillar of my insanity.
💜 happy to know we’re making it better.
Piefed is not written in Rust.
not yet
evil maniac laughter
I am still mentally in lemmy lol. Switch to piefed was pretty recent.
deleted by creator
Yes, but with 0 blocks already, it only needs 62 more for total domination!
Rust is actually awesome in many ways. No always the right solution, but nice to have in your toolbox.
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.
deleted by creator
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.
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.
Do you think Zig can be a complement to Rust in cases where the language cannot solve problems?
@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 purposeIf 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.
@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
Ahem…
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.
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.
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.
Rust […] could use a higher level scripting language, or integrate an existing one, I guess.
One approach is to use more macros. These are still rooted in the core Rust language, so they give up none of the compile-time checks required for stability. The tradeoff is more complex debugging, as it’s tough to implement a macro without side effects and enough compile-time feedback that you’d expect from a DSL.
Another is to, as you suggest, embed something. For example, Rust has Lua bindings. One could also turn things inside out and refactor the rust program (or large portions of it) as a Python module.
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.
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.
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.
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
lengthis always the size ofarray. Such as:fn rust_arraysum(array: Vec<i32>) -> i32 { unsafe{ arraysum(array.as_ptr(), array.len() as i32)} }Even though
unsafeis used, it is perfectly safe to do so. And now we can callrust_arraysumwithout 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.
Thanks for this. I was paraphrasing (badly, it seems). The video actually says it better:
To write code that lives in an embedded environment, it has to run in this mode in Rust called “no standard” (
#![no_std]) and this mode called “no main” (#![no_main]). Basically you have no access to any of the core utilities in Rust, you have to write a lot of them yourself.He then explains how embedded code necessarily has global mutability which is “the antithesis” of Rust development.
So yeah, you could make all of those wrappers, but at the end of the day you’ll end up with about the same amount of “unsafe” code as you would making the same thing in C++.
Edit: but if what you said still applies, it does seem like Rust would watch your back somewhat better than C++ would in that it wouldn’t even compile unsafe operations outside of
unsafeblocks, unlike C++ to the best of my knowledge where you kind of have to review the code yourself to make sure it only uses the appropriate wrappers.
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
It’s an interesting discussion. As someone who doesn’t actually deal with this and who literally never used Rust, I feel out of me depth. But it does sound like Rust has much better mechanisms to catch a programmer’s mistake. See my reply to the other guy.
I get the meme (though why was this single unstable point - imagemagick in the original xkcd - removed? To make the left side seem more stable clmpared to the original idea?), it might be trueish atm. But with rust I feel that a lot of projects that are rewritten in rust are quicker arriving at a “finished” (or almost finished) state where they are more or less just tools being used without much discussion anymore. I guess a lot of commonly used tools already use Rust in some way, but i rarely is an issue which makes this discussion-worthy or generates enough conflict in order to raise awareness outside.
I have a hunch that open-source rust-devopment is less of a hassle as a lot of discussion about code or the quality therof is simply avoided by a stricter compiler. If the code committed compiles with rustc there’s less possibility of it breaking other things in the codebase or containing hidden dangers that need to be discussed. Overall less friction, less overhead and distruction from the actual coding.
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”
I get the joke, but rust is actually pretty heavily used in the backend of services theae days. Cloudflare, Amazon, Dropbox, just to randomly name a few off the top my head. Have pretty heavily invested it into their back ends for more reliable service.
Over the last one or two years I feel like Rust haters have gotten even louder than the Rust evangelists. For every person who declares “Rewrite it in Rust!” I see two or three people saying how they hate Rust or how pointless it is and so on.
I am convinced Rust haters are simply refusing to learn something new, consciously or not.
I don’t like rust because I’m too stupid to understand it
Yeah, this whole meme just looks like ‘I hate Rust and don’t want it anywhere’
Of course, there is importance in trying it everywhere, because it shows where the language and ecosystem lacks and can evolve; but beside that, I think adoption by big companies wouldn’t happen if it wasn’t any good as some want to believe
The Lemmy backend is also written in rust
Here, FTFY:
Better meme
I like how this takes familiarity with the original xkcd comic as a given.
Knowledge of the sacred texts is required for enlightenment.
If not, you’re one of the lucky 10000.
The comic is now a mainstream meme, isn’t it?
Rust is fearlessly upholding the whole thing even without touching it. Incredible!
Gotta keep a distance to that dirty unsafe code!
That works great 👍
Hey now, about 1% of the Linux kernel is Rust now!
NT kernel also includes Rust.
Oh really? I had no idea Microsoft was doing rust at all
Which 1%?
The 1% that allows Linux to run on the New macbooks if i understand asahi Linux correctly
So drivers, I assume.
Oh yeah, the current rust work is about giving drivers access to the core abstractions of the kernel
The 1% of ultra-rich linux users that we need to take their money from in order to fix the economy
I assume you mean borrow their money? If you just take their money the compiler will complain.
Sure, “”“borrow”“” their money
I was making a rust joke.
Still waiting on that rust-based Nvidia driver. I assume it will take a few years tho.
Give it time. Once Fortran was king.
Yeah, in particular, you can write libraries in Rust, which can be used in virtually any other programming language, similar to how you can do in C and C++. And given that not a ton of young kids learn C/C++, there’s a chance that the majority of important cross-language libraries (like OpenSSL, SQLite etc.) are written in Rust in a decade or two.
You’re still using BLAS if you really need high-performing matrix calculations tho’
Considering that FFI is very much a thing, I’m finding it difficulty to understand the point it’s trying to make.
I’m working with some Rust right now that is 100% a big mess…
It’s consistently either the Rust or the Docker components that fail to build. In fairness, it’s a VERY big and complex application.
We had to use Nix to build Rust services and make containers of them. It works pretty well, except with Nix 2.29 and 2.30 where it is broken for some reason
If your setup doesn’t make it easier for you, choose a different setup.
docker doesn’t really fail to build unless something upstream fails, like lib builds that don’t have the proper dependencies installed. I’d still count those failures as rust fails 😂
that said, I worked with a kid that was trolling rust package managers hard by squatting on common library names because they refused to resolve the issues of squatting. dick move but clearly educated me on the toxicity of the rust community and why I should avoid it.
In my experience, the Rust community is pretty welcoming. Like, it’s actually a meme that trans women code in Rust for that reason.
just because they are accepting of people based on gender identity doesn’t mean toxicity cannot exist.
terfs are a great example of that.
Sure, but I’m saying in general. I don’t know why you’re so convinced of your position from the one experience you had.
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;
- this is normal enough that the community doesn’t feel the need to address the toxic behavior
- 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.
I guess, that’s an opinion to have then. I interpreted your point about toxicity to mean something different.
I will say that it certainly isn’t the case that no one in the community cares about namesquatting. You can likely find lively discussions around that right now.
But I have to admit that I don’t concern myself with it too much.
The thing for me is that one of the solutions that people suggest (for some of the problems that namesquatting has) is namespacing. And Rust kind of already has that, because it’s already pretty customary to create basically meta-packages with feature-flags to pull in other packages transitively, meaning your users will only need to get one package name right.Well, and the other thing is that the official package registry isn’t nearly as important in Rust as it is in many other languages, because you can also specify dependencies by providing the URL to the Git repository, with no registry involved. It’s mostly just for visibility that you’d stick something onto the official registry.
Haskell is somewhere far away off screen
And Eiffel is in a different plane of existence entirely
Where is Visual Basic in this diagram? Does nobody enhance blurry license plate pics any more?
