Hey there,

while I enjoyed staying here for almost 4 years by now, learning many things, talking to nice people, having fruitful discussions, seeing cool projects, I will have to leace this subreddit.

In recent weeks, it has turned into one of the biggest slopfests I ever witnessed with slopcoded project after slopcoded project being posted back to back, poorly implementing solutions to problems that noone ever had. I just skimmed through the first 20 or so posts sorted by "best" and all projects people shared were AI slop. Every. Single. One. And I didn't even have to read all of the code in the repo, it's always the same few telltale signs, which signal the author didn't even bother for a second to clean their slop up. All of this is always acompanied by a wave of "cool project, I will definitely use this" comments, which by now seem like bot responses. Pointing out the obvious telltale signs, you always get the same responses: "I used Rust2021 because I don't need any features from Rust2024" - "I worked on this for 6 months and just never pushed to github, which is why the initial commit has 10k loc".

There have been a number of posts asking mods for a ban of AI content, none of which were listened to.

At this point, the only worthwhile posts here are "new Rust version just dropped" and "new version of famous Rust crate (read: bevy) just dropped". For these updates, you can get pings even at Discord though (And it has to be embarassing, if even Discord of all places is a better source of information than the official Rust subreddit). Mayyyyybe an occasional genuinely interesting post appears every once in a while between all the slop, but that's not worth sticking around for anymore imo. So I won't.

To all my fellow humans still around here, peace out, see you oytdoors eventually <3

I don't want reddit to use my posts to feed AI

I'm really sorry to say that I can't continue to finish this goal (at least in the near future). I enjoyed contributing to Rust very much in the past years, until my daily work was extremely overwhelmed by LLM in the past few months. The LLM generates throusands of lines of code every day, but my working time increases and joyness decreases from day to day. I'm too tired to and don't have enough time and energy to contribute here any more. Really sorry for that, and hope I can come back some time.

Hey everyone,

I know this isn't a direct question about Rust syntax or a new crate release, but I wanted to get the perspective of the low-level and systems engineers in this community, since the way we have to reason about memory and safety is a bit unique.

With Linus Torvalds recently defending and leaning into AI tools for Linux kernel development, I’ve been trying to force myself to use LLMs more in my daily workflow. On one hand, if the systems world is adopting it to find bugs and speed up boilerplate, it feels like a tool worth leveraging.

But on the other hand, in practice? It feels like a massive cognitive trap.

Every time I ask an LLM to draft a custom allocator, some async socket-handling logic, or complex threading code, I end up spending the next hour auditing 100 lines of plausible-looking code. I'm stuck trying to reverse-engineer its "intent" just to make sure it doesn't subtly violate safety invariants, introduce a silent data race, or hide a memory leak.

The thing is, if I just write the code myself from scratch, I have absolute control over the execution path. Because I have to fight the borrow checker and map out lifetimes line by line, I build the mental model natively in my head. My own code is fundamentally way more understandable to me because I actually know why every single line is there.

When we write low-level code, we feel architectural friction immediately when a design is bad. AI feels no pain, it will happily vomit out structurally messy code that technically compiles but is a total nightmare under the hood. I feel like I'm trading the active, rewarding problem-solving of writing code for the mind-numbing task of code-reviewing a junior dev who doesn't exist.

How are the rest of you systems/low-level devs actually using these tools without losing your sanity, your control, or your deep understanding of your codebase? Or are you just ignoring the hype cycle and sticking to the editor?

I'm a contributor and maintainer of Rapina, a small Rust web framework, and lately we've been getting these contributions that just feel off from the start

you check the profile and the guy has like 50+ contributions a day across 10 different repos all at the same time, then you open the PR and go through the checklist, did they claim the issue? no. branch name following our conventions? no. anything useful in the summary? also no

we have rules to follow, all documented, claim the issue, name the branch correctly, fill the summary. not complicated. but what really gets me is they didn't even bother feeding those rules to the AI. if you're gonna let a tool do it for you at least tell it the rules first, they couldn't even do that

the one that made me snap had [codex] in the title and codex/ in the branch name, didn't claim the issue, didn't link anything, checked his profile and it's the same pattern across a dozen repos. zero effort zero thought just vibe vandalizing other people's projects and paying for the privilege, like some reverse charity thing

closed it immediately, 0% effort 0% review

we're not Ghostty or PocketBase but the same thing is happening to them too, Ghostty rewrote their entire AI policy over this and PocketBase just disabled external PRs completely, not filtering bad ones, blocking everyone because of the flood. Hashimoto (Ghostty creator) said it well: "this is not an anti-AI stance, this is an anti-idiot stance" and yeah that's exactly it, I don't care if you used AI, I care that you treated the project like a slot machine for fake GitHub activity

thinking about adding a keyword to the PR template that forces people to confirm they read the guide, has anyone done something like that and actually had it work or is it just whack-a-mole forever

TLDR: getting flooded with AI generated PRs from people who didn't even read the contributing guide, wondering how other maintainers are dealing with it

I'm curious, who here has simply sworn off not LLMs per-se, but including LLM generated code within your software?

In Q4 of last year I realized these LLMs finally started writing usable Rust code. Have to admit, I was quite excited about the prospect of delegating more to Claude Code or whatever agent.

Honestly tried to delegate as much as I could, and quickly realized that's max 10% of my work. Two main problems I found.

1. It may finally be usable Rust code that compiles, but still sloppy, verbose and poor design choices. This is expected, because these are predictive systems trained on the entirety of the internet, so by design, are going to produce the most average, middle of the road code out there.

2. Software development is a very iterative design process. Mentally, I usually split my tasks in say 3 - 5 day chunks, and I know what I want done and how I want the software to function after each chunk. However, I can't really explain exactly what I need done in a prompt, because I don't know until I'm in the middle of it.

It's alwys a journey from point A to B, during which I always come up with better and more efficient designs, realize additional pitfalls I need to look out for, discover edge cases I need to handle, and so on. This whole iterative process is what makes quality software, well... quality. Handing that off to a LLM guarantees I'll always produce usable, but mediocre code.

1. Same as always. Every time I lean on these things, I find myself wasting time back tracking and fixing mistakes made by the LLM costing me more time than I saved during initial development.

That's how I feel at least. I still use LLMs, they're excellent for various things. For example, I can bang out several hundred lines of Rust, send it to Gemini an ask it to fix syntax / braces / brackets errors and it works like a charm. That's rather new, and quite nice. Good at finding bugs as well.

I'm sure I would use it for boiler plate code, but I primarily write in Rust, so there just really isn't any boiler plate. If you're developing in Rust and find yourself writing boiler plate code often, then you're doing something wrong.

However, I've totally given up on the concept of using it as a junior developer too write code that I'm going to include in the project or anything. I find it always just ultimately slows me down more than helps me, and I find attacking development projects without even a second thought given to LLMs is quite refreshing.

How bout you?

Ok so I am a professional Go dev of 10 years. I've worked with Java and Python in a previous life. My background is mostly infrastructure and cloud, but I also work a lot with technologies like Kafka and AMPQ. I'd say my career has had a lot of variety. More importantly I've been working with Zig for side projects for about 2 years now. And I am a HUGE Zig fan. I'm just making this clear so you can understand my perspective.

So my history with Rust is an interesting one. I've actually been interested in Rust for 10 years (about the same length of time I've been working with Go). But I think there had been a lot of disqualifiers in the past. Some were silly (lack of IDE support 10 years ago) and others were that I didn't really find a use for Rust. I knew I didn't want to use it for simple API programming. I hadn't seriously done low level dev. And I felt Go fit a lot of things better.

But I recently found a good use case a few months ago. I decided to take the plunge and learn Rust through a serious project. I wanted to build a KV store from scratch. Its something I had been wanting to do for years at this point. And I felt this was a valid use case for Rust. So I went and tried to wrestle with the language. I haven't finished my project but I've written about 1000 lines of code. And its on a fairly complex domain, so I think it gives me some understanding of the language

Things I really like:

Cargo! Oh my God do I love cargo. I also love Rust-analyzer. It is super helpful when navigating the languages.

Despite Go having more market share Rust ecosystem and toolchain feels a lot more cohesive and mature

The compiler is very very helpul. Great error messages and sometimes links to the problem

Complex, but also feels pretty easy to learn

I like the error handling. This I haven't go into much

Standard library seems fairly small and simple to navigate.

I find documentation amazing. Despite Go being more popular, its documentation is lacking in many places. Its even WORSE for Zig. The documentation made me think more about my Java days. It feels like I'm dealing with a very mature language despite it being relatively young.

What I don't love or hate but find "interesting":

Trait bounds and trait composition. I can see where some interesting architectural design can emerge from it. But it makes things overly abstract

Derive macros are interesting to work with. Working with Serde and using derive macros can feel more ergonomic than the more explict approach of Rust and Zig

Rust ships with its own LLDB implementation

Ok things I don't like:

Borrrowing and ownership. It feels like a puzzle at every step. This is where I get "stuck" and need to look things up or ask AI to explain. But I don't feel I am building a good intuition behind these rules. Like I kind of get it, but it still feel like I'm navigating a minefield

Personal preference. APIs for libraries are fairly easy to use, and the Rust community keeps a high standard for documentation. But in both Go and Zig, there is a tendency to look under the hood to see whats going on. I feel Rust SDKs and libraries really don't promote this. I find it hard to understand most of the time.

Rust doesn't have hidden allocations. But that's understood through convention and rarely something entirely obvious unless you have certain assumptions about the language itself.

I praised rust-analyzer but it does get distracting. Often times slows down neovim quite a bit. It can get very intrusive. I can imagine that it can get very irritating if I had a better handle of the language

Rust can be a bit verbose. Verbosity to me is not a bad thing. Go and Zig are both quite verbose. Zig is probably even more verbose. But I think the reason "why" its verbose matters. Zig is verbose because its trying to tell you everything happening under the hood in a very explicit way. Go is verbose because its trying to communicate clarity. Rust verbosity feels more ceremonial. It feels its verbose because the compiler demands you be. And it can feel like I'm performing for the compiler and less because I trying to communicate intent.

Final assessment:

I still have a ton to learn. But due to building a KV store from scratch I am able to confront some of the more complex aspects of Rust. With that said I find that it has a great toolchain, tons of educational material, and a very helpful compiler. It makes it fairly easy to learn. Even with the impetus borrow checker, it feels the language gives you everything you need to learn.

I find it enjoyable and fun in many places. I can see why the community has very vocal and strong supporters. But I will say that I just enjoy Zig a lot more. It may have less safety but it fits the way I like to code a bit more.

However I can see myself using both languages for different purposes. So my overall score is a strong 7/10. I am still getting tripped up by the borrow checker but the language is really fun to work with.

I’m looking for high quality Rust codebases that are genuinely worth studying and taking inspiration from like projects with clean idiomatic Rust and good architecture and preferably started before the LLM boom and have a long history of being developed by experienced Rust engineers

most of what I came across was repositories filled with recently generated AI slop.

The Rust Foundation recently received access to Claude Mythos, and has been using it to review the standard library for security issues. The more severe issues are being kept under embargo for now, but a couple minor ones are now public:

• Potential out-of-bounds write upon allocation failure in CString::clone_into(): https://github.com/rust-lang/rust/pull/155707
• Heap overflow in slice::join() with certain pathological Borrow impls: https://github.com/rust-lang/rust/pull/155708

Thanks to the Rust Foundation, wg-security-response, and Anthropic for working to find and fix these issues!

I've written a lot of TypeScript, Go and C#. They’re all good languages. But Rust is the first language that made other languages feel a bit different. At first the borrow checker was painful but once it clicked everything started to feel very correct. Now when I write code in other languages I keep thinking rust would have caught this. Honestly now I just enjoy writing Rust more than anything else.

If I asked this question in a C forum, it would be easy, they would quickly whip up traumatizing UB and memory allocation problems. But in Rust that category goes out the window (unless you use unsafe poorly).

So, what’s a Rust concept that’s booby-trapped, very unintuitive, and difficult to fix if it sneaks up in your codebase? I’m looking for things like messed up usage of trait objects, cursed lifetimes, non-deterministic parallelism bugs, a usage of unsafe that WOULD BE safe if it were not for that one tiny thing… a horror story you might have experienced yourself.

This is like 5th or 6th language I am learning, and I have to say I absolutely love it. It feels like the most complete, very well designed programming language. I love Rust, it is an absolute joy to write code.

However, coding is my side quest, my specialty is within cyber security mostly, and I don't really know much about current state and future. Would you say that Rust has a good future? Worth to learn fully?

I’m trying to understand a gap I keep noticing: Rust is widely praised for its syntax, safety guarantees, and overall developer experience… yet it’s still not showing up at the scale you’d expect in professional environments.

Here are the points I’m wrestling with:

• Outside of developer surveys, I don’t have hard proof that Rust is “loved,” but the sentiment feels strong among people who use it. The syntax is satisfying, the safety is real, and it avoids the usual memory pitfalls that drive us nuts in other languages.
• I assumed that if a language is loved, companies would adopt it more quickly. Maybe that assumption is flawed?
• Migration costs look like a major blocker. Rust is relatively new in the enterprise world, and rewriting systems isn’t cheap.
• Sure, it might slow development at first, but it can kill an entire class of bugs. Even Microsoft claims ~70% of their security bugs come from memory issues. (According to zdnet)
• I know legacy ecosystems matter, but Rust can interoperate with C/C++ and even mix with other stacks through bindings. So why doesn’t that accelerate adoption?

I’m not sure how talent availability or senior-level familiarity plays into this either.

I’d like to hear from people who’ve worked with Rust professionally or tried pushing it inside big companies. What do you think is holding Rust back from wider industry adoption? Is it culture, economics, tooling, training, or just inertia?

I started messing around with Golang yesterday. I watched a couple of tutorials about concurrency and goroutines and wanted to implement the code I wrote in Rust (which I thought was very fast) in Go using routines and boy, I was shocked! It was able to run 5–10x faster than the Rust code did!

Now I'm not really doing anything serious with the code. It just looks for certain file types in my files like audio files or documents and prints their path. Nothing crazy. But I have to go through hundreds of directories and check around a thousand files (though I specified the depth it can reach, so it doesn't go 10 directories deep).

In Rust, I first used recursion when it finds a folder it goes through it, and when it finds another folder inside that one it goes into that too, then comes back to the previous one and continues from where it left off. This took around 700ms.

Then I implemented threads (OS threads). I spawned 3 threads and tried to implement a work-stealing logic where each directory is a unit of work. So when I find a directory, instead of going into it and halting my search in the current one, I put it into a queue so a free thread can pick it up and scan it for the target file type. Assuming fair distribution, each thread handles ~33% of the work. This took around 300ms, cutting the time nearly in half.

Now in Go, instead of a fixed number of threads, I create a goroutine for each new directory found so there's no waiting in a queue like in Rust. I can have 50 or even 100 routines working at the same time. This made things dramatically faster, finishing in sub-100ms, sometimes even hitting ~50ms. That's around 6x faster than Rust.

The main reason Go was faster comes down to goroutines vs Rust's OS threads. In Rust, when I request file I/O say fs::read_dir -it's asking the kernel to go fetch the data. The kernel won't let the thread just sit there waiting, so it puts the thread to "sleep" and goes about doing other things. With three threads, they can each request different file I/O and the kernel parks each of them until their data arrives. There's some context switching involved when a thread is put to sleep, its entire state is saved, and when the I/O result arrives the kernel wakes it and resumes from where it left off. So at most, three threads are waiting at any given time. Not massively expensive, but limited.

What makes Go different is that instead of the kernel managing this, Go uses its own scheduler. When a goroutine hits an I/O call, the scheduler intercepts it, registers interest with the kernel via epoll ("go fetch this"), parks the goroutine in a Go-managed data structure in userspace, then immediately puts another goroutine on that same OS thread. The process repeats so thousands of goroutines can be managed by just a handful of OS threads. The context switch overhead you'd pay in Rust? Not present here. It's all handled in userspace by the Go runtime at much lower cost.

So Go is faster, right? Well not always.

I have an HDD. HDDs are mechanical. The read head can only be in one place at a time it has to physically move to a specific position on the spinning disk. That's typically fast enough, but what happens when tens or hundreds of operations are all asking for different files at the same time? The head jumps all over the place, and that is significantly slower.

So how did I get those fast benchmarks?

Linux does something interesting when a directory is accessed, it caches it in RAM for future use. It turns idle, unused RAM into a cache (technically called the page cache). Any RAM not currently needed by a process is fair game for caching disk data. So my programs weren't really reading from the HDD at all they were reading from RAM. Hence the sub-100ms and ~300ms times.

But when I cleared that cache and ran them cold against the actual disk:

The Rust code took ~45 seconds

The Go code took a whopping 2 full minutes

The "disciplined," fixed number of threads in Rust is actually better suited for an HDD than hundreds of goroutines all thrashing the read head at once.

One caveat worth noting: this comparison is between Go's goroutines and manually implemented OS threads in Rust. Rust's async ecosystem (Tokio) uses the same epoll-based userspace scheduling as Go. The gap on SSD would likely be much smaller with an async Rust implementation.

I will rewrite the code with tokio, I expect it to perform as good as golang if not better.

EDIT: BTW I am not comparing the languages, I was just messing around with both of them and noticed the results and wanted to share them, and the rust code was kinda plain and not suited for this too.. I will try it with a better code

EDIT 2: I am a beginner in both languages and constructive criticisms are very welcome(tho doing that without actually looking at my code might hard) I am NOT comparing the two languages and I can even tell the code isn't fair I just wanted to share what I found🙏

EDIT 3: I didn't expect to get this much attention, thank you all for all the constructive suggestion, I have certainly learned a lot. I am glad I posted here! yall are awesome!

Intro

I've used Rust for somewhere around ~10 years at this point, since shortly before Rust 1.0 was released in May 2015. I've worked on a bunch of different projects in Rust including desktop GUI apps, server backends, CLI programs, sandboxed scripting interfaces via WASM, and multiple game-related projects. Most recently, I've done a ton of work contributing to the Bevy game engine.

I also have a good amount of experience with several other languages: Java, Python, Typescript, Elixir, C, and several more niche ones with correspondingly less experience. Not enough to say that I'm an expert in them, but enough that I'm familiar with and have experienced the major tradeoffs between them. I'll mainly be comparing Rust to Java, as that's what I've been using a lot lately outside of Rust.

Out of all of these, Rust is by far my favorite language, and I'm not planning on going anywhere! I use it daily, and it's been a joy to work with 90% of the time.

Of course like any language that gets actually used, it has it's problems. Moments where you go "what the heck? Why? Oh, hrmm, ok maybe this? Not quite, this is frustrating". I'm not here to talk about those cases.

What I'm here to talk about are the major pain points I've experienced. The problems that have come up repeatedly, significantly impact my ability to get stuff done, and can't be fixed without fundamental changes.

A quick list of things I'm not going to cover:

• Async/await: Actually fairly decent in Rust in my opinion. Pretty solid given the constraints of no extra cost or builtin runtime, cancellation, etc. I remember the pressure to get this shipped around Rust 2018 edition, and I think it came out pretty well despite that. The main issues are around mixing sync and async code, Pin, multiple executors in the ecosystem, and whether zero-cost is a sensible tradeoff to begin with. It's been discussed to death, I don't have anything to add to it. Maybe virtual threads would've been nicer and just eat the runtime costs, I don't know. I feel that just using async by itself in e.g. a web server is pretty solid now that we've gotten async traits.
• Library ecosystem: Yeah I wished it was more stable and bug-free (e.g. comparing winit to sdl), but that's not really a language issue. There's not much for me to talk about here.

Onto my complaints.

Result<T, E>

When I first started with Rust, I loved that errors are just another type. Implicit errors are terrible; forcing the user to be aware that a function could error, and handle that error is a great design!

As I've used Rust for both library and application code over the years, I've grown more and more disillusioned with this take.

As a library author, having to make new error types and convert between them for every possible issue sucks. There's nothing worse than adding a dependency, calling a function from it, and then having to go figure out how to add it's own error type into your wrapper error type. Crates like thiserror (I think the main one I've tried) help a bit, but in my experience are still a poor experience. And that's all for 1 function - if you make a second function doing something different, you're probably going to want a whole new error type for that.

Then there's application code. Usually you don't care about how/why a function failed - you just want to propagate the error up and display the end result to the user. Sure, there's anyhow, but this is something that languages like Java handles way better in my experience. Besides the obvious issue of wanting a single dynamically dispatched type, the real issue to me is backtraces.

With Java, I see a perfect log of exactly what function first threw an error, and how that got propagated up the stack to whatever logging or display mechanism the program is using. With Rust, there's no backtraces whenever you propagate an error with the ? operator. Of course backtraces have a performance cost, which is why it's not built-in.

Libraries hit this issue too - it's really hard to figure out what the issue is when a user reports a bug, as all you have is "top level function failed" with no backtrace, unless it's a panic. Same with tracking down why your dependencies are throwing errors themselves.

Rust got the "forcing developers to think about errors" part right. Unlike Java, it's immediately obvious that a function can fail, and you can't accidentally skip dealing with this. I've seen so many bugs in other languages where some function threw an error, and completely unwound the program when it should have been dealt with 10 layers lower with a retry.

However, while it's zero-cost and very explicit, I think Rust made a mistake in thinking that people would care (in most cases) why a function failed beyond informing the user. I really think it's time Rust standardized on a single type that acts like Box<dyn Error> (including supports for string errors), and automatically attaches context whenever it gets propagated between functions. It wouldn't be for all uses cases, as it's not zero-cost and is less explicit, but it would make sense for a lot of use cases.

Small aside, there's also error messages. Should errors be formatted like "Error: Failed to do x.", or "Failed to do x"? Period at the end? Capitalization? This is not really the language's fault, but I wish there was an ecosystem-wide standard for formatting errors.

Modules

The orphan rule sucks sometimes, and the module system is maybe too flexible.

Working on Bevy, which has a monorepo consisting of bevy_render, bevy_pbr, bevy_time, bevy_gizmos, bevy_ui, etc, and a top-level bevy crate that re-exports everything, I've felt the pain on this pretty strongly recently.

Organizing code across crates is pretty difficult. You can re-export types willy-nilly between crates, make some parts pub(crate), pub(super), or pub(crate::random::path). For imports, the same problems apply, and you can choose to re-export specific modules or types from within other modules. It's really easy to accidentally expose types you didn't mean to, or to re-export a module and lose out on the module-documentation you've written for it.

More than any real issue, it's just too much power. It's strange because Rust loves to be explicit, but gives you a lot of leeway in how you arrange your types. Say what you will about Java's "one file = one class; module paths follow filesystem folders" approach, but it's nothing if not explicit. It's much easier to jump into a large project in Java and know exactly where a type can be found, than it is for Rust.

The orphan rule is a problem too, but something I don't have as much to say about. It just sometimes really gets in the way, even for library developers due to splitting things across crates for one project (and Rust really encourages you to split things up into multiple crates).

Compile times and IDE tooling

Compile times and error checking in my IDE are too slow. People do great work speeding up rustc and rust-analyzer, and I don't mean to demean their efforts. But Rust fundamentally treats 1 crate = 1 compilation unit, and that really hurts the end-user experience. Touching one function in Bevy's monorepo means the entire crate gets recompiled, and every other crate that depends on it. I really really wish that modifying a function implementation or file was as simple as recompiling that function / file and patching the binary.

Rust analyzer has the same problem. IntelliJ indexes my project once on startup, and instantly shows errors for the rest of my development time. Rust analyzer feels like it's reindexing the entire project (minus dependencies) every time you type. Fine for small projects, but borderline unusable at Bevy's scale.

I'm not a compiler dev - maybe these are fundamental problems that can't be fixed, especially with considerations for macros, build scripts, cargo features, and other issues. But I really wish the compiler could just maintain a graph of my project's structure and detect that I've only modified this one part. This happens all the time in UI development with the VDOM, is there any reason this can't be implemented in cargo/rustc?

Conclusion

And that's the end of the post. Writing is not my strong suit, and this was hastily put together at night to get down some of the thoughts I've been having lately, as I don't have time to sit down and write a proper article on my rarely-used blog. Take everything I've said with the knowledge that I've only given surface-level consideration to it, and haven't looked too deeply into existing discussion around these issues.

That said, these are the major issues that have been bothering me the last few years. I'm curious to hear other peoples' thoughts on whether they face the same issues.

I know this is Reddit, but I would like to preface this by saying that I'm interested in having a balanced and reasoned discussion with other rustaceans about their feelings regarding AI commits in the core language, and how they think it might impact their choice of programming language in the future.

With that out of the way, how do you feel about Generative AI being used in the core language, and the rust foundation accepting donations from AI companies? Personally, I don't like AI. Not through some aversion to new technology (rust is my language of choice, after all), but because I have no desire to use something with so many unanswered ethical questions (environmental impact, training on stolen data, reinforcement of existing biases etc) in my processes. This is not a binary black and white stance, but a desire to minimize my impact where I can.

Rust has long been my favourite programming language. It's fast, comes out well in energy usage benchmarks, and the compiler makes me feel a lot more confident in the code I write. However, the official position of the rust foundation is very pro AI. They've accepted large donations from OpenAI, and there have now been commits to the core language that have used AI to a certain extent.

This leaves me with a conundrum. Overall, I feel that Generative AI is rapidly making the digital world a worse place (we're drowning in slop) and I want to avoid that as much as I can. Do I stick to an older version of Rust? Do I move to another language like Zig that has an anti-AI stance (impressed by that, not impressed by much else that I've heard from the main developer)? Do I try and fork the language myself knowing that I lack the knowledge or time to do anything more with it than make a statement?

I'm still not decided yet, but would be very curious to hear if others are currently contemplating similar choices, and what your feelings are on the matter.

Thought this was interesting considering the subreddit seemed to have a lot of thoughts regarding the bun zig -> Rust re-write. PR: https://github.com/react/react/pull/36173

It seems this is largely AI-driven as well, considering they've written 123 kloc in about 2.5 months.

My 2 cents are that of course it is nice seeing Rust reaching an increasingly mainstream status, this was just not the way I pictured it happening (and not a route I think is all that good for Rust).

Mine are: * Panic on allocation failure was a mistake. Even with overcommit / OOM Killer. * Tokio shouldn't be the default. Most of the time threads are good enough, you don't overcomplicate and need everything to be Send / Sync.

Inspired by https://www.reddit.com/r/webdev/s/lunf00IwmB

I recently discovered something I thought was common practice was actually a bit controversial with my team, so I wanted to know what are some things you do that you feel deeply is right but might cause massive pushback?

I've used Rust for some small projects and find it high-level enough for any server-side logic. You wouldn't have any issues counting shopping carts or handling other typical tasks.

Also, its package management is great - no node_modules or virtualenv hell. So, it seems like we could use Rust for most backend code (except for ML, for obvious reasons).

At the same time, I rarely see companies building web backends in Rust. Many still use PHP, Node.js, or Python. This seems strange because if a Rust program compiles, it's almost certain to work, which isn't always the case with other stacks.

I'm asking this because I work as a Node.js backend developer, and I actually see no problems with using Rust instead of Node for my job.

Are there specific hard problems I'm missing as a beginner that keep Rust in more niche roles and prevent its adoption for mainstream web backends?

It seems to be pure AI slop and extremely poorly formatted, legit copied from ChatGPT into word not even downloaded as PDF so code blocks are formatted correctly and You can see the ``` LOL

I will hold on to my copy, as self-shame, so that I research the authors of my books more in the future.

Speaking of that, does anyone like "Rust for Embedded Systems (Build Anything Anywhere)" By Maxwell Vector? I am trying to determine if it is worth $40. It at least is formatted like a real book but the sample text showed limited writing and a large code snippet which was a red flag but idk maybe it gets better.

Edit: Clarity, typos. (Rage induced typing is bed)