Using a non-functional langauge for your concurrent program

>using a non-functional langauge for your concurrent program
enjoy race conditions faggot

Other urls found in this thread:

dl.acm.org/citation.cfm?id=1189288
twitter.com/SFWRedditImages

>what is Monad.Lock

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

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

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.

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.

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

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.

>what is mutex

>what is deadlock

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

A workaround for shitty languages

Java has Hadoop

daily reminder

>Semaphores
>reliable
choose one

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

kek

>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.

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.

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

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.

Pajeets btfo