Live data from Hacker News

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

sites.google.com

21–30 of 145 posts

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

#21
post #3

What's great about the actor model is that you can kinda apply it in languages not having such native support. Even if it will not be a strict model, with some education from the programmer it can do wonders and can be backed by lock free queues. What I see as a problem is always they for a thread to wait on new items a syscall must be executed which is costly. But one could use a spinlock a few cycles and later degr…

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 still effectively the choices that you've got to contend with: copying vs immutablity (bonus, COW mode, but still) vs ownership semantics.

Or to come at it from the other way: actors are far more featureful than is appropriate to directly compare to mere message passing semantics choices, because actors generally have some concept of error handling as a result of their relationship to scheduling, and that puts them on a whole different field.

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

#23

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.

unless they invented it, then it is flying monkeys everywhere.

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

#24
post #22

Speaking of concurrency, is there a current environment that does something similar to Linda? I always thought that sounded quite promising, but apparently that generally is a death sentence (I also liked Modula-3, the Palm Pre and Tcl).

I think that creating a Linda engine is a chicken/egg problem. If there are no applications that are using the paradigm, then there's no need for a highly performing engine.

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

#25

In case the author sees this: The indentation of the code samples is all over the place, making it quite hard to read. Even more so for a white-space sensitive language like Pony. Did you mix tabs and spaces?

Pony is not white space sensitive.

Readers are though..

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

#26
post #3

What's great about the actor model is that you can kinda apply it in languages not having such native support. Even if it will not be a strict model, with some education from the programmer it can do wonders and can be backed by lock free queues. What I see as a problem is always they for a thread to wait on new items a syscall must be executed which is costly. But one could use a spinlock a few cycles and later degr…

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.

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

#27
post #8

"The problem is, that sometimes, unfortunately, these tools are just not sufficient, it's still easy to shoot your own foot and get lost in a sea of complexity." As a non-native English speaker I found this use of commas very difficult to understand. Often I get the feeling that native speakers don't even notice it.

Native speakers are often prone to different mistakes than non-native speakers. For example "would of" (instead of "would have" / "would've"), confusing "they", "they're", "their" or confusing "where" with "were". a vs an is an interesting case, too.

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

#28
post #8

"The problem is, that sometimes, unfortunately, these tools are just not sufficient, it's still easy to shoot your own foot and get lost in a sea of complexity." As a non-native English speaker I found this use of commas very difficult to understand. Often I get the feeling that native speakers don't even notice it.

as the others have said, its incorrect grammar in English.

it would however be correct in German, so that might be it?

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

#29
post #19
post #8

"The problem is, that sometimes, unfortunately, these tools are just not sufficient, it's still easy to shoot your own foot and get lost in a sea of complexity." As a non-native English speaker I found this use of commas very difficult to understand. Often I get the feeling that native speakers don't even notice it.

The first comma is simply incorrect. "unfortunately" does need commas around it, but it could be moved to the beginning for a simpler sentence. The fourth comma is also incorrect and should be replaced by a semicolon. "Unfortunately, the problem is that sometimes these tools are just not sufficient; it's still easy to shoot your own foot and get lost in a sea of complexity." And looking at that now, I would also get…

Just to aid people who are interesting in looking this sort of thing up, the fourth comma in the original is an example of a "comma splice", where the comma is too weak to join the two independent clauses. You can solve a comma splice by either making the two independent clauses into separate sentences, joining them with a stronger piece of punctuation (like a semicolon, colon, or a dash), or by using a conjunction like "and".

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

#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 that is writing correct concurrent code, even when your compiler is helping you out.

Post reply on HN