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

71–80 of 145 posts

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

#71

Post by dmix »

macintux wrote: post #26
heavenlyhash wrote: post #21

Earlier quoted context omitted.

I found it interesting that the article mentions actors much at all for the same reason. It's pretty trivial to construct actors out of some other message passing system. The interesting design choices in doing so are mostly down to the semantics in A) message passing, and B) scheduling/triggering/mapping-onto-green-threads/etc. And for part A, all the other choices in the first three segments of the article are stil…

That’s a big reason I’m a fan of Erlang: individually, its features are interesting, but collectively they form an amazing system. Greater than the sum of its parts.

Agreed, it's one thing to have good primitives like Go channels but Erlang/Elixir provide an entire system from which to build a concurrent/async application. Things like error handling, messaging, storage, and structuring your application well for concurrency are already basically built-in into the standard approach you take building Erlang/Elixir apps.

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

#72

Post by gpderetta »

zzzcpan wrote: post #67
gpderetta wrote: post #64

Earlier quoted context omitted.

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 chil…

The term deadlock has been used for message passing issues since the dawn of time. It is literally the same issue.

Using timeouts to paper over issues is just wrong. I accept that timeouts are necessary to deal with network issues (and a timeout should cause the connection to be dropped, so won't solve the deadlock issue), but certainly they are not required for in-application message passing.

Finally if an actor won't send a message untill it has received another one, I fail to see how statically declared handlers will help.

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

#73

Post by weberc2 »

johnisgood wrote: post #54
weberc2 wrote: post #50

Earlier quoted context omitted.

We learned some Ada in school. I really liked it, but the free toolchain was poor (hard to get working properly, unintuitive) and the community stubbornly defended its various idiosyncrasies like its verbose Pascal syntax and its homegrown project file format. Most importantly, it just didn’t heave much of an open source ecosystem, and the community was pretty hostile and defensive toward newbies. But yeah, the langu…

When did this happen? Have you checked its current state? It has been growing ever since. There are dozens of tools available today for free, and it is very easy to set up. I agree that its open source ecosystem needs to grow, but for that we do need more Ada programmers! :P By the way, I am really sorry if you experienced hostility from the community. May I ask where it took place? I had similar experiences with a v…

Hmm, circa 2012. I've checked in on it a handful of times in the ensuing years, but I came across Go in 2014 and it ended up suiting my needs almost perfectly (rapid application development, simple, great performance, mostly safe, fantastic tooling/ecosystem, zero-runtime-dependencies, etc).

As for where the hostility took place, it was most Ada proponents who would pop up in /r/programming, here on HN, etc. I'm sure the circumstances select for the most toxic folks from any community, but it seemed especially potent from Ada folks (could have been bad luck, ymmv and all that).

Would love for Ada to modernize and improve tooling/ecosystem, but between Go and Rust, I'm afraid that the advantages for a modern Ada might be marginal. It seems unfortunate for Ada that it didn't modernize prior to 2012; it could have eaten both Go and Rust's lunch before they even existed.

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

#74

Post by pizlonator »

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.

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

#75

Post by jerf »

kibwen wrote: post #39
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…

I find this line of thinking to be a holdover from an earlier age. One could replace the word "concurrency" in the above comment with "memory safety" to express the popular sentiment as of the 1980s--but in the decades hence the vast, vast majority of programmers have come to be able to completely ignore concerns related to the careful management of allocating and deallocating memory, and though we can argue that the…

I like to say that threads & locks makes concurrency an exponential problem, but the fearless concurrency solutions make them a polynomial problem. Still a problem, but no longer insane, incomprehensible, and impossible.

Personally I suspect generalized concurrency is always going to be something that "professional" programmers deal with, and non-professionals will only get pre-canned solutions for particular problems, because the general case will always be a bit more complicated than non-specialist programmers are going to want to handle. I think concurrency is worse in terms of what you need to keep in your head than raw pointers are, and those are already too much for a non-specialist.

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

#76

Post by toast0 »

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…

A lot of the fear around concurrency comes from hard won experience. Shared memory concurrency is _really_ hard to get right, and the results are often streams of execution that are very perplexing. Message passing concurrency isn't without pitfalls, but the pitfalls are fewer, and the debugging usually more clear -- your stuck processes/threads usually indicate what they're waiting for, and when you find two threads waiting for a message from the other, you know you messed up the ordering. Of course, the message passing infrastructure still has some tricky concurrency problems itself, but that's a smaller, more tractable problem.

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

#77

Post by felixgallo »

pizlonator wrote: post #74

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.

Exactly. Because the recorded history shows those constructs are nearly impossible to use correctly.

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

#78

Post by stingraycharles »

pizlonator wrote: post #74

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.

On the other hand, a powerful concurrency abstraction can make it much easier to reason about a large system. But I agree that the “fearless” part is mostly unjustified.

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

#79

Post by justryry »

pizlonator wrote: post #74

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.

While those primitives you mention make it possible to get a correct result, they require consistent and correct use from the programmers. While some of us may do this perfectly most of the time, bugs are inevitably created. This is reality.

Fearless concurrency means guaranteeing many of those problems cannot occur. That frees up brain cycles, eases maintenance, reduces bugs, and perhaps even opens up concurrency to a wider audience or set of use cases.

Post reply on HN