5 ms·

Does anyone have a short, paragraph or two summary of why you might choose Pony over Erlang/Elixir or Akka with Java or C#?

by cwyers 10y ago

spooneybarger 10y ago
Prerequisite: You have the stomach for a relatively immature language Re Erlang/Elixir the number 1 selling point would be if you need performance that you can't get from Erlang/Elixir. Re Akka on the JVM, the number 1 selling point would be you want predictable latencies from your GC that you can't get from the JVM. Along with those, you get a type system that enforces data-race safety which now that I am using Pony daily, is the #1 selling point for me.
- mafribe 10y ago
  Where does Pony's performance vis-a-vis Erlang/BEAM come from? The absence of dynamic typing? Better scheduler?
  - spooneybarger 10y ago
    There are a number of areas: Most message passing on BEAM is done via copying. Pony can share the memory directly because the compiler enforces safe sharing via deny capabilities. You can only send 3 basic types to another actor: iso -> mutable memory that you have the sole reference to val -> immutable reference. you can read but you can't write tag -> an opaque reference. good for sending messages to actors or doing identity comparisons The type system certainly helps as well. It allows us to give LLVM hints on optimizations it can make. The type system also helps because we can do "dangerous but fast" things safely because we can prove they are safe in this instance. Compiling to native code via LLVM is another area for performance wins. That said, Erlang has over 20 years of rock solid production usage behind it and that unto itself is a quite a selling point. At this point in time, I'd suggest Pony to Erlang/Elixir users if they need more performance, otherwise, I'd stick with Erlang for now.
    - steveklabnik 10y ago
      > The type system also helps because we can do "dangerous but fast" > things safely because we can prove they are safe in this instance. This is an area of some static type systems that I'm really interested in; it feels counter-intuitive at first. You'd imagine that flexibility is what lets you do the things you need to do to go fast, but in many cases, restrictions actually are. Cool stuff.
      - infinite8s 10y ago
        Yeah, see the lack of aliasing in fortran as an example of a restriction that allows the compiler to generate optimal code.
      - mintplant 10y ago
        Absolutely. In modern JavaScript engines, for example, dynamic typing makes something as basic as |foo.bar = 7| extremely complicated internally. In SpiderMonkey, |foo| could be a native object with |bar| in some varying location on a fixed or dynamic slot, or it could involve a proxy, a setter, unboxed or unboxed expando object, DOM or cross-compartment wrapper... To make the whole thing efficient, a particular property access could go through engine code, specialized JIT-generated native code after enough type information has been collected, or one of three inline cache systems, which generate multiple native code stubs |switch|ed on checks based on previous (slower) executions. A given get or set could even pass through more than one of the above, if too many checks fail and bailouts are required. And |bar| could be located directly on |foo| or on some object in |foo|'s prototype chain, requiring on-the-fly verification of additional invariants to ensure correctness. Static typing would mean the engine can know for sure what |foo| is and where to look for |bar|, allowing faster, guaranteed-correct code to be emitted ahead of time. Dynamic typing makes it harder to offer speed, correctness, security, and good memory usage all at once.
      - vanderZwan 10y ago
        > You'd imagine that flexibility is what lets you do the things you need to do to go fast, but in many cases, restrictions actually are. Aren't you mixing up flexibility for the programmer with flexibility for the compiler? The more restrictions the programmer has, the more flexibility the compiler has to change instructions and still produce the same results.
  - rurban 10y ago
    pony is compiled to native code, and to highly optimized code. beam is just interpreted. even if most of the time the code has to wait, it has to wait much less. that's why pony can beat C++ with OpenMP in comparable tasks. It's garbage collector is superior, having to do much less work than in beam. The data workload for each thread is much smaller. objects are tiny, messages are mostly referenced (shared) and not copied. erlang does more. it already supports distributed actors, so there's a little overhead also.
    - PeCaN 10y ago
      Curious, how is Pony's GC superior to Erlang? Erlang's GC is already pretty quick (since the heaps are very small).
      - doublec 10y ago
        There's a thread here from a previous discussion: https://news.ycombinator.com/item?id=9483071 https://news.ycombinator.com/item?id=9483071 One nice thing about the Pony GC is it can GC actors that are waiting for messages but will never receive one. In some other languages I've used I end up with processes idling in a receive on channel living forever but never able to exit because nothing is going to put a message in the channel.
karma_vaccum123 10y ago
Pony represents new thinking for concurrent design. I would not use Pony in production yet, but it is worth a look if you want to explore novel approaches for concurrency.
pjmlp 10y ago
Pony is targeted to the Fintech market, the same that is driving JVM vendors to improve its story regarding value types and related improvements. But it is still quite on the early days.
- spooneybarger 10y ago
  We are not targeting Pony to Fintech. There's a nice fit there but we aren't sitting down and thinking, "how can we make Pony good for Fintech".
  - pjmlp 10y ago
    That is what I got from here: https://www.infoq.com/presentations/pony https://www.infoq.com/presentations/pony https://www.infoq.com/news/2016/03/pony-fintech https://www.infoq.com/news/2016/03/pony-fintech
    - spooneybarger 10y ago
      There's a nice fit between Fintech concerns and Pony, that said, Pony is quite usable across a variety of domains. That said, perhaps we gave that impression. Hopefully folks outside of Fintech will be interested in Pony as well.

Does anyone have a short, paragraph or two summary of why you might choose Pony over Erlang/Elixir or Akka with Java or C#?

by cwyers 10y ago

Does anyone have a short, paragraph or two summary of why you might choose Pony over Erlang/Elixir or Akka with Java or C#?

spooneybarger 10y ago

Prerequisite: You have the stomach for a relatively immature language Re Erlang/Elixir the number 1 selling point would be if you need performance that you can't get from Erlang/Elixir. Re Akka on the JVM, the number 1 selling point would be you want predictable latencies from your GC that you can't get from the JVM. Along with those, you get a type system that enforces data-race safety which now that I am using Pony daily, is the #1 selling point for me.

mafribe 10y ago
Where does Pony's performance vis-a-vis Erlang/BEAM come from? The absence of dynamic typing? Better scheduler?
- spooneybarger 10y ago
  There are a number of areas: Most message passing on BEAM is done via copying. Pony can share the memory directly because the compiler enforces safe sharing via deny capabilities. You can only send 3 basic types to another actor: iso -> mutable memory that you have the sole reference to val -> immutable reference. you can read but you can't write tag -> an opaque reference. good for sending messages to actors or doing identity comparisons The type system certainly helps as well. It allows us to give LLVM hints on optimizations it can make. The type system also helps because we can do "dangerous but fast" things safely because we can prove they are safe in this instance. Compiling to native code via LLVM is another area for performance wins. That said, Erlang has over 20 years of rock solid production usage behind it and that unto itself is a quite a selling point. At this point in time, I'd suggest Pony to Erlang/Elixir users if they need more performance, otherwise, I'd stick with Erlang for now.
  - steveklabnik 10y ago
    > The type system also helps because we can do "dangerous but fast" > things safely because we can prove they are safe in this instance. This is an area of some static type systems that I'm really interested in; it feels counter-intuitive at first. You'd imagine that flexibility is what lets you do the things you need to do to go fast, but in many cases, restrictions actually are. Cool stuff.
    - infinite8s 10y ago
      Yeah, see the lack of aliasing in fortran as an example of a restriction that allows the compiler to generate optimal code.
    - mintplant 10y ago
      Absolutely. In modern JavaScript engines, for example, dynamic typing makes something as basic as |foo.bar = 7| extremely complicated internally. In SpiderMonkey, |foo| could be a native object with |bar| in some varying location on a fixed or dynamic slot, or it could involve a proxy, a setter, unboxed or unboxed expando object, DOM or cross-compartment wrapper... To make the whole thing efficient, a particular property access could go through engine code, specialized JIT-generated native code after enough type information has been collected, or one of three inline cache systems, which generate multiple native code stubs |switch|ed on checks based on previous (slower) executions. A given get or set could even pass through more than one of the above, if too many checks fail and bailouts are required. And |bar| could be located directly on |foo| or on some object in |foo|'s prototype chain, requiring on-the-fly verification of additional invariants to ensure correctness. Static typing would mean the engine can know for sure what |foo| is and where to look for |bar|, allowing faster, guaranteed-correct code to be emitted ahead of time. Dynamic typing makes it harder to offer speed, correctness, security, and good memory usage all at once.
    - vanderZwan 10y ago
      > You'd imagine that flexibility is what lets you do the things you need to do to go fast, but in many cases, restrictions actually are. Aren't you mixing up flexibility for the programmer with flexibility for the compiler? The more restrictions the programmer has, the more flexibility the compiler has to change instructions and still produce the same results.
- rurban 10y ago
  pony is compiled to native code, and to highly optimized code. beam is just interpreted. even if most of the time the code has to wait, it has to wait much less. that's why pony can beat C++ with OpenMP in comparable tasks. It's garbage collector is superior, having to do much less work than in beam. The data workload for each thread is much smaller. objects are tiny, messages are mostly referenced (shared) and not copied. erlang does more. it already supports distributed actors, so there's a little overhead also.
  - PeCaN 10y ago
    Curious, how is Pony's GC superior to Erlang? Erlang's GC is already pretty quick (since the heaps are very small).
    - doublec 10y ago
      There's a thread here from a previous discussion: https://news.ycombinator.com/item?id=9483071 https://news.ycombinator.com/item?id=9483071 One nice thing about the Pony GC is it can GC actors that are waiting for messages but will never receive one. In some other languages I've used I end up with processes idling in a receive on channel living forever but never able to exit because nothing is going to put a message in the channel.

karma_vaccum123 10y ago

Pony represents new thinking for concurrent design. I would not use Pony in production yet, but it is worth a look if you want to explore novel approaches for concurrency.

pjmlp 10y ago

Pony is targeted to the Fintech market, the same that is driving JVM vendors to improve its story regarding value types and related improvements. But it is still quite on the early days.

spooneybarger 10y ago
We are not targeting Pony to Fintech. There's a nice fit there but we aren't sitting down and thinking, "how can we make Pony good for Fintech".
- pjmlp 10y ago
  That is what I got from here: https://www.infoq.com/presentations/pony https://www.infoq.com/presentations/pony https://www.infoq.com/news/2016/03/pony-fintech https://www.infoq.com/news/2016/03/pony-fintech
  - spooneybarger 10y ago
    There's a nice fit between Fintech concerns and Pony, that said, Pony is quite usable across a variety of domains. That said, perhaps we gave that impression. Hopefully folks outside of Fintech will be interested in Pony as well.