Yeah I'd written some rust ~ 10 years ago when the language was very different and that led me to believe that it was a 'great within it's niche' sort of thing for a long time, but after spending the last couple of years with it as a daily driver I think it's a pretty great general-purpose language.

The one really common gotcha with rust is that when trying to write concurrent code, newbies tend to throw Arc<RwLock<T>> goo around everywhere, and they end up with the world's shittiest garbage collector.

▲ germandiago 5 hours ago | parent | next [-]

Give me something like boost.multiindex for Rust, and maybe I could think of trying some experiments.

I think C++ is an excellent choice due to its volubility actually. Bc when I want safety, I mostly have it (but I have done a lot of C++, admittedly).

▲ m00dy 5 hours ago | parent | prev | next [-]

yeah, locks are expensive.

▲ the__alchemist 5 hours ago | parent | prev [-]

It is interesting to see the different patterns used due to different cases and tastes. For example, my concurrency patterns rarely use locks, and are instead usually one of:

  - Dedicated hardware via DMA, multiple cores/MCUs etc
  - Thread pools (e.g rayon)
  - GPU
  - SIMD
  - Atomics
  - Interrupts and their ISRs
  - Event loops
  - std::sync Thread and MPSC (My Std rust default for not blocking the GUI etc)

	▲	surajrmal 4 hours ago \| parent [-]
		Most of it comes down to avoiding shared data. Unfortunately it requires forethought to do that well. There are also many cases where you do want to share data for optimal performance as other options are ultimately too heavyweight. Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).