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.
Why we used Pony to write Wallaroo
41–50 of 87 posts
Re: Why we used Pony to write Wallaroo
#42Author 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
How do you ingest data with Wallaroo? I see a mention of "...say TCP" and in the github word count there is mention of a (data)source framed-message-protocol but nothing that describes it in the (https://github.com/WallarooLabs/wallaroo/blob/0.2.0/book/cor...) link.
Dropping Python into the mix for a high throughput processing pipeline seems counterproductive. Why isn't there a tutorial in a more strict language like Go or C++, since someone pursuing this kind of high-throughput framework that can't benefit from wider parallelism, will 100% want that performance guarantee?
Re: Why we used Pony to write Wallaroo
#43From 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.
Re: Why we used Pony to write Wallaroo
#44I 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…
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 ) or the IRC channel (#ponylang on freednode, 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/p…
> I'm glad to hear you got it working!
Me, too! This looks pretty exciting!
Re: Why we used Pony to write Wallaroo
#45I used Pony and bindings to opengl to write the (very) start of a graphics engine. 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!
Re: Why we used Pony to write Wallaroo
#46Earlier quoted context omitted.
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 ) or the IRC channel (#ponylang on freednode, 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/p…
> I'm glad to hear you got it working! Me, too! This looks pretty exciting!
I'm often lurking on IRC if you need help.
Re: Why we used Pony to write Wallaroo
#47Earlier 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?
Howdy. Erlang's modules are involved in code namespace for the compiler & runtime (i.e., the 'M' of the 'MFA' triple of Module + Function name + Arity that names a function) as well being the unit/scope/bound for hot code loading (i.e., you must load or unload an entire module at a time).
I've worked in Erlang-land far longer than I've lived in any OOP-land, so I'm not sure what you mean by enterprise'y OOP. Coincidentally, Pony's rules for "Packages" are something I just smacked my ignorant head against a few hours ago. The subsections of https://tutorial.ponylang.org/packages/ in the tutorial can probably answer at least some of your question: specifically "Package System" and "Use Statement".
Re: Why we used Pony to write Wallaroo
#48Earlier 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…
> Biggest weakness would be maturity. Has there been any progress towards a preemptive scheduler? Otherwise, I'd think that's the most obvious weakness.
There's pros and cons to preemptive and cooperative scheduling policies. I wouldn't be comfortable labelling either as weakness. It really depends on context.
I've heard rumor of someone working on a preemptive scheduler. The current cooperative one is about to have runtime backpressure added to it which is going to be a really nice scheduling win.
Re: Why we used Pony to write Wallaroo
#49I used Pony and bindings to opengl to write the (very) start of a graphics engine. 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!
[deleted]
Re: Why we used Pony to write Wallaroo
#50Earlier quoted context omitted.
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.
Thanks, that makes sense