
Why we used Pony to write Wallaroo - spooneybarger
https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-write-wallaroo/
======
munificent

        > 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 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...](https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html)

Not only that, but HotSpot also features a true concurrent collector, which is
a command-line flag away.

~~~
yeukhon
Depends on the sizing I believe. One problem I see in Java-based DB like
Cassandra and Elasticsearch is JVM busy doing garbage collection. The major
collection kicks in all the time. Probably because of bad config and bad data
usage pattern, but it is still a common problem for me. I am all ears for
advice.

~~~
stcredzero
This was an anti-pattern of the runtime model that Java inherited from
Smalltalk. Tuning the GC used to be an arcane art. There was also a lot of
effort put in by programming shops to just reducing GC pressure as an
optimization. This is why I appreciate Golang's pragmatic approach of not
using the GC by avoiding the heap. The main benefit to having GC is to make
initial development faster by reducing the severity and frequency of mistakes.
It's really there as a safety net, not as a foolproof end-all be-all. Use
tools in a way which plays up their strengths.

It's hard to tune a GC to be super-fast. It's easy to profile and find your
biggest memory leaks.

~~~
pjmlp
Yeah, there were plenty of GC languages with value types when Java came about,
I was bit disappointed it only had them for primitive types.

Now they are trying to fit them in without breaking backwards compatibility.

------
jorgeleo
From Pony documentation:

Simplicity

Simplicity can be sacrificed for performance. It is more important for the
interface to be simple than the implementation. The faster the programmer can
get stuff done, the better. It’s ok to make things a bit harder on the
programmer to improve performance, but it’s more important to make things
easier on the programmer than it is to make things easier on the
language/runtime.

This is an excellent design decision. Yes, performance sometimes introduces
complexity, and I have been in teams where the philosophy is: "It does not
matter if it is slower, but any high schooler that knows HTML has to be able
to understand it". The purpose of a program is to satisfy the users, not the
developers or the managers, and if the next developer needs to study a thing
or two before understanding the code that is OK.

Simplicity should be sacrificed for performance.

~~~
stcredzero
_The purpose of a program is to satisfy the users, not the developers or the
managers, and if the next developer needs to study a thing or two before
understanding the code that is OK._

 _Simplicity should be sacrificed for performance._

This is self contradictory. Programmer resources need to be allocated to
pleasing the users. To please users, you need a certain amount of performance.
Performance is not simply and end in itself. Programmer resources can be used
to please users in other ways.

~~~
jorgeleo
I was keeping it PG-13

~~~
stcredzero
HR is happy to know!

------
krylon
I have been looking over to this language every now and then for a long while
now, and this article finally motivated me to actually learn it.

But it seems the documentation is a bit out of date - I cannot even get the
"Hello, world"-program to build correctly, neither on Debian Stretch nor on
openSUSE Tumbleweed.

It is quite frustrating if you try to learn a new language, and when you make
your first step, you step on a nail.

And it is even more frustrating, because Pony looks _very_ interesting, for
the reasons the linked article explains. ):

UPDATE: On Debian, telling the pony compiler to --pic does the trick.

UPDATE2: On suse, installing binutils-gold solved the problem.

UPDATE3: Now we're talking! This language is very, very interesting, indeed!

~~~
aturley
Sorry to hear that. As far as I know the documentation should be up to date,
but it's entirely possibly you've found an issue.

If you like you can hit up the mailing list
([https://groups.io/g/wallaroo](https://groups.io/g/wallaroo)) or the IRC
channel (#ponylang on freednode,
[https://webchat.oftc.net/?channels=wallaroo](https://webchat.oftc.net/?channels=wallaroo))
to see if anybody can help, or if you think you've found a bug you can file an
issue in github
([https://github.com/ponylang/ponyc/issues](https://github.com/ponylang/ponyc/issues)).

UPDATE: I'm glad to hear you got it working!

~~~
krylon
> I'm glad to hear you got it working!

Me, too! This looks pretty exciting!

~~~
spooneybarger
I'm often lurking on IRC if you need help.

------
spooneybarger
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

~~~
ZenoArrow
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 be stronger in certain areas, but it
seems like there's a certain amount of overlap in terms of use cases.

~~~
jtfmumm
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 angles). In the end we thought that Pony
would be better for managing concurrency for our particular use cases, which
we thought mapped well onto the actor model.

~~~
kodablah
> 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?

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

~~~
steveklabnik
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...](http://cityboundsim.com/devblog/my-full-rustfest-
talk-with-networking-live-demo)

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

~~~
Cyph0n
Oh wow, I used to follow Citybound development a while ago when it was still
written in JS. Anselm is an amazingly talented developer and it's great to see
him working with Rust!

------
charlesetc
I used Pony and bindings to opengl to write the (very) start of a graphics
engine. [http://www.charlesetc.com/stars-
game-7.html](http://www.charlesetc.com/stars-game-7.html)

It was surprisingly easy to learn - I found the capabilities system rather
intuitive compared to other methods for safely managing data races. Also the
syntax is really simple and easy to read!

------
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...](http://mail.openjdk.java.net/pipermail/announce/2017-October/000237.html)

" _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_"

~~~
twic
My understanding (which might be out of date now) is that G1 still doesn't
perform as well as CMS, so i'd be more interested in a throughput comparison
to that!

------
eljimmy
I do enjoy reading these "Why we used <x> to build <y>" 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.

~~~
spooneybarger
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.

~~~
eljimmy
Oh wow, well I'm all the more impressed then. It's admirable to try out new
tech and venture into the unknown. Kudos!

------
anonacct37
Pony looks really interesting and I look forward to trying it out. I can't
help but try to reason about how my work language would handle these problems.
Go.

Highly concurrent: check.

Predictable latencies: I think that's a check, the go gc has had alot of
engineering put into it to provide good pause times. There are some edge cases
still.

Data safety: I think go is weakest here in terms of language design. Go does
have go build -race which works pretty well for me, but I can see how some
wouldn't consider it sufficient. It also wouldn't catch single threaded
ownership problems, which can happen.

Easy way to interact with other languages: via CGO and buildmodes you can
trivially call go from other languages. Some don't like that the runtime is
still shipped and started, but the fact remains that you can cffi go functions
from python very easily.

I'll have to check out pony this weekend. I've read up on it a bit but haven't
compiled anything.

~~~
aturley
That's great! We're collecting stories about peoples' first impressions of
Pony ([https://www.ponylang.org/categories/my-first-
pony](https://www.ponylang.org/categories/my-first-pony)), so if you're
interested in contributing to that please get in touch.

I'm an engineer at Wallaroo Labs and I've been learning Go so that I can add a
Go API to Wallaroo. Your analysis looks pretty spot-on based on my experience.

The buildmodes is go definitely make it easy to call Go from other languages.
The trickiest thing I've run into so far with calling Go is that you aren't
supposed to hold on to Go pointers outside of Go code, so I'm having to jump
through some hoops to hold on to objects between calls.

I have an RFC for Pony that I need to finish up that will let you call Pony
function from C. I'm planning on getting around to that soon, as I think it
will help improve our FFI story.

------
Mikeb85
Really good post. Haven't heard much about Pony but seems like a really
interesting language and like something I could use for a particular project.

~~~
spooneybarger
Thanks.

If you ever want to talk Pony, you can find me lurking in the Pony IRC.

------
noncoml
Never heard Pony before. Sounds like a faster, type-safe erlang? Sign me up,
looks awesome!

~~~
rurban
Well, there are several major differences. Erlang actors are lightweight
green-threaded continuations, pony uses lockless threading from a threadpool,
so you use will all your cores. Pony is much faster in CPU (on par with C++
with OpenMP), on IO it's about the same, as IO is mostly about avoiding
waiting.

Pony uses much less memory, there's no beam overhead, the GC protocol is
better, the object overhead is much smaller.

Pony allows zero-copying messages (call-by-ref vs call-by-value), which allows
using fast shared memory threading models (besides copying values). All this
is compile-time safe via the type-system.

The pony stdlib does not support blocking IO, which is probably a good
decision, but you need more overhead adding the wait logic by yourself.

Erlang supports distributed actors, pony not yet. Sylvan and Sebastian are
working on it, but it's not easy. See
[https://www.ponylang.org/media/papers/a_string_of_ponies.pdf](https://www.ponylang.org/media/papers/a_string_of_ponies.pdf)

Erlang supports macros via elixir, pony not.

Pony's capability-bases type system is far too advanced for a regular user.
You need much longer to learn it and come up with compilable designs. This
might be frustrating.

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

~~~
aturley
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.

~~~
spooneybarger
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](https://www.ponylang.org/media/papers/a_string_of_ponies.pdf)

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

~~~
macintux
Thanks. As an Erlang fan, I'm curious how types and networking are going to
overlap.

------
sandGorgon
This is interesting - you wanted actors, you wanted a pleasant programming
language and you wanted to be on the JVM.

I'm curious why you didn't choose Kotlin with Vert.X . Kotlin is a small town
language that won only because it was loved by the community...Nobody "pushed"
it. And it has won - it's now officially supported by Google.

Vertx is a superb actor model framework with first class kotlin support. Its
extremely high performance
([https://www.techempower.com/benchmarks/#section=data-r8&hw=i...](https://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=plaintext))
and is pretty popular
([http://vertx.io/whos_using/](http://vertx.io/whos_using/))

From a forward looking perspective, why Pony ... Especially if it's
development has stalled.

~~~
adamnemecek
There’s also quasar for actors.
[http://docs.paralleluniverse.co/quasar/](http://docs.paralleluniverse.co/quasar/)

------
scardine
For a moment I thought this was about the Pony ORM (Python) - looks like there
are quite a few popular projects named Pony, perhaps we should use "Pony
Language" instead of just "Pony" for the sake of disambiguation.

------
tytytytytytytyt
Are there any statistics that compare this to some similar existing software?

