Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we used Pony to write Wallaroo

blog.wallaroolabs.com

Post reply on HN
Print view View original

21–30 of 87 posts

Re: Why we used Pony to write Wallaroo

#21

Post by fasquoika »

spooneybarger wrote: post #6
snappyTertle wrote: post #3

Earlier quoted context omitted.

Why did you choose Pony over something like Erlang or Elixir?

I want to preface this with: I love erlang. We use Elixir for the service that powers metrics display for Wallaroo. When I learned Erlang several years ago, it made me a better programmer. At the time we made the decision, we were worried about Erlang being able to meet the latency and throughput goals we had. I knew a number of people who worked on Riak at Basho and had a few lengthy discussions about Erlang perform…

Is your application CPU bound? Because that's generally where Erlang's performance is lacking. I'm pretty sure you wouldn't run into performance issues in Erlang if you're doing an IO bound task

Re: Why we used Pony to write Wallaroo

#22

Post by doall »

JVM GC is an interesting topic since recently there was a proposal for the ZGC project in the OpenJDK mailing list. http://mail.openjdk.java.net/pipermail/announce/2017-October...

"ZGC has been designed with the following goals in mind:

- Handle multi-terabyte heaps

- GC pause times not exceeding 10ms

- No more than 15% application throughput reduction compared to using G1"

Re: Why we used Pony to write Wallaroo

#23

Post by dljsjr »

munificent wrote: post #16

> The standard JVM garbage collection strategy is “stop the world.” This is quite an over-simplification for what is a fundamental property to think about when designing a performance-oriented system. The default collector in HotSpot does, I think, stop the world when collecting. But it also does multiple small collections between larger major collections. It, by default, optimizes for throughput over latency since m…

The JVM concurrent GC has failure conditions. It does as much as possible concurrently but still occasionally has to stop the world.

Re: Why we used Pony to write Wallaroo

#24

Post by steveklabnik »

spooneybarger wrote: post #19
kodablah wrote: post #14

Earlier quoted context omitted.

> we thought mapped well onto the actor model. Out of curiosity, were there a widely accepted actor lib/approach in Rust (I know there are a few like RobotS and others), would that have affected your decision?

It might have. When we were looking at Rust, it was a topic of conversation.

In general, it's not a space where there's a hyper-mature library, but there are some cool stuff happening today: http://cityboundsim.com/devblog/my-full-rustfest-talk-with-n...

That said, I mean, if you want to go full actors, Pony is a great choice.

Re: Why we used Pony to write Wallaroo

#25

Post by spooneybarger »

fasquoika wrote: post #21
spooneybarger wrote: post #6

Earlier quoted context omitted.

I want to preface this with: I love erlang. We use Elixir for the service that powers metrics display for Wallaroo. When I learned Erlang several years ago, it made me a better programmer. At the time we made the decision, we were worried about Erlang being able to meet the latency and throughput goals we had. I knew a number of people who worked on Riak at Basho and had a few lengthy discussions about Erlang perform…

Is your application CPU bound? Because that's generally where Erlang's performance is lacking. I'm pretty sure you wouldn't run into performance issues in Erlang if you're doing an IO bound task

Wallaroo is a framework for end users writing applications. It is not an application itself. Many of the use cases that people come to us with are very CPU intensive.

Re: Why we used Pony to write Wallaroo

#26

Post by aturley »

ZenoArrow wrote: post #4
spooneybarger wrote: post #2

Author here. Small bit of background. I'm VP of Engineering at Wallaroo Labs and a member of the Pony core team (many folks at Wallaroo Labs are now actively involved in the Pony community). Happy to answer any questions here or if you prefer, via email: sean@wallaroolabs.com

Have been impressed with Pony the few times I've seen it on HN, thanks for your work on Pony and Wallaroo. I'm guessing that tooling for Pony still needs some refinement, but as things are now what would you recommend to someone new to Pony (e.g. editor, package manager, build tools, debugging tools)? Oh and just out of interest, did you evaluate Rust as a language for Wallaroo? I do think Pony has the potential to b…

I'm also an engineer at Wallaroo Labs. A while back I wrote up some information for people who were interested in Pony:

https://gist.github.com/aturley/49b60c98306d90ffc2f981515827...

I've been using Emacs as an editor. We use a combination of make and pony-stable to build projects. For package management we use pony-stable. LLDB is your best bet for debugging, and if you follow the link above there's a link to the pony-lldb project, which is an LLDB extension that makes it easier to work with a few Pony datatypes.

Re: Why we used Pony to write Wallaroo

#27

Post by aturley »

model_m_warrior wrote: post #20
spooneybarger wrote: post #10

Earlier quoted context omitted.

From the Pony side: Biggest strength would be performance. Biggest weakness would be maturity. I think almost every pro/con I can think of can fall into those 2 buckets right now. I'm a big fan of type systems so Pony having one is a big win for me. The maleability of Pony and its immaturity helped us in some ways. We were able to treat it as a runtime for us to help mold and fit to our needs. That wouldn't have been…

Are Ponys classes akin to Erlang modules or does it take a more enterprise-y perspective on OOP?

I'm not sure which features of Erlang modules you're interested in comparing to Pony classes, but I'll take a stab at trying to answer.

Pony classes are defined using a "class" keyword. Classes have properties and functions, where functions are like methods that you would find in a language like Java. Pony supports structural subtyping via interfaces and nominal subtyping via traits, and it disallows multiple inheritance.

I'm not sure how much that helps, but if you have more specific questions I'd be happy to try to answer them. I'm a little rusty on my Erlang, but hopefully it will come back to me.

Re: Why we used Pony to write Wallaroo

#29

Post by aturley »

polskibus wrote: post #28

Does Pony have preemptive scheduling? Does Pony have an equivalent of Distributed Erlang?

Pony does not do preemptive scheduling. Pony actors have behaviors, which can be thought of as methods that handle messages that are sent to the actor; these are the unit of scheduling, and a behavior runs from beginning to end without preemption. Multiple behaviors can run at the same time, but only one behavior per actor can be running at any time.

There is currently no equivalent to Distributed Erlang, but that's something that the creator of the language has been looking into.

Re: Why we used Pony to write Wallaroo

#30

Post by spooneybarger »

aturley wrote: post #29
polskibus wrote: post #28

Does Pony have preemptive scheduling? Does Pony have an equivalent of Distributed Erlang?

Pony does not do preemptive scheduling. Pony actors have behaviors, which can be thought of as methods that handle messages that are sent to the actor; these are the unit of scheduling, and a behavior runs from beginning to end without preemption. Multiple behaviors can run at the same time, but only one behavior per actor can be running at any time. There is currently no equivalent to Distributed Erlang, but that's…

A bit more info. Sebastian Blessing did a thesis on Distributed Pony. You can read it here: https://www.ponylang.org/media/papers/a_string_of_ponies.pdf

At this time, there is no "in the wild" implementation.

Post reply on HN