Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart • Hacker News Board

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

#141

Post by lugg » Wed, Feb 27, 2019, 4:41 AM UTC

kccqzy wrote: post #128

lugg wrote: post #121

Earlier quoted context omitted.

Did you just say single threaded concurrently reasoned applications are more performant than multithreaded applications? Trying to reason about how this could be possible. I'm still amazed by the performance you can get out of async non blocking style application code so don't take this the wrong way, truly trying to understand here. I'm also a little confused about threads being rescheduled by the OS being treated l…

No I didn't say "single threaded concurrently reasoned applications are more performant than multithreaded applications" because I was highlighting this style of concurrency from the programmer's perspective. But yes, for certain types of applications it can be more performant. Naturally, if your application is computationally intensive, a single thread can't compete with a multithreaded application. But for applicat…

Thanks for the clarification I see your angle now.

I'm not trying to debate on this, pretty sure we're just reasoning about facts we both agree on here.

I was aiming for a more general stance but if were talking about web servers there is one thing we might disagree on being the net benefit of non blocking in that specific scenario.

Let me see if I can explain, the individual requests may contain a lot of slow blocking io but these are handled async with a thread per request at the server level. So the request and internal blocking is limited to the request only (ignoring thread pool limits.)

While it may be that non blocking might produce more performant request level handling in some cases most or at least a substantial amount of web request logic is very dependent on chaining those blocking io one after the other, e.g. get thing modify, return.

In blocking you execute and reason about sequentially in non blocking you reason about with callbacks or syntactic sugar around promises specifically because sequential programming is easier to reason about.

The point of difference being that in non blocking you have a lot of overhead in the event loop and in the implementation, all to produce sequentially executing code that doesn't block other requests.

This is sort of why me and a few colleagues came to the conclusion PHP is still pretty damn decent for web stuff.

Non blocking is great for concurrency where it actually results in parallelism but if it doesn't then there isn't much gain other than gained complexity.

All this needs to be taken with a grain of salt. Node has Async await for a reason, and I've seen a few different implementations of non blocking php as well.

The choice really comes down to which style you find your self benefiting from on the regular.

Bleh that needs about three rounds of editing before it makes sense, something I don't have time for. Sorry for the ramble!

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

#142

Post by rurban » Wed, Feb 27, 2019, 7:16 AM UTC

daotoad wrote: post #130

It's too bad Perl6's interesting approaches to concurrency aren't mentioned here. Supporting concurrency and parallelism were key points in the design of Perl6, and in the multi-paradigmatic way of Perl, it provides a variety of tools. Jonathan Worthington can write and speak about this topic far better than I can so I refer you to his talk and slides: 1. http://www.jnthn.net/papers/2018-conc-par-8-ways.pdf 2.C https…

But these explicitly don't mention the two best approaches he chose to ignore and even kill.

First the parrot threading model, which provided lockless safe threadpools, and second the pony threading model which provides the same on top of supporting shared refs, and forbids blocking IO. Which makes it even faster.

His talk ends with his simple approach taken being the best. Which is not only wrong but also a lie, because he was part in killing off the parrot threading model.

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

#143

Post by nickik » Thu, Feb 28, 2019, 9:50 AM UTC

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.

I understand that, but that has nothing to do with STM in general and everything with Haskell solution in particular.

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

#144

Post by yogthos » Thu, Feb 28, 2019, 11:56 PM UTC

leshow wrote: post #136

yogthos wrote: post #127

Earlier quoted context omitted.

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…

Except that they're not the same. Static typing restricts you to a set of statements that can be verified by the type checker. This is a subset of all valid statements, otherwise you could just type check code in any language at compile time.

Static typing makes many dynamic patterns either difficult or impossible to use. For example, Ring middleware becomes pretty much impossible in a static language https://github.com/ring-clojure/ring/wiki/Middleware-Pattern...

The pattern here is that the request and response are expressed as maps. The request map is passed through a set of middleware functions, and each one can modify this map in some way.

A dynamic language makes it possible to write middleware libraries that know absolutely nothing about each other, and compose seamlessly. A static language would require you to provide a full description of every possible permutation of the request map, and every library would have to conform to it. This creates coupling because any time a library needs to create a new key that only it cares about, the global spec needs to be modified to support it.

My experience is that immutability plays a far bigger role than types in addressing the problem of maintainability. Immutability as the default makes it natural to structure applications using independent components. This indirectly helps with the problem of tracking types in large applications as well. You don't need to track types across your entire application, and you're able to do local reasoning within the scope of each component. Meanwhile, you make bigger components by composing smaller ones together, and you only need to know the types at the level of composition which is the public API for the components.

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

#145

Post by snapdangle » Tue, Mar 05, 2019, 8:26 AM UTC

rurban wrote: post #142

daotoad wrote: post #130

It's too bad Perl6's interesting approaches to concurrency aren't mentioned here. Supporting concurrency and parallelism were key points in the design of Perl6, and in the multi-paradigmatic way of Perl, it provides a variety of tools. Jonathan Worthington can write and speak about this topic far better than I can so I refer you to his talk and slides: 1. http://www.jnthn.net/papers/2018-conc-par-8-ways.pdf 2.C https…

But these explicitly don't mention the two best approaches he chose to ignore and even kill. First the parrot threading model, which provided lockless safe threadpools, and second the pony threading model which provides the same on top of supporting shared refs, and forbids blocking IO. Which makes it even faster. His talk ends with his simple approach taken being the best. Which is not only wrong but also a lie, bec…

Reini, get off your crazy horse man! No one in the world, including the author of the Parrot threading model, thinks it is the "best" threading model.