Pony needs to have something that shows how it's references are more/differently useful in a multi-actor program. I suspect that's a tall order.
Pony needs to have something that shows how it's references are more/differently useful in a multi-actor program. I suspect that's a tall order.
Whether this is has a big impact on running systems remains to be seen, Erlang is very good at quickly collecting data.
Another thing that I would say Pony has that Erlang doesn't is an easy FFI mechanism. You can write NIFs for Erlang, but in my experience writing native code or wrapping C libraries has been much easier in Pony.
(Disclaimer, self-promotion):
It doesn't get easier than this: https://hexdocs.pm/zigler/Zig.html
(I'll be dropping direct c support in there in the next release)
I think the biggest hurdles when writing NIFs are:
* Interacting with Erlang terms from C/Rust/Zig. Admittedly both zigler and rustler help in this regard, by wrapping Erlang terms. Pony is able to expose raw pointers and structs to C, which I've felt easier to work with.
* Dealing with the Beam's preemptive scheduler. This isn't as big of a problem now with dirty schedulers but still a mismatch compared to normal Erlang code. Pony uses a cooperative scheduler everywhere, so you'll already be used to splitting long tasks in different steps by the time you need to use the FFI, which makes the transition easier.
https://www.youtube.com/watch?v=l848TOmI6LI
(this is an old api, there is a new api that makes the modes completely interchangeable: https://www.youtube.com/watch?v=kpRK9BC0-I8)
"There’s plenty to love about Pony, but more than anything else, what we love most is that Pony makes it easy to write fast, safe, efficient, highly concurrent programs."
In Erlang you can write safe highly concurrent programs, but you might struggle with fast and efficient. Of course, how much fast and efficient you need depends on what you are trying to do.