[flagged]
What are you referring to? Pointing out ways one's language is better is not necessarily arrogance. It's just communication.
My Rust experience after eight years
31–40 of 55 posts
Re: My Rust experience after eight years
#32For me lack of language specification is not a problem and it is good that Rust only have one implementation so I don't have a headache to support multiple compilers like C++. The only problems I have with trait is lack of const function and trait upcasting, which just solved by 1.86 that released yesterday. For iterator type mismatched it does not cause much problem since I can create a dedicated generic function to…
Could you create a type around Mutex that enforces the locking order?
You could - and this is what we do - push all of your state into one large struct. Note that this has drawbacks as well and if you have a lot of reads and some very important writes, you will still get deadlocks.
Re: My Rust experience after eight years
#33[deleted]
Re: My Rust experience after eight years
#34For me lack of language specification is not a problem and it is good that Rust only have one implementation so I don't have a headache to support multiple compilers like C++. The only problems I have with trait is lack of const function and trait upcasting, which just solved by 1.86 that released yesterday. For iterator type mismatched it does not cause much problem since I can create a dedicated generic function to…
Sharing resources is always a source of deadlocks and bugs, I don’t see a feasible resolution to that in a programming language. I don’t think one gets into deadlocks more often than any other language with Rust, but you are not experiencing most other concurrency bugs, which makes it feel like deadlocks are a bigger issue.
Wait, I've been told by "evangelists" that besides not having any security vulnerabilities, you also can't have deadlocks in Rust!
Re: My Rust experience after eight years
#35[flagged]
Curious if you have any examples since I didn’t read any zeal from the posted essay.
Re: My Rust experience after eight years
#36Earlier quoted context omitted.
I'm not familiar at all with the Ferrocene specification, but in general I do wonder if the ISO C/C++/Fortran (singling these out as I'm somewhat familiar with them, not saying there aren't other languages with similar spec processes) process of a prose spec is really the best way to go in this day and age? Those languages certainly have their historical reasons for the specs being the way they are, but I'm not convi…
You can not really write a formal spec without having prose first. It would be nice to have a formal spec for C, and C is one of the languages where this is feasible (and also partially done by various people).
> You can not really write a formal spec without having prose first.
The WebAssembly folks might have done that? From the Wasm SpecTec blog post I linked in a sister comment (emphasis in original):
> In fact, the formal version [of the Wasm spec] was written long before the prose, which was then created by manually transliterating the formal rules into natural language (for some definition of “natural”).
To be fair, I'm sure there was a lot of non-formal discussion in the process of creating the formal spec but I'm not sure whether that counts as "prose" in this context.
Re: My Rust experience after eight years
#37Earlier quoted context omitted.
Sharing resources is always a source of deadlocks and bugs, I don’t see a feasible resolution to that in a programming language. I don’t think one gets into deadlocks more often than any other language with Rust, but you are not experiencing most other concurrency bugs, which makes it feel like deadlocks are a bigger issue.
Wait, I've been told by "evangelists" that besides not having any security vulnerabilities, you also can't have deadlocks in Rust!
Those "evangelists" would be wrong, then. Rust prevents data races by default, but doesn't prevent deadlocks by default. It is possible to use Rust's type system to statically ensure the lack of deadlocks [0], but that's not provided by default.
[0]: e.g., https://docs.rs/lock_ordering/latest/lock_ordering
Re: My Rust experience after eight years
#38For me lack of language specification is not a problem and it is good that Rust only have one implementation so I don't have a headache to support multiple compilers like C++. The only problems I have with trait is lack of const function and trait upcasting, which just solved by 1.86 that released yesterday. For iterator type mismatched it does not cause much problem since I can create a dedicated generic function to…
Could you create a type around Mutex that enforces the locking order?
Something like https://docs.rs/lock_ordering/latest/lock_ordering perhaps?
Re: My Rust experience after eight years
#39Earlier quoted context omitted.
Sharing resources is always a source of deadlocks and bugs, I don’t see a feasible resolution to that in a programming language. I don’t think one gets into deadlocks more often than any other language with Rust, but you are not experiencing most other concurrency bugs, which makes it feel like deadlocks are a bigger issue.
Wait, I've been told by "evangelists" that besides not having any security vulnerabilities, you also can't have deadlocks in Rust!
No, you don't have data races in Rust. Deadlocks are more or less just as possible in Rust as in other languages. In fact, the 2024 edition of Rust changed something[0] to make it more difficult to hit some deadlock situations, but it's well-known that there's not much in the language to protect you from them.
[0] https://doc.rust-lang.org/edition-guide/rust-2024/temporary-...
Re: My Rust experience after eight years
#40Earlier quoted context omitted.
You can use the parking_lot mutex implementation crate, which includes support for deadlock detection. Personally, I also try to avoid using Tokio's async mutexes.
Tokio mutexes are only useful if a lock needs to be held across suspension points. Since futures can migrate threads between suspension points and most regular mutexes on most platforms do not support being unlocked from a different thread, tokio’s mutex has a very narrow but a well defined use case.
Another use for tokio's mutexes is that they won't block a thread while waiting to acquire the lock (as awaiting a tokio mutex is itself a suspension point). For some use-cases this might not matter, though.