Erlang/OTP 27 Highlights

Post by neonsunset » Tue, May 21, 2024, 7:44 PM UTC

rdtsc wrote: post #30

neonsunset wrote: post #25

Earlier quoted context omitted.

Tasks are not processes, and that would be a wrong thing to do, and so would be "isolated heaps" given performance requirements faced by .NET - you do want to share memory through concurrent data structures (which e.g. channels are despite what go apologists say), and easily await them when you want to. CSP, while is nice on paper, has the same issues as e.g. partitioning in Kafka, just at a much lower level where it…

> and that would be a wrong thing to do, and so would be "isolated heaps" - you do want to share memory through concurrent data structures (which e.g. channels are despite what go apologists say), and easily await them when you want to. It depends on the context. In some contexts absolutely not. If we share memory, and these tasks start modifying global data or taking locks and then crash, can those tasks be safely r…

Post by weatherlight » Tue, May 21, 2024, 8:22 PM UTC

neonsunset wrote: post #41

rdtsc wrote: post #30

Earlier quoted context omitted.

> and that would be a wrong thing to do, and so would be "isolated heaps" - you do want to share memory through concurrent data structures (which e.g. channels are despite what go apologists say), and easily await them when you want to. It depends on the context. In some contexts absolutely not. If we share memory, and these tasks start modifying global data or taking locks and then crash, can those tasks be safely r…

RE: locks and concurrently modified data-structures It comes down to the kind of lock being used. Scenarios which require strict data sharing handle them as they see fit - for recoverable states the lock can simply be released in a `finally` block. Synchronous/blocking `lock` statement does this automatically. All concurrent containers offered by standard library either do not throw or their exceptions indicate a wro…

Post by solid_fuel » Tue, May 21, 2024, 11:05 PM UTC

neonsunset wrote: post #20

spinningslate wrote: post #13

Earlier quoted context omitted.

this. Erlang's concurrency support is one of those things you can't unsee. Going back to sequential-by-design languages (which is pretty much every other industrial quality language bar go[1]) just feels cumbersome: C/C++/C#/Python/...: "You want concurrency? Sure. We have OS processes, and threads, and this cool new async doohickey. Pick whatever you fancy! Oh, but by the way: you can't use very many processes cos t…

C# tasks are lightweight, and I'd expect for per-task overhead to be significantly lower than that of Erlang's. e.g.: var delay = Task.Delay(3_000); var tasks = Enumerable .Repeat(async () => await delay, 1_000_000) .Select(f => f()); Console.WriteLine("Waiting for 1M tasks..."); await Task.WhenAll(tasks); Console.WriteLine("Finished!"); edit: consider suggesting a comparable example in Erlang before downvoting :)

    #!/usr/bin/env elixir
    
    [process_count | _] = System.argv()
    
    count = String.to_integer(process_count)
    
    IO.puts "spawning #{count} processes"
    
    1..count
    |> Enum.map(fn _c ->
      Task.async(fn -> 
        Process.sleep(3_000) 
      end)
    end)
    |> Task.await_many()

    » time elixir --erl "+P 1000001" process_demo.exs 1000000
    spawning 1000000 processes
    
    ________________________________________________________
    Executed in    6.85 secs    fish           external
       usr time   11.79 secs   60.00 micros   11.79 secs
       sys time   15.81 secs  714.00 micros   15.81 secs

Post by asabil » Wed, May 22, 2024, 7:53 AM UTC

neonsunset wrote: post #39

asabil wrote: post #36

Earlier quoted context omitted.

GC determinism is one of the things you get. Another one is non cooperative asynchronous termination.

Pretty much all efficient GC implementations are inherently non-deterministic, even if predictable. How can this improve predictability of GC impact?

Post by neonsunset » Wed, May 22, 2024, 2:46 PM UTC

solid_fuel wrote: post #45

neonsunset wrote: post #20

Earlier quoted context omitted.

C# tasks are lightweight, and I'd expect for per-task overhead to be significantly lower than that of Erlang's. e.g.: var delay = Task.Delay(3_000); var tasks = Enumerable .Repeat(async () => await delay, 1_000_000) .Select(f => f()); Console.WriteLine("Waiting for 1M tasks..."); await Task.WhenAll(tasks); Console.WriteLine("Finished!"); edit: consider suggesting a comparable example in Erlang before downvoting :)

I'm not really sure what this proves, since there aren't really good reasons for spawning 1 million processes that do nothing except sleeping. A more convincing demonstration would be spawning 1 million state machines that each maintain their own state and process messages or otherwise do useful work. But examples of that on the BEAM have been around for years. So, in interest of matching this code I wrote an example…

    var count = int.Parse(args[0]);

    Console.WriteLine($"spawning {count} tasks");

    var tasks = Enumerable
        .Range(0, count)
        .Select(async _ => await Task.Delay(3_000));

    await Task.WhenAll(tasks);

    mkdir CSTasks && cd CSTasks
    dotnet new console --aot
    echo '{snippet above}' > Program.cs
    dotnet publish -o .
    time ./CSTasks