[flagged]
tbh I'm not getting GPT-voice from this
It's there in places ("The honest answer is...") but I think most of this is human written. They probably started with an AI draft I'd guess.
Surelock: Deadlock-Free Mutexes for Rust
31–40 of 90 posts
Re: Surelock: Deadlock-Free Mutexes for Rust
#32[flagged]
So tired of this sort of comment. LLMs are trained using (primarily, generally) online material. It sounds like online humans, in aggregate, plus or minus a bit of policy on the part of the model builders.
> So tired of this sort of comment.
Email the mods about it rather than replying, subject “Accusation of AI in FP comment” or whatever. It’s a guidelines violation to make the accusation in a comment rather than to them by email, and they have tools to deal with it!
Re: Surelock: Deadlock-Free Mutexes for Rust
#33[flagged]
[deleted]
Re: Surelock: Deadlock-Free Mutexes for Rust
#34[flagged]
So tired of this sort of comment. LLMs are trained using (primarily, generally) online material. It sounds like online humans, in aggregate, plus or minus a bit of policy on the part of the model builders.
Except nobody writes like the aggregate, hence why it's so jarring.
The closest actually human style to LLM writing is obnoxious marketing speak. So that also sucks.
So many people who are not great writers lean on LLMs to write, but aren't good enough to see how bad it is. They should be criticised for this. Either use them and be good enough to make it read as human, or just don't use them. No free lunch.
Re: Surelock: Deadlock-Free Mutexes for Rust
#35Earlier quoted context omitted.
So tired of this sort of comment. LLMs are trained using (primarily, generally) online material. It sounds like online humans, in aggregate, plus or minus a bit of policy on the part of the model builders.
> So tired of this sort of comment. Email the mods about it rather than replying, subject “Accusation of AI in FP comment” or whatever. It’s a guidelines violation to make the accusation in a comment rather than to them by email, and they have tools to deal with it!
Nobody is making an accusation of an AI comment - people are pointing out that the article is at least partially AI generate, which does not go against any HN guidelines, and neither does complaining about those comments.
Re: Surelock: Deadlock-Free Mutexes for Rust
#36I agree with the author: it's a shame that TVars aren't catching on in more languages. They are a great idea from the database world, that we could use in the rest of computing, too.
Well, what means to support, truly, TVars?
Is easy, or hard?
Demand a new paradigm at large, or is only a inconvenience in the few places is used?
Because if the answer is "turns the language into Haskell" then is a big NOPE!
Re: Surelock: Deadlock-Free Mutexes for Rust
#37Hrm. I'm not immediately impressed by the "Level" construct. That feels like a lot of new cognitive burden. It's also not at all obvious to me that multiple levels of mutex is a common pattern? I'm not sure I've ever encountered a situation where locking Account also and always requires locking Config? Heaven help you if you have 3 or more levels.
I dunno. I appreciate the opposition to "just be careful". But this feels to me like it's inducing bad design patterns. So it feels like it's wandering down the wrong path.
Re: Surelock: Deadlock-Free Mutexes for Rust
#38I'm intrigued! I was fighting deadlocks in some Java code this week, and I'm working on a Rust project to maybe replace some of that. One thing I didn't see in the post or the repo: does this work with async code? I couldn't find the "search" button on Codeberg, and tests/integration.rs didn't have any async. For embedded, I have had my eye on https://github.com/embassy-rs/embassy (which has an async runtime for embe…
IIUC, this crate has similar restrictions to the std Mutex. So it depends on what you mean by "work with async code." First, lock acquisition seems to be a blocking method. And I don't see a `try_lock` method, so the naive pattern of spinning on `try_lock` and yielding on failure won't work. It'll still work in an async function, you'll just block the executor if the lock is contested and be sad. Second, the key and…
Just wanted to add to your great summary a link to tokio’s docs on which kind of mutex to use, which seem applicable to the mutex in TFA as well: https://docs.rs/tokio/latest/tokio/sync/struct.Mutex.html#wh...
Also to note, regarding “future not send,” that, in tokio codebases where the general expectation is that futures will be Send, enabling the clippy lint “future_not_send” is extremely helpful in avoiding these kinds of issues and also in keeping the error localized to the offending function, rather than it being miles away somewhere it happens to be getting indirectly spawned or whatever: https://rust-lang.github.io/rust-clippy/stable/index.html?se...
Re: Surelock: Deadlock-Free Mutexes for Rust
#39[flagged]
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.