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

131–140 of 145 posts

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

#131

Post by kazinator »

coldtea wrote: post #96
tempodox wrote: post #94

Earlier quoted context omitted.

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

> have the usual infix syntax

Isn't it the case that all operators in Smalltalk have the same precedence and left-to-right associativity? That's not "the usual" infix syntax.

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

#132

Post by coldtea »

kazinator wrote: post #131
coldtea wrote: post #96

Earlier quoted context omitted.

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

> have the usual infix syntax Isn't it the case that all operators in Smalltalk have the same precedence and left-to-right associativity? That's not "the usual" infix syntax.

Usual referring to the mere "infix syntax" part (as opposed to some other kind of syntax that isn't infix).

Not to having "infix syntax plus the associativity / precedence you get in C". We've already established that it doesn't have the usual precedence.

The distinction was with e.g. Lisp which has a prefix syntax (polish notation), and other more exotic styles.

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

#133

Post by pizlonator »

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

Couldn't the same argument be made for manual memory management? Couldn't I say that GC'd languages are for "people too afraid to handle pointer juggling"? I've done a fair amount of pthread work, and I coded myself into enough hard-to-debug issues in C that when I discovered I could fairly-easily structure my stuff around ZeroMQ, and then later discovering a book on different process calculi, I decided that there's…

Nobody who promotes GCs calls it “fearless memory management”. So no. The same thing cannot be said for GC.

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

#134

Post by pizlonator »

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.

False. Lots of software uses pthreads and its direct wrappers.

Correctly? What does anyone ever do correctly in software? Does anyone write GUIs correctly? Does anyone do databases correctly? Proving even simple software correct is an enormous endeavor that most pragmatic programmers simply never have the luxury to do. So proclaiming that threads are bad because nobody does them “correctly” is setting an arbitrarily high standard. Or maybe you just don’t know what that word means.

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

#135

Post by pizlonator »

justryry wrote: post #79
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…

Every Turing complete primitive makes it possible to get an incorrect result. Every Turing complete primitive inevitably generates bugs. That’s the reality. Singling our threads because they also obey that basic law of computer science is a little selective, don’t you think?

I understand what the thing they call “fearless concurrency” is. And I will repeat again: it’s skittish concurrency. It’s for fearful people.

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

#136

Post by leshow »

yogthos wrote: post #127
jerf wrote: post #103

Earlier quoted context omitted.

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" i…

That's the difference between Clojure and Haskell mindsets in a nutshell. Clojure approach is to have sane defaults and guide the programmer towards doing the right thing, but ultimately letting them do what they need to. Whether it makes sense to do something or not is context dependent in practice. Ultimately, the person writing the code understands their situation best, and the language shouldn't get in the way of…

> You could of course argue that by preventing the user from doing certain things you avoid some classes of errors. However, I will in turn argue that by forcing the user to write code for the benefit of the type checker often results in convoluted solutions that are hard to understand and maintain. So, you just end up trading one set of problems for another.

Funny, this is exactly the opposite of my take from a type system like Haskell's. The thing is, whether it's enforced by types or not, the same invariants exist in your code. The only difference is that in one case they are checked explicitly at compile time, and the other case they are hidden and can blow up your programs.

If anything, explicit invariants make code easier to maintain and understand.

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

#137

Post by dmix »

lugg wrote: post #122
dmix wrote: post #71

Earlier quoted context omitted.

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.

Whats a tldr for how Erlang handles error handling? This is something that is usually glossed over / afterthought when it is kind of a big deal in real life programming.

It’s hardly an afterthought in Erang. It’s a fundamental part of OTP to handle failure. Which is far easier when everything is wrapped in restartable processes with immutable state.

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

#138

Post by e12e »

toolslive wrote: post #32
fyfy18 wrote: post #14

Earlier quoted context omitted.

It sounds like OP is a non-native speaker too. I'd simplify it to this: "The problem is that sometimes these tools are just not sufficient. It's still easy to shoot yourself in the foot and get lost in a sea of complexity." (Hemingwayapp is great for making sure writing is not too complex)

"These tools are often insufficient" ?

"These tools are insufficient" (or: are not enough).

A tool that's "often insufficient" isn't a very good tool - by virtue of often being insufficient - it becomes [ed:simply] insufficient?

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

#139

Post by goatlover »

dunefox wrote: post #105
goatlover wrote: post #97

Earlier quoted context omitted.

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.

Real programmers use Assembly/C/Fortran 77 for everything.

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

#140

Post by felixgallo »

pizlonator wrote: post #134
felixgallo wrote: post #77

Earlier quoted context omitted.

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

False. Lots of software uses pthreads and its direct wrappers. Correctly? What does anyone ever do correctly in software? Does anyone write GUIs correctly? Does anyone do databases correctly? Proving even simple software correct is an enormous endeavor that most pragmatic programmers simply never have the luxury to do. So proclaiming that threads are bad because nobody does them “correctly” is setting an arbitrarily…

Are you saying that buggy software is good because it’s widespread, and then trying to ad hominem me? Because that’s adorable both ways.
Post reply on HN