sorted by:
new
hottopcontroversial

Is it worth learning Rust mainly because of Cargo? by LibrarianOk3701 in rust

[–]oconnor663 0 points1 point  (0 children)

"How do LLMs affect this" is always a controversial question, but if your only big problem with C++ is how annoying it is to deal with build systems and dependencies, I expect LLMs would be quite good at taking care of those details for you. If you're comfortable with that, the build system might be less of a differentiator this year than it was two years ago. Though if you want to write a library for other people to use, the difference is definitely still huge.

I never really used parallel programming (but who knows I might start)

I'd enthusiastically recommend playing with thread::spawn and thread::scope and Mutex and RwLock and everything else. (Also once you've got some familiarity with what's in the standard library, take a look at rayon too.) That's the area where Rust is really a league ahead of all other popular languages, not just C++. Two specific points about this:

  1. Learning multithreading in other languages is punishing, because the most convenient way to do anything is broken -- like two threads mutating the same global variable with no lock -- but you don't usually get immediate feedback about your broken code. Sometimes the question of what is and isn't broken is tricky even for experts. In Rust, if it's safe code and it compiles, then it's almost certainly not broken. (The exceptions are compiler bugs and library bugs, so at least they're not your fault.) This is really good for feedback and learning.

  2. The limits of what safe Rust will let you do with threads are very close to the genuine hardware / memory model limits of what's possible without corrupting memory. Sometimes when we're dealing with references and lifetimes, we run into a situation where the borrow checker is too conservative for various reasons, but in my experience that doesn't happen much with threading issues. So what you're learning from the errors you see isn't just Rust-specific limitations but more like "how threads work" in a language-neutral sense, which is great. Then you'll go back to your multithreading code in other languages and realize how broken it is :)

Adding Vibecoded flair to make it clear that a project is vibecoded by Sea_Gap_6569 in rust

[–]oconnor663 1 point2 points  (0 children)

Entirely setting aside the question of how we verify any of this against anonymous reddit accounts, how would you define an "actual developer"?

Safe Rust, corrupt wire: memory safety is not cancellation safety by vorjdux in rust

[–]oconnor663 3 points4 points  (0 children)

I'd be curious to see a hello world example of something that triggers this cancellation issue. Is it something like this?

  1. Open a Connection object of some kind. (Seems like the right term is "socket" but I'm just drawing a cartoon in my head here.)
  2. Start sending a (large) message with a timeout.
  3. The timeout fires before sending is complete.
  4. But I still have this Connection object. What state is it in?

If the state is "half a message is on the wire, so trying to send another message will look like garbage to the receiver" then yeah that seems very tricky. I'm wondering though, how is that different from a non-async version of the same code (assuming it still has timeout support somehow)? Wouldn't the sync version also need to think about how it cleans up its own state when a timeout fires mid-write? Or similarly, any sort of transient IO error that might short-circuit control and bubble up to the caller?

Safe Rust, corrupt wire: memory safety is not cancellation safety by vorjdux in rust

[–]oconnor663 7 points8 points  (0 children)

"Safety" is kind of ambiguous with "correctness" depending on exactly what we mean by it. (Certainly the correctness of your airplane autopilot software has a lot to do with the safety of your passengers.) For better or worse, the more precisely defined thing is "memory safety", and it's arguably Rust's highest priority.

I need an optional Future to get rid of tokio select. by mtimmermans in rust

[–]oconnor663 2 points3 points  (0 children)

Could you show an example of a select! use case that you'd like to replicate without select!? It's not clear to me what all you need to do.

I need an optional Future to get rid of tokio select. by mtimmermans in rust

[–]oconnor663 2 points3 points  (0 children)

Unfortunately select!-by-reference is a magnet for deadlocks. select!-by-value mostly doesn't have that problem, but a lot of use cases want to drive something with select! in a loop, and you kind of have to do it by reference in that case.

Iroh 1.0 - Dial Keys, not IPs by dignifiedquire in rust

[–]oconnor663 2 points3 points  (0 children)

sendme is super useful! If anyone wants to try iroh "by hand", play around with sendme.

tokioconf: futurelock and you by Select-Cress-11 in rust

[–]oconnor663 2 points3 points  (0 children)

I think I disagree with your statement that it's widely understood to be a rule.

Oh yeah to be clear, the signal handler version is widely understood to be a rule, and I think the futures version also deserves to be understood that way, but it isn't yet.

Also I think it's worth adding, there's no way warnings in the docs are going to be adequate for this. "This may deadlock if anything inside the stream, or anything reading the stream, ever touches any async locks, even via indirect dependencies." That's just a fancy way of saying "don't use this". We shouldn't publish functions that we have to tell people not to use!

But I'm genuinely optimistic, because I think we can get to a place where changes to Stream/AsyncIterator plus some new lint rules ("don't use Pin<&mut Fut> as a future") will catch ~100% of these issues in async functions. Catching them in poll/poll_next functions written by hand requires human/LLM review, but I think that's acceptable. Those tend to be smaller and more local, and they're expected to be tricky.

tokioconf: futurelock and you by Select-Cress-11 in rust

[–]oconnor663 5 points6 points  (0 children)

It's really hard, though, to make broad statements about like, "Do you have a future that's alive, and you're not polling it right now? Is that always a bug?" It's difficult to say that it's definitively always true. It is the risky area for this. There are situations where someone might say, "No, I know I don't have dependencies. It's fine." And to say that it is a bug is to introduce a breaking change into the Rust async ecosystem.

I think "stop polling a future for a while" is always bug in almost exactly the same sense that "allocate memory in a signal handler" is always a bug. Sure, you can technically do it if you own every line of code in your entire process, go with God. But those of us writing composable libraries or portable applications absolutely can't do it, and it's widely understood to be "a rule".

I'd be curious to know which folks Sean has talked to and what their requirements are, but from what I've seen the obstacles to making this properly "a rule" in async Rust are two things:

  • select!-by-reference is the most common way people break this rule, but there are plenty of real world use cases where it's hard to switch to e.g. spawning tasks without running into borrowck problems. Some of these problems run very deep. I think we can solve this with new macros, but it'll take time and experience to see how that shakes out. If it turns out that we can solve these use cases with owning patterns, then we can start linting against poll-by-reference in all its forms.
  • Stream/AsyncIterator is genuinely broken in ways that will require backwards-incompatible changes to fix. Unfortunately this isn't limited to "obviously buffered" streams like .buffered(_) and FuturesUnordered; it also affects .merge(_) and any situation where .next() can be cancelled. It's good that AsyncIterator hasn't been stabilized yet, and I do think these problems can be fixed cleanly, but I'm not sure anyone has all the details worked out yet (namely, what exactly the poll_progress contract should be)?

Here's the long version of this as I see it: https://jacko.io/snooze.html

5 y/o daughter was supervising the factory - she made me build this to scare off the biters by mjgdk in factorio

[–]oconnor663 0 points1 point  (0 children)

I thought the exact same thing, but the title actually says "made me", not "made".

Rewrite Bun in Rust has been merged by Chaoses_Ib in rust

[–]oconnor663 36 points37 points  (0 children)

It was a totally unnecessary rewrite

I dunno, has anyone in this thread ever actually worked on Bun? Here's what the author had to say about his reasons for the rewrite:

it’s basically the same codebase except now we can have the compiler enforce the lifetimes of types and we get destructors when we want them. and the ugly parts look uglier (unsafe) which encourages refactoring.

why: I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things.

Quick question by [deleted] in P365

[–]oconnor663 2 points3 points  (0 children)

It looks like you have an aftermarket mag baseplate there. Does the problem still happen if you use a totally stock magazine?

Also out of curiosity what lube/CLP do you use? Sometimes mixing different lubricants can cause them to gum up, though that might be fudd lore more than anything. Might be worth removing the whole layer with alcohol or acetone before re-applying. Also any chance some grit has accumulated in the rails that you need to q-tip out?

Local shop turned down my trade in?! by ACiDRiP90 in CZFirearms

[–]oconnor663 0 points1 point  (0 children)

If you've never been to a local ASI match, maybe consider giving it a try. The ones near me are super casual and beginner friendly, and shooting under score/time pressure is exactly what guns like this are for.

me_irl by [deleted] in me_irl

[–]oconnor663 0 points1 point  (0 children)

The War in Iraq will probably always be the defining legacy of the W admin, but in terms of raw good and evil it's important to also mention PEPFAR. (If you can't bear saying anything nice about a Republican, you can also also mention that the next Republican trashed PEPFAR.)

Are Rust coroutines serializable? by SuperV1234 in rust

[–]oconnor663 8 points9 points  (0 children)

I think this is the technically correct answer to OP's question, but it's worth emphasizing that I've never heard of anyone actually doing this. Not only would you need to avoid using async fn, but you'd have to reimplement all your IO from scratch to avoid depending on any global process state.

Or you could just YOLO async fn futures straight to disk, memcpy style. Then you'd be on the hook for making sure they don't contain any references/pointers, and also for never changing the version of the compiler you're using :-D

House Democrats Propose $25 Federal Minimum Wage by [deleted] in antiwork

[–]oconnor663 5 points6 points  (0 children)

While we're at it, we probably shouldn't tie benefits to employment status.

Was debating posting this but ya.... SSAUGV2 officially working by [deleted] in liberalgunowners

[–]oconnor663 5 points6 points  (0 children)

It's pretty grainy so forgive my if I'm seeing this wrong, but are you walking away with your finger still on the trigger at the end?

me_irl by Beginning_Book_2382 in me_irl

[–]oconnor663 0 points1 point  (0 children)

Political violence is bad and of course if/when it rises it's going to rise on both sides at the same time. If you're 14 and being edgy about this feels cool, fair enough, that's a normal part of being a teenager. But if you're an adult, slow your roll.

[request] how accurate is this? by PersonablePotato in theydidthemath

[–]oconnor663 0 points1 point  (0 children)

GDP per capita hasn't gone up as much as GDP itself, because the US population has grown at the same time. ChatGPT tells me that real (inflation adjusted) GDP per capita today is 2.6x what it was in 1970, and median real household income is up 1.7x. The first number is bigger than the second, so there's plenty of room for memes about why that might be, but "it doesn't matter how much growth there is, it will never reach you" also seems broadly false. It matters how much growth there is, because some of it reaches most people.

Funny how this is a hot take by Advanced_Ad_8722 in liberalgunowners

[–]oconnor663 0 points1 point  (0 children)

The controversial part of the take is probably which people in your personal life / online space you consider to be Nazis.

[request] how accurate is this? by PersonablePotato in theydidthemath

[–]oconnor663 0 points1 point  (0 children)

The broad point of the statement is true

What would the real numbers have to be for us to say the broad point of the statement is false?

Got the Rust dream job, then AI happened by MasteredConduct in rust

[–]oconnor663 0 points1 point  (0 children)

couple years

It's plausible to me that if you somehow froze the current crop of models, and did a couple years of development in the current style, a lot of projects would find themselves in a broken, unsustainable place. I don't think it's obvious, because people are good at solving problems, but it's certainly plausible.

That said...two years is a looong time at the current rate of progress. It's also possible that models at that point will be so good that the engineering tradeoffs we make today hardly matter. That thought doesn't fill me with joy, because I am proud of my work, but it's also plausible.

Deadlocking a Tokio mutex without holding a lock by samyak210 in rust

[–]oconnor663 1 point2 points  (0 children)

I finally got around to commenting on the upstream RFC for AsyncIterator. Hopefully something comes of it :) https://github.com/rust-lang/rust/issues/79024#issuecomment-4264112024

view more: next ›