Lunatic

Languages and libraries

actor runtime

SHOW HN2020

141points
47comments
#433of 3,028 in 2020
Top 15%of 2020 by points

How HN took it

LovedMost comments that take a side are positive

7 positive, 13 neutral or asking, 1 mixed, 1 critical, out of 22 comments about the project. Thread score +0.24.

Idea: 7 for, 1 against

The thread, comment by comment

Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.

positive neutral or mixed critical about another commenter or something else the maker

What HN said

What people liked

  • Actor-per-wasm-instance design seen as a promising alternative to microservices

    From 3 comments
    • Erlang/OTP inspired actor systems that run Webassembly code are a brilliant (and potentially way superior) alternative to microservice madness. Until now adopting Erlang or Akka…
      the_duke on HN
    • > OTP inspired actor systems that run Webassembly code are a brilliant (and potentially way superior) alternative to microservice madness I very much agree with this. While Actor…
      Snitch-Thursday on HN
    • This is the way forward. A wasm-instance-per-actor architecture enables: - Actor prioritization - Actor pausing - Killing actors at arbitrary points - Actor serialization /…
      nahuel0x on HN
  • Fits well with Erlang/OTP ideas like supervision and isolation

    From 2 comments
    • It's more about fine grained control of errors. WASM/Lunatic could bring many of the benefits of Erlang application design to any wasm friendly language. The creator of Elixir…
      elcritch on HN
    • This is the way forward. A wasm-instance-per-actor architecture enables: - Actor prioritization - Actor pausing - Killing actors at arbitrary points - Actor serialization /…
      nahuel0x on HN

Objections

  • Unclear whether WASM actors remove the need for containers and orchestration

    From 2 comments
    • > All while avoiding the complexities of grpc, building Docker images, Kubernetes, service meshes, "serverless" frameworks, I don't think this will happen to be honest. The WASM…
      justsomeuser on HN
    • It seems I've been in my "ignore all new tech stuff" hole for too long when I open a project link and don't understand most of the value/code. It seems very interesting though, I…
      bird_monster on HN
  • Actor concept and examples were hard to understand from the README

    From 1 comment
    • Thanks, because from the github page I had no idea what "Actor" meant, though I was interested to know more. Reading the code sample did not give me any better idea what was…
      uglycoyote on HN
  • Examples look more like channels (CSP) than mailbox actors

    From 1 comment
    • Fantastic project! The ability to transform serial compiled languages to run atop an async engine is great. The examples, though, remind me more of Go routines and CSP rather…
      elcritch on HN

Requests

  • Shared buffers for passing data between actors without copying

    From 2 comments
    • Nice work! How do you pass complex objects between actors in Lunatic? Do you have to pass a byte array, or is there a more sophisticated approach where you don't have to…
      octopoc on HN
    • Thanks! Currently the heaps and stacks of each actor are completely separate and it's impossible to pass anything without copying it. In the future I would like to add an option…
      bkolobara on HN
  • Binary message formats such as MessagePack or CBOR

    From 1 comment
    • Fantastic project! The ability to transform serial compiled languages to run atop an async engine is great. The examples, though, remind me more of Go routines and CSP rather…
      elcritch on HN
  • Supervision trees and process linking

    From 1 comment
    • Fantastic project! The ability to transform serial compiled languages to run atop an async engine is great. The examples, though, remind me more of Go routines and CSP rather…
      elcritch on HN

Questions

  • Memory overhead per actor compared with Erlang processes

    From 3 comments
    • just a question: how much memory a wasm process in lunatic consumes as minimum?
      nahuel0x on HN
    • > Has the potential to be better than Erlang what's the overhead of a wasm instance?
      dnautics on HN
    • What about Erlang? 4k sound like not that much to me? Imagine a server with 1M concurrent connections, could it need just 4G? (Plus lots of overheard. And without heap)
      cutemonster on HN
  • How it compares with actix and Go channels

    From 2 comments
    • Any comparison with actix(-web)? I know the latest version of actix-web doesn't use the actor model, but actix itself still does.
      cercatrova on HN
    • how does this compare to other "green thread" approaches? Like go channel?
      nsonha on HN

Alternatives named

  • wascc

    From 1 comment
    • Erlang/OTP inspired actor systems that run Webassembly code are a brilliant (and potentially way superior) alternative to microservice madness. Until now adopting Erlang or Akka…
      the_duke on HN
  • Bastion

    From 1 comment
    • See also, Bastion: Highly-available distributed fault-tolerant runtime in Rust https://news.ycombinator.com/item?id=22403713
      ignoramous on HN
  • Erlang/OTP and Elixir

    From 2 comments
    • > single language ecosystem The BEAM supports at least 20 languages.
      macintux on HN
    • All of which are tiny niche languages, except Elixir... I actually think think BEAM gaining the ability to run WASM would be a smart development. It would make using high…
      the_duke on HN
  • Akka

    From 1 comment
    • > Until now adopting Erlang or Akka meant restricting yourself to a single language ecosystem, "Erlang" itself is a single language, but the BEAM/OTP ecosystem isn't usable only…
      dragonwriter on HN
  • Orleans

    From 1 comment

Category, keywords, summaries and labels on this page were made by AI (Thread Reader v2) and not checked by hand. Each point links to the comments it came from.

Add a badge to your READMEShown on HackerShow
[![Shown on HackerShow](https://hackershow.org/badge.svg)](https://hackershow.org/show/25160474)