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

71–80 of 87 posts

Re: Why we used Pony to write Wallaroo

#71

Post by 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...) and is pretty popular (http://vertx.io/whos_using/)

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

Re: Why we used Pony to write Wallaroo

#72

Post by adamnemecek »

sandGorgon wrote: post #71

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 extreme…

There’s also quasar for actors. http://docs.paralleluniverse.co/quasar/

Re: Why we used Pony to write Wallaroo

#73

Post by pjmlp »

stcredzero wrote: post #69
yeukhon wrote: post #64

Earlier quoted context omitted.

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.

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 an…

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.

Re: Why we used Pony to write Wallaroo

#74

Post by polskibus »

switchbak wrote: post #58
polskibus wrote: post #39

Earlier quoted context omitted.

Preemptive scheduling is one of the advantages of Erlang over other actor implementations like Akka. Please consider implementing it!

Admittedly I'm not familiar with Erlang's preemptive model, but I'll ask anyway :) When using async based APIs with something like Akka, passing around futures and such, and leveraging multiple actors in thread pools, doesn't that get you to approximately the same place as Erlang? Sure, the JVM isn't doing the preempting, but the OS is. Is the main downside per-thread resource consumption and context scheduling overh…

As far as I understand, Erlang scheduling is more aware of actor model resource usage patterns and NIFs than a combination of a JVM (or another runtime) + OS. It makes it more reliable and performant in the end (in places where scheduling matters).

Re: Why we used Pony to write Wallaroo

#75

Post by dotdi »

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…

This.

I specifically came here to write something very similar. Thank you. Call me a JVM fanboy, but when I see such comments, I tend to believe the author didn't want to spend time genuinely understanding the JVM and doing thorough testing.

I don't want to discard per-actor heap memory in Pony. That's pretty slick. Pony has been on my radar for a while because it does a lot of things well.

Re: Why we used Pony to write Wallaroo

#76

Post by MrBuddyCasino »

Cyph0n wrote: post #60
MrBuddyCasino wrote: post #54

Earlier quoted context omitted.

I‘ve worked with Scala/Akka, and while I like the actors model, some things turn me off about the stack, mostly the language. After reading the Pony guiding principles, I was delighted. This looks like an implementation where the ecosystem complexities don’t get in my way of „getting things done“!

May I ask what turned you off about Scala?

Its the JVMs C++. Because it is both OO and functional, it has too many concepts and some have a poorly thought out mental load/usefulness balance. Implicits is just the most notorious offender. For me it was a huge productivity killer, because proficiency takes a long time and the tools are poor (IDE support, compile times & build tools).

I like my languages opinionated, in as "there should be one way to do it". Python, C, Go, Clojure, maybe Rust. Designed to be a tool for their inventors set of problems, not a vehicle to implement research papers. Fast turnaround/feedback cycles.

Re: Why we used Pony to write Wallaroo

#77

Post by vanderZwan »

snappyTertle wrote: post #3
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

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

Just so you know, some of the earliest videos you can find about Pony are at Erlang conferences, probably because it is cited as a big influence (actor language). The two communities seem to be getting along very well.

Re: Why we used Pony to write Wallaroo

#78

Post by jtfmumm »

sandGorgon wrote: post #71

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 extreme…

We decided for a number of reasons that the JVM wasn't the right fit for us, so we didn't end up considering Kotlin.

Pony is being actively developed, and has been as long as we've been using it. Since some of our team are now core contributors to the language, we've also invested in improving Pony, which has proven to be very useful to us.

Re: Why we used Pony to write Wallaroo

#79

Post by rurban »

noncoml wrote: post #31

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

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

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.

Re: Why we used Pony to write Wallaroo

#80

Post by jorgeleo »

stcredzero wrote: post #70
jorgeleo wrote: post #43

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. Thi…

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 i…

I was keeping it PG-13
Post reply on HN