undefined | Better HN

story

0 pointspdimitar6y ago0 comments

- Zero-copy mechanics out of the box (borrow checker helps there) and especially in message passing. A lot of the overhead of actor style systems seems to come from copying data and not so much in the actual message queue reading and dispatching.

- Strong static typing. It's 2020 and we should all stop pretending that it doesn't eliminate class of bugs. It does.

- Goes without saying since we mention Erlang but still -- full async support for both CPU and I/O intensive tasks. If one actor goes 100% CPU in an infinite loop everybody else should be unaffected (as much as the hardware allows for that). And if the compiler itself can detect infinite loops and just yell at you for them, even better! (But that borders on sci-fi at the moment.)

- Again related to the above: full non-voluntary preemption. You can insert your own yield points if you like but the runtime will choose if it will respect them or not.

- Obviously, raw speed. I love Elixir and with time I learned how to make its code minimally intrusive for the CPU -- most of my Elixir code basically glues things together, does a quick processing and gets the hell out of the way. 100% of my Elixir code always waits on DB or network requests and I am very proud of that. Still, I'd love such an amazing concept like the actor style parallelism and all the BEAM's goodies in general to come in a package that's 10x or 100x faster and make full use of modern hardware! SIMD / AVX included.

---

There could be more but these are just off the top of my head.

A much shorter answer would likely be: a BEAM VM with minimal memory and I/O and CPU overhead, fully utilising the hardware, and bringing correctness and less bugs with strong static typing.

0 comments

lostcolony6y ago

So short aside - zero copying (locally; it will always be a copy in distributed Erlang) is possible as is with large binaries. But those can (and have) created memory issues themselves (by keeping a large binary around when you're only referencing a small part).

For other types, it's not possible without either adopting Rust's memory model (but that's a huge set of tradeoffs to take on; completely change the language), or giving up the GC benefits of everything being process(stack) allocated, which would entail a whole new set of tradeoffs (and probably not be much faster).

I, personally, don't see that direction as a plus, as such.

Not sure about your third/fourth point; that's Erlang's behavior, no? One actor being busy won't starve others, for CPU or IO. It's pre-emptive; the VM counts reductions and moves on (and not really sure why, given that, you'd want user controlled pre-emption; I never had an issue with one actor starving others, unless calling out to some C code or something, and even that is mitigated with dirty schedulers). Detecting infinite loops could be optimistic, like Dialyzer's typing, I think, but could never be 100% because, yeah, halting problem.

And as above, totally agree on typing, though I personally like Dialyzer's optimistic approach (I just wish type specs were enforced).

But, per the original, I am totally on board with more languages supporting actors...I just was curious what 'a better Erlang' would look like. Some of your bullets seem "a better language (for my use case)", and not really aligned with Erlang's goals.

pdimitarOP6y ago

Yep, you're right. I was kind of rambling. :)

As for the zero-copy stuff, I am not educated enough to claim anything. I have just seen some claims by Rust and liked the idea of the borrowing -- but I know data in the stack is always going to be faster than data in the heap.

I am just wondering if we can't stop with this whole "copy your data" thing all the time.

My comment was a rant + a general musing of a guy who lately mostly codes Elixir; the lack of strong typing is a major pain at times, and sometimes I also wonder if the BEAM VM can't be much faster.

That's all. Apologies if my comments were off-topic.

j / k navigate · click thread line to collapse