Live data from Hacker News

Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

sites.google.com

101–110 of 145 posts

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#101
post #89
post #86

Earlier quoted context omitted.

I did use agents in the past, but stopped since core.async became available: it addresses the use cases for agents in a much more flexible way. Also, I found that handling errors in agents is difficult. As for the general use case, atoms and core.async are great tools, and I haven't needed to use refs (aka the STM) for years.

Don't the core.async go-blocks have issues if you need to block on IO heavy stuff, as in the thread-pool will be blocked until the side-effects are done? Agents don't have that problem, at least I don't think they do.

Yeah this is true, typically you want to keep blocking functions outside this. By default, core.async allocates as many threads as cores in your CPU.

In addition to this, I personally find core.async to deal poorly with flow control (e.g. slow subscribers slowing down the entire flow for every subscriber), and seems to not have a lot of telemetry / it’s difficult to find out what’s going on in the thread pool behind it.

I’ve personally settled on Zach Tellman’s Manifold library, which provides a much more sane abstraction and is fully compatible with core.async.

For some addition thought and material on these topics, I highly recommend watching this talk by Zach, “Everything Will Flow” https://youtu.be/1bNOO3xxMc0

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#102

I was really excited to discover Pony a couple of years ago, sadly there is negative momentum with this project. So much potential, yet the world isn’t ready for it yet.

Mind explaining what you mean by 'negative momentum'? I'd never heard of Pony before and only took a look at it just now.

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#103
post #68
post #57

Earlier quoted context omitted.

Important part of STM is that the retry mechanism requires functions to be pure - which haskell compiler will check for you.

Technically, STM requires that you're not updating your state via side effects. That's a different proposition from requiring your functions to be pure. For example, you could have a function with a print statement inside your STM transaction just fine.

If you want to go way down that rabbit hole, it's an active topic of conversation in the Haskell community right now how to break up IO into more granular pieces than what the IO type natively provides, where a function is either "pure" or it's a dirty rotten effects producer, and no middle ground in between.

Although, even a stray print inside an STM transaction could actually do you a lot of damage, since "print" is actually a fairly expensive operation. I've written all sorts of programs in my life that were technically bottlenecked not on reading the input, writing the output, or any of the processing in-between, but on the printing it was doing. And, relatedly, every community that tries to write a really blazingly fast web server in their language runs into a bit of a wall around the mere act of logging the hits. (Even just the date computation starts to bottleneck things, but the writing does too.)

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#104
post #55

I'm a bit surprised that there didn't appear to be any mention of Clojure's built-in concurrency support outside of basic immutability. core.async gives a nice channel-based system, agents give an actor-ish system, and STM/atoms let you mutate the variable safely, without having to manually work with locks. This is definitely a good high-level article, just something I was surprised by, since core.async is what drove…

It was not built-in because it WAS possible, unlike other languages. So I think the argument in this specific case is mute.

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#105

Whether or not this is "fearless" depends on your point of view. As a long-time pthreads programmer, these systems feel like skittish concurrency. It's for folks who are too afraid to use the underlying concurrency primitives, like shared memory, synchronization of some kind provided by OS, threads.

Isn't it better to let the computer handle things humans are bad at unless you have a real good reason to muck around in the lower level?

No, because that would make sense. You MUST shoot yourself in the foot at absolutely every opportunity that presents itself or you're too afraid.

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#106
post #89
post #86

Earlier quoted context omitted.

I did use agents in the past, but stopped since core.async became available: it addresses the use cases for agents in a much more flexible way. Also, I found that handling errors in agents is difficult. As for the general use case, atoms and core.async are great tools, and I haven't needed to use refs (aka the STM) for years.

Don't the core.async go-blocks have issues if you need to block on IO heavy stuff, as in the thread-pool will be blocked until the side-effects are done? Agents don't have that problem, at least I don't think they do.

All of the core.async operations having blocking versions (eg. >!! vs. >!) which means you can use your own threads/thread pools for any work, if needed. Basically, you create your own threads instead of using go blocks and then use the blocking operations, >!!, <!!, alts!!, alt!!, etc.

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#108
post #55

I'm a bit surprised that there didn't appear to be any mention of Clojure's built-in concurrency support outside of basic immutability. core.async gives a nice channel-based system, agents give an actor-ish system, and STM/atoms let you mutate the variable safely, without having to manually work with locks. This is definitely a good high-level article, just something I was surprised by, since core.async is what drove…

STM in Haskell is really nice to use also.

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#109

Whether or not this is "fearless" depends on your point of view. As a long-time pthreads programmer, these systems feel like skittish concurrency. It's for folks who are too afraid to use the underlying concurrency primitives, like shared memory, synchronization of some kind provided by OS, threads.

Rust's primitives are all thin wrappers on top of libpthread. The difference is that the type system ensures you don't forget them, and makes it harder to misuse them (such as accessing data without locking its mutex, or mutating shared memory in a non-atomic way).

And even if you think you never make mistakes, and it's always the other programmers who are the problem, Rust keeps other peoples' code in check too.

Re: Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart

#110

What about picking jobs from an SQL-table as writing back with a check? I naver had any of the problems specified on a multi-core/process system.. or have I just been lucky or blessed by ignorance?

That's an example of shared-nothing message-passing system, which is a perfectly valid solution. It's implementable in all the aforementioned languages.
Post reply on HN