[spooneybarger]

Once we made the decision to use Pony for Wallaroo, that has driven a lot of our other choices. The Java and C client libraries are excellent. We had architectural concerns about how the thread pool in the clients would interact with our scheduler threads.

There's a large performance improvement we get by having a single scheduler thread for each CPU. The performance impact of that is very large. Adding another threadpool that competes for CPU usage would be problematic.

Our client is for those high-performance use cases where if we can get parity or close to parity with the C client then we should get much better performance due to those architectural concerns.

That said, we plan on providing a way for folks who are less concerned with performance to use the C client library.

In the end, it was less about "use Pony" and more about "do this in a way that matches with Wallaroo's architecture".

[sidlls]

> In the end, it was less about "use Pony" and more about "do this in a way that matches with Wallaroo's architecture".

This could be accomplished without using Pony, unless you view "Wallaroo's architecture" as being effectively synonymous with "use Pony."

[klibertp]

> This could be accomplished without using Pony

Sure, but why should it be accomplished without Pony? Languages are optimized for use-cases. This means that some languages are good and some are worse at handling particular use-cases. If Pony is the best choice for their use-case, why would you not choose it? Taking all the risks of a new tech into account, of course.