Rust

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.

I like how this takes familiarity with the original xkcd comic as a given.

I think half of Lemmy knows most of XKCD
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?

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

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.
- We always hear how great Rust is, but I’d be curious to know where it isn’t.
  In any project that's sufficiently advanced and written in any other language. You don't simply do a rewrite of 100k+ LOC just because you want to use Rust.
  Somewhere where you'd rather use a scripting language like Python. I.e., rapid prototyping or gluing together some infra components.
  A situation where your team's expertise is in some other language.
  A situation where a library/framework is native/only available for a certain language.
  Few of these are strictly technical requirements. It's obvious that you can use almost any language to do almost anything, including Rust, if that's what you prefer. However, the context matters in the real world.
  All this being said, I wish I had a chance to write Rust professionally. It's a neat language.
- 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 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.
- 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.

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"

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
- The 1% of ultra-rich linux users that we need to take their money from in order to fix the economy

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.

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'

Still waiting on that rust-based Nvidia driver. I assume it will take a few years tho.

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

Haskell is somewhere far away off screen

And Eiffel is in a different plane of existence entirely

Considering that FFI is very much a thing, I'm finding it difficulty to understand the point it's trying to make.

not a big fan of rust personally. I think it would be much smarter to bring borrow checking to C through annotations. That way we would not have to rewrite the whole world

While I agree that would solve much of the motivation behind rewriting in rust, I don't think it would bring many of the rust-enthusiasts over to C. For me at least, the killer feature of rust is having a modern tooling and language with proper library management, functional stuff in the language and one language standard everyone agrees upon.
- I don't think it's about bringing rust enthusiasts to C, it's about the fastest way to bring more safety to the entire ecosystem.
  I'm not convinced it's possible with just annotations, mind.
- Yeah, I don't think there's anything wrong with coding in rust for people who like it. But I do think it's quite a bit of useless work that could be spent more wisely on new products instead of rewriting things that we already have
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.?
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.
- 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.
- 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.
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.
C++ already has much more of the required language constructs, which is why there is already an attempt to add borrow checking to C++ called circle. Until that standardizes, I wouldn't expect it in C.

That works great 👍

Wait, but I don't see how it's relevant in the smallest of ways... OOOOOH! (/s, bc obviously we all knew that already:-P)

Where is Visual Basic in this diagram? Does nobody enhance blurry license plate pics any more?

points at blurry image of vehicle in background
enhance!

Be careful, a Rust Dev will accuse you of FUDposting! They might even try to collect evidence on you for being "a terrible person", then sending their followers after you, then individually contact all your publicly known friends about it!

Okay, Christoph Hellwig.
- Sorry, but Rust is still just as much a "not a functional programming language" as Java is "not an object oriented programming language"...

😡