crossbeam VS rust

Deadlocks and leaks are easy as other languages.

Ouch, didn’t know about https://github.com/crossbeam-rs/crossbeam/issues/821, thanks for pointing that out, that’s a big update for me!

The last option I can think of is using two threads (like above) and epoch GC instead of a lock (i.e. using crossbeam-epoch). But I don't have enough experience with this to say anything about it.

You should definitely look at the Rayon crate. After I figured that out, my productivity vs multi threaded C was exponentially better (literally did many days of equivalent C work in less than an hour). Rayon is focused on data processing, other multi threaded stuff can benefit from other crates like crossbeam (Channels, scoped threads), and tokio (async networking).

Crossbeam – Tools for concurrent programming in Rust\ (14 comments)

Glad you like it 🙂 https://github.com/rust-lang/rust/pull/58530

It's directly responsible for Rust needing the "turbofish" syntax to pin down generic return types as in

let foo.iter().map(|x| x*2).collect::>()

If they'd used something like [T] for generics, then there'd be no collision with the < and > operators needing disambiguation in some contexts.

They even have a Book of Mozilla-esque entry in their test suite named "Bastion of the Turbofish" to pin down an example of the problem case, complete with

https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba9...

To my knowledge, this closure syntax was a direct Ruby influence mainly because this syntax was also supposed to work like Ruby blocks: `array.each |e| { ... }`. Originally owned and shared closures had a different syntax (`fn~() { ... }` or `[email protected]() { ... }`)---this was back when Rust had a built-in shared reference, roughly equivalent to `std::sync::Arc` in the modern Rust---and it was pointed out that they should be harmonized at some point [1]. It was that time when people realized that then-loop-only syntax can be generalized into any closures, and this semi-decision got stuck even after the "internal" iterator that accepts a closure has long gone.

[1] https://github.com/rust-lang/rust/issues/1864

I found only this issue https://github.com/rust-lang/rust/issues/87970 but has no details

Here's the discussion that lead to the implementation of those functions, from more recent to least recent,

* the tracking issue https://github.com/rust-lang/rust/issues/49048

* the RFC https://github.com/rust-lang/rfcs/pull/2169

* the internals discussion https://internals.rust-lang.org/t/mathematical-modulo-operat...

It's baffling that Rust got this wrong..

If rust has no runtime, maybe you could enlighten us as to what this is: https://github.com/rust-lang/rust/blob/master/library/std/src/rt.rs

I don't want to list specific contributors here. We often have no information on why people left the project - there might be all sorts of personal factors. I will say that my broader sentiment - that Rust's momentum has slowed, that it's not delivering on its commitments in a timely way, that there are concerns about it's ability to deliver in future - has been expressed publicly by high profile past core contributors:

https://github.com/rust-lang/rust/pull/96709#issuecomment-11...

I don't think Rust should tackle any ambitious project to rewrite the compiler while these basic concerns remain.

Commit counts regularly fluctuate: https://github.com/rust-lang/rust/graphs/contributors

Potentially it is due to this layout optimization and a missing repr(C) somewhere in your code or a dependency. For example, here is an is a related issue in luminance.

rav1e is quite well maintained, the fix for the lint was merged days after the ilog PR merged. But the 0.5.1 release of rav1e was one year ago, in December 2021, while the ilog rename was end of August 2022. There hadn't been a release though of rav1e until end of November 2022, which was also a semver incompatible one. Users had only 2-ish months of time to get to the new rav1e version without experiencing breakage.