>using a non-functional langauge for your concurrent program

>>55257704
>what is Monad.Lock

>>55257704
Just use rust, it literally prevents race conditions straight via the typesystem, no need to restrict yourself into a paradigm that outright forbids mutations.

>>55259874
Not him but depending on performance requirements of what you are doing its possible to not even need mutations

>>55260907
Rather than "needing" mutation, it's about the convenience of being able to use mutation. Some problems are inherently easier to express in that context. Just like trying to program functionally in a language that doesn't inherently support it creates a mess, so does trying to implement solutions to problems that naturally lend themselves to a sequential solution using mutation.

>>55259874
The problem is that Rust's approach limits throughput. This approach works fine for device drivers and the like, but is unsuitable for high-level applications.

The best approach is Clojure's in-memory implementation of MVCC. While high contention circumstances will lead to some wasted work, studying results from database theory informs us that this drawback isn't as exaggerated as you'd imagine, and STM usually out-performs traditional lock-based or type-based solutions.

>>55261699
There's nothing preventing the use of STM in rust. In fact, there are already two STM libraries for rust: stm and stim.

>>55261793
Yes, but it's provided via a library and thus will never integrate into the core language like Clojure, and the benefits of STM are lost in the granularity if you permit mutable data structures.

Semaphores

What's the best language for distributed systems?

Erlanggggg

I just need some of the stuff to run asynchronously. C# is perfect for that.

>>55257704
>what is mutex

>>55265279
>what is deadlock

>Rust
>The new meme in town, after Go, after Node.JS
>Chinese people are already coding Rust libs on github

>>55265279
A workaround for shitty languages

>>55265159
Java has Hadoop

File: haskell.png (12KB, 225x321px) Image search: [Google]

12KB, 225x321px

daily reminder

>>55262987
>Semaphores
>reliable
choose one

>>55266710
It's something Haskell does for you....mutex is cheaper and therefore more cost effective

>>55267218
kek

>>55267269
>mutex is cheaper and more cost effective
This actually isn't true. There's literature out there that suggests that STM techniques out-perform lock-based concurrency.

http://dl.acm.org/citation.cfm?id=1189288

>muh CSR

Some problems are parallel in nature, some are concurrent. Even C has APIs to do CSR properly.

You don't avoid concurrency just because you're using Haskell.

>>55269298
>You don't avoid concurrency just because you're using Haskell
I'm not sure what you mean by this?

>>55269298
You inherently avoid concurrency issues because your code is side-effect free and therefore ALWAYS safe to parallelize outside the explicit dependency graph laid out by the very AST itself, since there is no other dependencies at any time.

>>55269284
Pajeets btfo