5 ms·

> I'm not much into asynchronous languages. Is there any examples around with a built in and slim syntax for concatenating callbacks? Thanks. Yeah it's called

> I'm not much into asynchronous languages. Is there any examples around with a built in and slim syntax for concatenating callbacks? Thanks. Yeah it's called any language that offers good abstractions for concurrency. Elixir/Erlang, Haskell, Clojure and Go are a few good examples.

pmontra 12y ago
I played a little with Elixir (and Phoenix) months ago and I know the |> operator, which is not exactly what I was looking for in my reply. I'll look again at Elixir and at how it handles callbacks.
- tel 12y ago
  |> is (not, see below) mere function composition function compose(f, g) { return function inner(x) { return f(g(x)); } } this is not the right kind of composition for something like nested callbacks. For that you need slightly more. Edit: It's actually the "apply" operator which looks like function apply(f) { return function applied(x) { return f(x); } } Apply and compose work together nicely. For instance, in Haskell apply is ($) and compose is (.), so you can build a compositional pipeline and apply it like f . g . h $ x or like f $ g $ h $ x since association goes this way f $ (g $ (h $ x))
  - deleted 12y ago
    [deleted]
    - tel 12y ago
      Ah, my bad, I was distracted writing. It's Haskell's ($), not the (.).
      - rubiquity 12y ago
        No worries. I deleted my post before your reply came through because I didn't feel my example was good and I'm struggling to do better this early in the morning :D In a lot of cases compose and |> will be similar due to operations that are commutative, but they are semantically different.
- rubiquity 12y ago
  There aren't any callbacks in Elixir. The run time takes care of scheduling for you. The code you write looks synchronous but is executing asynchronously.
  - phamilton 12y ago
    Not only does this make your code easier to read, it also means that the entire ecosystem is available to you rather than a partitioned between sync and async libraries.
  - phamilton 12y ago
    Not only does this make your code easier to read, it also means that the entire ecosystem is available to you rather than a partitioned between sync and async libraries.
marrs 12y ago
Rust is also worth a mention as one to watch.
- rubiquity 12y ago
  Recently Rust removed libgreen from their standard library and went back to native threading so that users can choose and build their own abstractions. So as a language by itself Rust doesn't have a ton of concurrency abstractions but the community appears to be working hard creating concurrency abstractions and I'm sure it's only a matter of time.
  - sanderjd 12y ago
    To expand on this a bit, while they went back to native threading, they didn't ditch any of the type system and library work designed to make message passing convenient and memory safe, which is (arguably) more fundamentally important for concurrency than M:N threading.
    - rubiquity 12y ago
      Great point. I just meant in the context of the languages I cited Rust doesn't offer similar abstractions.
      - sanderjd 12y ago
        Yeah not disagreeing with you at all. It doesn't work the same way "concurrency-focused languages" generally work right now, but it does share the message-passing philosophy with them. Interestingly, I heard a rumor that Go is considering moving to 1:1 threading on Linux, which would align it with Rust's current approach, just without the memory protection capabilities of the type system (though I have no idea whether or not this is true).

pmontra 12y ago

I played a little with Elixir (and Phoenix) months ago and I know the |> operator, which is not exactly what I was looking for in my reply. I'll look again at Elixir and at how it handles callbacks.

tel 12y ago
|> is (not, see below) mere function composition function compose(f, g) { return function inner(x) { return f(g(x)); } } this is not the right kind of composition for something like nested callbacks. For that you need slightly more. Edit: It's actually the "apply" operator which looks like function apply(f) { return function applied(x) { return f(x); } } Apply and compose work together nicely. For instance, in Haskell apply is ($) and compose is (.), so you can build a compositional pipeline and apply it like f . g . h $ x or like f $ g $ h $ x since association goes this way f $ (g $ (h $ x))
- deleted 12y ago
  [deleted]
  - tel 12y ago
    Ah, my bad, I was distracted writing. It's Haskell's ($), not the (.).
    - rubiquity 12y ago
      No worries. I deleted my post before your reply came through because I didn't feel my example was good and I'm struggling to do better this early in the morning :D In a lot of cases compose and |> will be similar due to operations that are commutative, but they are semantically different.
rubiquity 12y ago
There aren't any callbacks in Elixir. The run time takes care of scheduling for you. The code you write looks synchronous but is executing asynchronously.
- phamilton 12y ago
  Not only does this make your code easier to read, it also means that the entire ecosystem is available to you rather than a partitioned between sync and async libraries.
- phamilton 12y ago
  Not only does this make your code easier to read, it also means that the entire ecosystem is available to you rather than a partitioned between sync and async libraries.

marrs 12y ago

Rust is also worth a mention as one to watch.

rubiquity 12y ago
Recently Rust removed libgreen from their standard library and went back to native threading so that users can choose and build their own abstractions. So as a language by itself Rust doesn't have a ton of concurrency abstractions but the community appears to be working hard creating concurrency abstractions and I'm sure it's only a matter of time.
- sanderjd 12y ago
  To expand on this a bit, while they went back to native threading, they didn't ditch any of the type system and library work designed to make message passing convenient and memory safe, which is (arguably) more fundamentally important for concurrency than M:N threading.
  - rubiquity 12y ago
    Great point. I just meant in the context of the languages I cited Rust doesn't offer similar abstractions.
    - sanderjd 12y ago
      Yeah not disagreeing with you at all. It doesn't work the same way "concurrency-focused languages" generally work right now, but it does share the message-passing philosophy with them. Interestingly, I heard a rumor that Go is considering moving to 1:1 threading on Linux, which would align it with Rust's current approach, just without the memory protection capabilities of the type system (though I have no idea whether or not this is true).