Erlang can do these very well. Is there anything LF better? Just asking for opinion.

Haven880 • today at 10:20 AM • 2 replies • view on HN

Replies

The main thing this seems to provide is determinism. Where Erlang, to stick to your question, can be non-deterministic (without taking special care). I'm reading the dissertation this work is based on to see how it guarantees determinism, so at present I'm just taking their word for it.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2020/Archive/EE...

In chapter 1 they provide an example of (using Erlang syntax, completely untested so probably needs some massaging to run as I'm rusty on Erlang) this scenario, which would be deterministic in Erlang:

  counter() -> counter(1).
  counter(N) ->
    receive
      dbl -> counter(N*2);
      {inc, Arg} ->
        N1 = N1 + Arg,
        io:format("~w~n", [N1]),
        counter(N1)
    end.

  main() ->
    P = spawn(counter),
    P ! dbl,
    P ! {inc, 1}.

Because messages sent from one process to another are guaranteed to be made available in that same order, this is deterministic. They introduce a motivating example on page 5 (21 in the PDF) where a relay is introduced.

  relay() ->
    receive
      P -> P ! dbl
    end,
    relay(P).

  main_with_relay() ->
    P = spawn(counter),
    R = spawn(relay),
    R ! P,    % <- trouble starts here
    P ! {inc, 1}.

This may give the same result as the first example when run on the same node, but the guarantee is lost, it might not happen in the same order as the first version. For an example where it will likely give a different result, consider if counter were a local process to main (on the same node) while relay were a remote process (on a separate node) with high latency, it's likely that the network delay would result in {inc, 1} arriving before dbl.

The work in LF lets you write this (don't ask me how, still reading) so that the relay would be logically instantaneous even if physically it wasn't, consequently the dbl message would arrive "first" by logical time and the counter would process things as in the original Erlang code.

Of course, you can make the Erlang relay behavior deterministic, but you have to add extra code to achieve it. LF apparently gives you a simpler way to get the desired determinism without having to write the extra code yourself, it's baked into its semantics.

➕ show 1 reply

scythmic_waves • today at 3:27 PM

This project lacks a compelling sales pitch. It mentions that LF is better than actors but I also don't see no reason to believe that.

It does offer a deep dive into what reactors are but why would I bother to learn? If OP reads my comment, that's what I would add to this landing page. Show me why the alternatives mentioned are inferior.

alt Hacker News

Replies