4 ms·

There still isn't anything there that Erlang doesn't already have, excepting the theoretically-strong reference capabilities...which is what got me watching pon

There still isn't anything there that Erlang doesn't already have, excepting the theoretically-strong reference capabilities...which is what got me watching pony for a couple years. 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.

ergl 6y ago
One thing that reference capabilities allow you to do is pass data between actors without copying. Erlang is very eager in copying almost everything you put in a message to a process (with the expection of big binaries, etc). 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.
- dnautics 6y ago
  > Another thing that I would say Pony has that Erlang doesn't is an easy FFI mechanism (Disclaimer, self-promotion): It doesn't get easier than this: https://hexdocs.pm/zigler/Zig.html https://hexdocs.pm/zigler/Zig.html (I'll be dropping direct c support in there in the next release)
  - ergl 6y ago
    Zigler looks interesting! I've given it a look before, would be very nice if it could support Erlang too, but I imagine Elixir macros are doing a lot of work for you. 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.
    - dnautics 6y ago
      re: preemptive scheduler: https://www.youtube.com/watch?v=l848TOmI6LI 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 https://www.youtube.com/watch?v=kpRK9BC0-I8)
rowland66 6y ago
I think that the first sentence on the why Pony page says it all "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.
speed_spread 6y ago
Totally subjective, but one thing I'd give Pony over Erlang is likable, consensual syntax. Erlang is weird, for no particular reason.

ergl 6y ago

One thing that reference capabilities allow you to do is pass data between actors without copying. Erlang is very eager in copying almost everything you put in a message to a process (with the expection of big binaries, etc). 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.

dnautics 6y ago
> Another thing that I would say Pony has that Erlang doesn't is an easy FFI mechanism (Disclaimer, self-promotion): It doesn't get easier than this: https://hexdocs.pm/zigler/Zig.html https://hexdocs.pm/zigler/Zig.html (I'll be dropping direct c support in there in the next release)
- ergl 6y ago
  Zigler looks interesting! I've given it a look before, would be very nice if it could support Erlang too, but I imagine Elixir macros are doing a lot of work for you. 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.
  - dnautics 6y ago
    re: preemptive scheduler: https://www.youtube.com/watch?v=l848TOmI6LI 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 https://www.youtube.com/watch?v=kpRK9BC0-I8)

rowland66 6y ago

I think that the first sentence on the why Pony page says it all "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.

speed_spread 6y ago

Totally subjective, but one thing I'd give Pony over Erlang is likable, consensual syntax. Erlang is weird, for no particular reason.