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

91–100 of 145 posts

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

#91

Post by NickM »

lelf wrote: post #81

> Its use of dynamic typing makes me a little bit hesitant to use it, though, as I really love the help provided by static typing. There is dialyzer, a static type (and not only) analysis tool for Erlang. It is part of Erlang/OTP (i. e. built-in.) http://erlang.org/doc/apps/dialyzer/users_guide.html

Yeah as a long-time Erlang dev I would strongly recommend Dialyzer to anyone trying to build a serious Erlang project. It doesn't give you quite the same level of rigor that a strong typing system would, but it is nice to be able to spec out types on an as-needed basis while letting it infer types in other parts of the code. It kind of ends up feeling like a nice middle ground between static and dynamic typing, in my experience.

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

#92

Post by Animats »

felixgallo wrote: post #77
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.

Yes. Having spent too much time debugging code by people who thought they were clever enough not to need language safety, I want language-level protection.

(Did the Python crowd ever fix the race condition in CPickle?[1] They were in denial about this about eight years ago when I reported it. Doing multiple CPickle operations in separate threads can crash CPython. If you search for "CPickle thread crash" you find many reports of hard to reproduce problems in that area.)

[1] https://bugs.python.org/issue23655

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

#93

Post by dxhdr »

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.

> As a long-time pthreads programmer, these systems feel like skittish concurrency.

I interpreted "fearless" to mean the opposite of "defensive programming." You have to be pathologically defensive when coding with basic synchronization primitives. These languages provide an alternative that frees you from that mindset. I only have experience with Erlang/OTP but it has been mind expanding when it comes to writing complex, robust, concurrent code. In fact one of the core Erlang style principles is "do not program defensively." Try that with pthreads!

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

#94

Post by tempodox »

coldtea wrote: post #70
tempodox wrote: post #62

Earlier quoted context omitted.

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.

In Lisp and Smalltalk it's obvious enough how composite expressions are evaluated, and they don't have the usual infix syntax to begin with. Pony does and the different precedences are just a bad surprise. As far as that's a design decision, I'd call it bad design.

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

#95

Post by lastofus »

tombert wrote: post #89
jwr wrote: 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.

I believe all I/O is blocking unless you use something that wraps NIO. This is definitely true for core.async threads, but I'm not sure why it would any different for agents.

This is also a bit of a departure for people coming from Go or Erlang/Elixir.

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

#96

Post by coldtea »

tempodox wrote: post #94
coldtea wrote: post #70

Earlier quoted context omitted.

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

In Lisp and Smalltalk it's obvious enough how composite expressions are evaluated, and they don't have the usual infix syntax to begin with. Pony does and the different precedences are just a bad surprise. As far as that's a design decision, I'd call it bad design.

>In Lisp and Smalltalk it's obvious enough how composite expressions are evaluated, and they don't have the usual infix syntax to begin with.

That's Lisp. In Smalltalk they do (have the usual infix syntax).

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

#97

Post by goatlover »

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.

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?

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

#98

Post by espeed »

imtringued wrote: post #16
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.

The problem with fancy new programming languages is that no big company is willing to back it and then actually use it (this is the most important step). But languages without backing/usage go nowhere and then get donated to the apache or eclipse foundation.

You sure about that? Sylvan Clebsch [1] -- Pony's creator -- is now part of Microsoft Research [2], has been working on a distributed actor model, and is presenting on Pony at QCon London next week [3].

[1] https://github.com/sylvanc

[2] https://www.microsoft.com/en-us/research/people/syclebsc/

[3] https://qconlondon.com/speakers/sylvan-clebsch

Pony: Co-Designing a Type System and a Runtime [video] https://www.microsoft.com/en-us/research/video/pony-co-desig...

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

#99

Post by lilactown »

stingraycharles wrote: post #82
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…

It’s also worth noting that almost nobody uses agents or STM (except for some highly specific use cases, but I’ve never seen them in years), and core.async is a library, not a part of Clojure (which is a good thing, because it promotes choice and keeps the language small).

I used agents for things like polling (combined with a scheduling library) because the additional plumbing with core.async wasn't worth it. But it's pretty niche.

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

#100

Post by zzzcpan »

gpderetta wrote: post #72
zzzcpan wrote: post #67

Earlier quoted context omitted.

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…

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

Think of it as reacting to messages, not waiting. In that model actors of course can react by sending messages, but can't have a special waiting state for specific messages, making it impossible to block other handlers. I'm not sure why this is hard to understand.

We do have this problem solved in every possible way. But it's so not a big deal with actor model, that there is no point sacrificing any flexibility for it.

Post reply on HN