Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

sites.google.com

Post reply on HN
Print view View original

61–70 of 145 posts

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

#61

Post by jerf »

leshow wrote: post #53
fogetti wrote: post #43

I am not sure but I think Go channels were inspired by CSP (communicating sequential processes) which is not inherently unsafe though.

from the article: > Notice that this article does not include Go, a language that admittedly has an elegant concurrency solution as well (Go channels) because that solution is not actually thread-safe - it's not very hard to have race conditions in Go or corrupt state because Go does not enforce a separation of shareable and not-shareable mutable state.

My vote for Go's #1 mistake isn't the popular "lacking generics", but missing the opportunity to have fearless concurrency, and making it so that goroutines can only communicate via immutable shared values and copied values. If you want to optionally and explicitly penetrate that barrier sometimes, I'd be OK with that, but this should be the default.

Generics will probably be added after the fact 10 years after the 1.0 release. They may not be quite as slick as something that was in there from the beginning, but based on the many other languages that added them after the fact, it'll probably work out well enough. Fearless concurrency can't be added to a language; if it's not in there from the beginning it'll never be added. It's a change so big it's almost automatically a new language. And, as can be logically deduced from that statement, I am aware that it would have some additional effects in the language, such as introducing immutability, it wouldn't be simply what we now know as "Go" with just a minor tweak. I'm comfortable with that. Even with Go's focus on simplicity, I do think there was a slight error towards being a bit simpler than the problem permits here.

(I do pretty well with Go's concurrency, but I was first trained brutally by Erlang and Haskell. I see those who don't come by the same route have more trouble.)

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

#62

Post by tempodox »

smallstepforman wrote: post #2

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.

Or Pony is not ready for the world. I mean, they don't even have arithmetic operator precedences [1]. If you're doing things concurrently it must be something uber-important, like censoring cat pictures, but apparently not arithmetics.

[1] https://github.com/aksh98/Pony_Documentation#precedence

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

#63

Post by throwaway2-32 »

tombert wrote: 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…

52 major open issues, 2 critical issues, and 38 others

major issues list memory leaks. https://dev.clojure.org/jira/secure/IssueNavigator.jspa?rese...

first-party?

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

#64

Post by gpderetta »

zzzcpan wrote: post #59
falcolas wrote: post #51

Earlier quoted context omitted.

How do you solve for deadlocks at the compiler level? Even if all your memory access is perfectly safe, you can still deadlock on external resources if you aren't pay attention. That's what I mean by fear and respect for concurrent programming. That's the problem that hasn't been solved.

Deadlocks is a solved problem. Technically, they can't even exist in any concurrency model that doesn't share anything. What can exist is processes waiting for messages from each other, but that's not a deadlock, but a valid behavior and is only potentially problematic without timeouts. Asynchronous message passing with event-driven/reactive semantics farther enforce impossibility to block on waiting for a specific m…

Deadlocks are not restricted to shared memory communication. Two Unix processes talking via a socket pair can trivially deadlock ( for example if they are both blocked waiting for the other side to speak first).

Also asynchronous systems can deadlock as well, it is just much harder to debug as the debugger won't show an obvious system thread blocked on some system call; the deadlocked threads of execution still exist but will have been subject to CPS and hidden from view (just some callback waiting forever on some wait queue).

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

#65

Post by bgorman »

throwaway2-32 wrote: post #63
tombert wrote: 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…

52 major open issues, 2 critical issues, and 38 others major issues list memory leaks. https://dev.clojure.org/jira/secure/IssueNavigator.jspa?rese... first-party?

Core async is maintained by Cognitect (maintainers of Clojure). It is very commonly used, and it has been upgraded to mesh well with the rest of the language over time (namely support for transducers).

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

#66

Post by tombert »

throwaway2-32 wrote: post #63
tombert wrote: 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…

52 major open issues, 2 critical issues, and 38 others major issues list memory leaks. https://dev.clojure.org/jira/secure/IssueNavigator.jspa?rese... first-party?

I don't really know what that has to do with anything; every piece of software has bugs. I haven't really encountered any issues with core.async yet. I suspect you could find similar bugs in nearly any popular concurrency library.

By first-party, I mean it seems to be officially part of the Clojure ecosystem, the docs are hosted on the main site: https://clojure.github.io/core.async/

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

#67

Post by zzzcpan »

gpderetta wrote: post #64
zzzcpan wrote: post #59

Earlier quoted context omitted.

Deadlocks is a solved problem. Technically, they can't even exist in any concurrency model that doesn't share anything. What can exist is processes waiting for messages from each other, but that's not a deadlock, but a valid behavior and is only potentially problematic without timeouts. Asynchronous message passing with event-driven/reactive semantics farther enforce impossibility to block on waiting for a specific m…

Deadlocks are not restricted to shared memory communication. Two Unix processes talking via a socket pair can trivially deadlock ( for example if they are both blocked waiting for the other side to speak first). Also asynchronous systems can deadlock as well, it is just much harder to debug as the debugger won't show an obvious system thread blocked on some system call; the deadlocked threads of execution still exist…

It's not useful to use the same term for very different kinds of things. Shared resource deadlocks are common and disastrous problems. Share nothing mutual blocking is uncommon, not necessarily a problem at all and can be completely harmless and automatically recovered when it is a problem. For example, spawning actors to wait without timeouts would be absolutely ok, parent can do all the timeouting and kill the children.

Two processes blocking on a socket is not a deadlock. Surely there are timeouts on both sides, because using sockets without timeouts is just ignorance, and both will just timeout and move on.

Also strictly statically declared event handlers per actor are 100% mutual blocking and deadlock free. Because they can't wait for messages in a way, that blocks other event handlers.

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

#68

Post by yogthos »

londt8 wrote: post #57
nickik wrote: post #40

Earlier quoted context omitted.

The idea of STM has nothing todo with strong types. You can have STM with types or without. Clojure has a full STM since version before version 1.0. Simple example: (def stm (refs {})) (alter! stm assoc :testkey "testvalue") (println @stm) See: https://clojure.org/reference/refs

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.

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

#69

Post by whateveracct »

falcolas wrote: post #30

I have a, perhaps unjustified, concern at the loss of fear around things like concurrency. People keep substituting appeasing the compiler with actual thinking around hard problems. But until the halting problem is solved at a compiler level (at a level that can account for runtime cases), you should always have a healthy amount of fear when writing concurrent code. Fear, and respect, the absurdly difficult challenge…

> But until the halting problem is solved at a compiler level (at a level that can account for runtime cases)

Idris can already check for totality (i.e. guarantee its programs will halt) without solving the (unsolvable) halting problem. So we're almost there!

And even in Haskell, you can write certain classes of concurrent code without thinking thanks to 1) its great RTS and concurrency libraries and 2) the fact that Haskell programs compose so well: If I have thread safe programs A and B, Haskell gives me a variety of ways to compose their results in such a way that thread safety is always preserved.

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

#70

Post by coldtea »

tempodox wrote: post #62
smallstepforman wrote: post #2

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.

Or Pony is not ready for the world. I mean, they don't even have arithmetic operator precedences [1]. If you're doing things concurrently it must be something uber-important, like censoring cat pictures, but apparently not arithmetics. [1] https://github.com/aksh98/Pony_Documentation#precedence

>Or Pony is not ready for the world. I mean, they don't even have arithmetic operator precedences

Many languages don't have arithmetic operator precedence (Smalltalk, Lisp, etc) and that's fine.

It's not some feature that's missing, it's a design choice.

Post reply on HN