[deleted]
Why we used Pony to write Wallaroo
11–20 of 87 posts
Re: Why we used Pony to write Wallaroo
#12Author 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
Thanks for the writeup Sean. I've been interested in pony since I read about here on HN a while back.
I have a question on this quote
> The standard JVM garbage collection strategy is “stop the world.” That is, when the JVM needs to reclaim unused memory, it needs to pause all other processing so it can safely garbage collect. These pauses are sometimes measured in seconds. That is going to destroy your tail latencies.
Thats why applications rarely use the default serial collector.
Does your comparison still hold against the CMS and G1 collectors, which do a much a better job at eliminating "stop the world pauses"?
Re: Why we used Pony to write Wallaroo
#13I do enjoy reading these "Why we used to build " posts, as they're usually insightful and provide a glimpse into languages or frameworks I'm not familiar with.
On the flip side, I can't help but wonder how likely they would have been to use Pony had none of their core team members been active in the Pony community.
Re: Why we used Pony to write Wallaroo
#14Earlier quoted context omitted.
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 an engineer at Wallaroo Labs and I've been writing Pony for the last two years. We're using pony_stable (which is the primary package manager at the moment) and make for managing builds. I currently use Sublime 3 as my editor and lldb for debugging. I know that others are using emacs and vim as well. We did consider Rust as there are certainly overlaps in their approaches to safety (though coming from different a…
> 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?
Re: Why we used Pony to write Wallaroo
#15I do enjoy reading these "Why we used to build " posts, as they're usually insightful and provide a glimpse into languages or frameworks I'm not familiar with. On the flip side, I can't help but wonder how likely they would have been to use Pony had none of their core team members been active in the Pony community.
Hope you enjoy this one as well.
We weren't active in the Pony community until we decided to use it for Wallaroo. We felt it was very important to invest in the improvement of Pony. And to do that, we needed to be part of the community.
Pony became our runtime instead of writing one ourself. That doesn't mean we don't have to work on our runtime. It means we are sharing the burden with others.
Re: Why we used Pony to write Wallaroo
#16 > The standard JVM garbage collection strategy is “stop the world.”
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 most applications care more about overall throughput than low latency.
Even with the default, you can tune the maximum latency if you want to sacrifice throughput:
https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...
Not only that, but HotSpot also features a true concurrent collector, which is a command-line flag away.
Re: Why we used Pony to write Wallaroo
#17I do enjoy reading these "Why we used to build " posts, as they're usually insightful and provide a glimpse into languages or frameworks I'm not familiar with. On the flip side, I can't help but wonder how likely they would have been to use Pony had none of their core team members been active in the Pony community.
Interestingly enough, none of us had even written anything significant in Pony when we made the initial tentative decision. After we came to the conclusion that it might be a good fit, we started a test project and a couple of us tried ramping up as fast as we could. It was actually only after we decided it was the right choice that we started to get actively involved in the community.
Re: Why we used Pony to write Wallaroo
#18Author 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
Thanks for the writeup Sean. I've been interested in pony since I read about here on HN a while back. I have a question on this quote > The standard JVM garbage collection strategy is “stop the world.” That is, when the JVM needs to reclaim unused memory, it needs to pause all other processing so it can safely garbage collect. These pauses are sometimes measured in seconds. That is going to destroy your tail latencie…
Thanks.
At my previous job, we used the G1 collector and still had issues with "stop the world" type pauses. G1 does a best effort, but I've had applications that still experience rather long pauses (sometimes measured in seconds, usually hundreds of microseconds).
I haven't used either CMS or G1 heavily since I joined Wallaroo Labs a couple years back so, I don't have first hand experience with either recently.
Azul's Zing JVM does a really nice job of concurrent collection and if you can afford it, is a great way to improve the performance of clustered JVM applications.
Re: Why we used Pony to write Wallaroo
#19Earlier quoted context omitted.
I'm an engineer at Wallaroo Labs and I've been writing Pony for the last two years. We're using pony_stable (which is the primary package manager at the moment) and make for managing builds. I currently use Sublime 3 as my editor and lldb for debugging. I know that others are using emacs and vim as well. We did consider Rust as there are certainly overlaps in their approaches to safety (though coming from different a…
> 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.
Re: Why we used Pony to write Wallaroo
#20Earlier quoted context omitted.
What benefits does Pony have when compared to Erlang?
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?