Never heard Pony before. Sounds like a faster, type-safe erlang? Sign me up, looks awesome!
Why we used Pony to write Wallaroo
31–40 of 87 posts
Re: Why we used Pony to write Wallaroo
#32Never heard Pony before. Sounds like a faster, type-safe erlang? Sign me up, looks awesome!
That's the general idea. But, Erlang has a wee bit of a head start.
Re: Why we used Pony to write Wallaroo
#33I 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!
Re: Why we used Pony to write Wallaroo
#34Earlier 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…
> Biggest weakness would be maturity.
Has there been any progress towards a preemptive scheduler? Otherwise, I'd think that's the most obvious weakness.
Re: Why we used Pony to write Wallaroo
#35Pony 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.
Re: Why we used Pony to write Wallaroo
#36Earlier quoted context omitted.
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…
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 At this time, there is no "in the wild" implementation.
Thanks. As an Erlang fan, I'm curious how types and networking are going to overlap.
Re: Why we used Pony to write Wallaroo
#37I 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/ponyc/issues).
UPDATE: I'm glad to hear you got it working!
Re: Why we used Pony to write Wallaroo
#38Earlier quoted context omitted.
It might have. When we were looking at Rust, it was a topic of conversation.
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... That said, I mean, if you want to go full actors, Pony is a great choice.
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!
Re: Why we used Pony to write Wallaroo
#39Does Pony have preemptive scheduling? Does Pony have an equivalent of Distributed Erlang?
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…
Preemptive scheduling is one of the advantages of Erlang over other actor implementations like Akka. Please consider implementing it!
Re: Why we used Pony to write Wallaroo
#40Pony 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…
That's great! We're collecting stories about peoples' first impressions of 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.