Pony 0.25.0 released

https://www.ponylang.io/blog/2018/10/0.25.0-released/

by spooneybarger • 8 years ago

95 38 8 years ago

ponylang.io

qaq4• 8 years ago

Pony looks interesting anyone using it in prod. ?

bketelsen• 8 years ago

wallaroo labs is using it at scale, that's the only company I'm familiar with.

pjmlp3• 8 years ago

It should be noted that is where Pony was born.

Additionally, one of the language designers, Sylvan Clebsch, now works at Microsoft Research, so in a way Microsoft is also sponsoring the work on Pony.

spooneybarger14• 8 years ago

There are others, but we at Wallaroo Labs are the only ones that I know of that are talking about it.

qaq4• 8 years ago

After digging around doesn't look like there is a usable PG client :(

spooneybarger14• 8 years ago

Several people started one as a "first Pony project". I'm not aware of anyone completing one.

Pony is very "roll your own libraries" or "wrap a c library" at this point in time. Still pre-1.0.

Lots of chance for folks to contribute and make there mark is the optimistic way I look at it. Pessimistic view is "not many libraries".

losvedir2• 8 years ago

Congrats on the release. As someone whose day job is elixir but whose side project passion right now is rust, a high performance, strongly typed, actor model language like Pony is right up my alley.

My one hang up right now is the other half of the elixir magic: OTP. In particular supervision trees and genservers.

While Pony has an actor model and message passing for concurrency, I wasn't able to find anything OTP-like. What's more, I read some things that it was even impossible to express in the language since there's no mechanism to block and wait for a message. Is this true? Are there any plans down the line for support of this?

weberc2• 8 years ago

I hear a lot of hype about supervisor trees from Erlang folks, but very little description about what they do or why they’re useful. Are they applicable to other languages? Could someone point me to a good resource for someone who doesn’t know Erlang or Elixir?

Zalastax2• 8 years ago

They are very useful if you follow the philosophy of Erlang: let it crash. It's really important to get easy to understand distributed systems. A good introduction: https://learnyousomeerlang.com/supervisors

vberg• 8 years ago

https://learnyousomeerlang.com https://learnyousomeerlang.com/supervisors

This book is imho a fantastic read that helped me understand Erlang a lot.

pdimitar• 8 years ago

It is basically "whatever thing in your system has an external dependency that's not 100% reliable, isolate it in an actor/process that can crash and be safely restarted".

Expand the concept to trees of dependencies and several possible after-crash strategies and you get very resillient apps.

But to fully appreciate it, you have to try it. It sounds pretty generic when advocated for but when you code a bit around that, it gets pretty amazing.

mirceal• 8 years ago

Yes. The concepts are applicable basically everywhere. For example: do you know how systemd restarts your service if it crashes? How about how k8s behaves when your health probes fail? It’s everywhere. Build it to crash fast if it has a problem. Have a higher level entity that monitors it and automatically restarts it/does something when it does crash. Now go meta and have supervisors watching supervisors and controllably crash or restart bigger parts of your system. (This is based on the “crash early”, “keep state consistent”, “have you tried turning it off and on” principles. It’s not new and you’re probably already doing it tona certain degree)

losvedir2• 8 years ago

I really like this description[0]. It's broadly about designing programs, and handling robustness and state, so I imagine it would apply to other languages, although it does mention some erlang specific things.

[0] http://jlouisramblings.blogspot.com/2010/11/on-erlang-state-...

Zalastax2• 8 years ago

As far as I know Pony doesn't yet have a distribution story so supervision might not be priority for the maintainers yet. However, since Pony is an "Active Objects"-language, every actor in Pony is essentially an instance of a genserver - this is what makes it easy to type. Supporting more advanced communication patterns in a strongly typed fashion is rather difficult so for the foreseeable future I believe that a gradual typing approach will be the way to go. Genserver is also very powerful so Pony can likely see good success if they just build in some supervision strategies and make it possible to distribute.

spooneybarger14• 8 years ago

This is true. There is no distributed Pony at this point. It was a high priority early on but when we looked at everything we thought we needed for a 1.0 release, it didn't make the list.

There is Sebastian's thesis which has an approach idea... https://www.ponylang.io/media/papers/a_string_of_ponies.pdf

And Sylvan and I spent a good amount of time discussing how to implement. Then a lot was learned while building Wallaroo over at Wallaroo Labs, we'd certainly lean on stuff from there as well.

If anyone is interesting in working on distributed Pony, we'd be happy to help support you. Come by the IRC or developer mailing list. Let's chat.

But, its not something that anyone is working on right now.

zzzcpan• 8 years ago

I believe you can express those things in Pony via higher order programming. Just like in Rust, although Rust got quite a bit farther on this.

spooneybarger14• 8 years ago

Pony core team member here:

There are no block and wait patterns. That is true.

You need to structure you app as an async one. All communication between actors is async. This has the nice side-effect of making it really hard to write in a deadlock.

There are no plans to and wait at this time. It's not something that folks who are using Pony call for. It is something that folks coming from Erlang/Elixir want to see.

Perhaps they end up dropping off and we end up with confirmation bias that our approach is right. Perhaps we are on to something.

OTP wise, more patterns built into a library would be awesome and anyone who wants to take that one, we'd be happy to help support their effort.

qaq4• 8 years ago

Hehe in the same boat (- Elixir being a day job). Pony looks really interesting.

spooneybarger14• 8 years ago

Stop by the user mailing list or IRC some time!

https://pony.groups.io/g/user

#ponylang on Freenode

piinbinary• 8 years ago

I'm curious, how many people work on Pony now? What scale of effort does it take to get a language to this point?

spooneybarger14• 8 years ago

There was a year of full time development when Casualty existed as a company to support Pony. That got Pony to the starting line. Since then its been a volunteer effort. A lot of people have contributed many great improvements.

If we had lots of paid folks working full time, we'd be further along.

What is the effort? A lot. Not trying to be pithy, but it really is a lot of work.

We'd love to have more volunteers to help out. And for folks who can't contribute time, we've started accepting donations so we can pay for hosting and other costs: https://opencollective.com/ponyc

pjmlp3• 8 years ago

Congratulations on the release from my side as well.

The more languages the merrier, specially type safe ones for distributed computing.

spooneybarger14• 8 years ago

Pony core team member here, Thanks!

spooneybarger14• 8 years ago

O my! Hi Pony core contributor here. Normally when I submit releases to HN, they kind of silently die. I was surprised to come back and see this on the front page. I'll check the comments from time to time and try to answer questions.

While I have your attention:

Pony is an all volunteer project. We could really use your support. We'd love to get more contributors of all stripes. Code, documentation, design work. All of it! Come by the developer mailing list (https://pony.groups.io/g/dev) or #ponylang channel on Freenode and we'll get you started.

And if you can't contribute time, we are now taking donations to help pay for expenses: https://opencollective.com/ponyc

O also, if you are in London in early November. Sylvan and I are doing a Pony tutorial at Code Sync. Tickets are still available. If you click on the tutorial title on this page: https://codesync.global/conferences/code-mesh-2018/tutorial/

Tickets are still available.

_edited to fix broken links_

espeed2• 8 years ago

What lang ecosystem with an interactive REPL do you see as the best fit for pairing with and driving Pony?

I've been dreaming of ways to help bootstrap the Pony lang/lib interop story and build toward a numerical interactive programming environment, being able to combine Pony's native async Actor model and runtime safety guarantees, while also safely being able to hook into to an external ecosystems existing numerical computing, data structure, and GPU/TPU accelerator libs.

I seem to remember someone giving a lang talk a while back where in the Q&A the speaker said integrating with Pony might be a good fit. I was looking into dependent types at the time...it may have been Idris or OCaml, and hooking into the Julia ecosystem would be most interesting, with maybe even Zig acting like low-level LLVM glue code binding all the external C libs together.

In my dream I have it all and the Pony too! All the lang libs are hooked together in a typed-provable way, and when fully connected they combine to form a high-performance, interactive parallel distributed programming environment, and it runs in the browser too. What do you think, is that too much of a DeepDream?

spooneybarger14• 8 years ago

Ideally something with a C-FFI interface and a runtime without a lot of concurrency opinions.

Hooking up Python and Pony is fairly straightforward for example. We've done it at Wallaroo Labs. That's very much "embedded a Python interpreter inside a Pony process" approach. Perhaps you are thinking of something different?

I'm not really sure what you are thinking of. If you sent your ideas to the user mailing list, someone might have some ideas. Something a bit more concrete might help on that front.

staticassertion2• 8 years ago

I haven't touched Pony in a while but it holds a lot of promise.

My paper cuts with Pony were:

a) No assertions/ unhandled exceptions. I believe things like divide by zero or any other case where you want an assertion should exist.

The actor model makes this easy, in theory. Actors are boundaries so just unwind to the actor boundary on exception and have your actor handle the failure from there. Sort of a 'catch all'.

My expectation is this is already how a ton of errors get handled in pony - bubble up to actor, handle. A pony dev can correct me here if that's not the case.

b) The conversions between types needs sugar. I remember some 'recover' statements that were really boilerplatey.

Maybe this is also an issue of compiler errors, if they'd guided me. But sugar around this would be nice as well.

spooneybarger14• 8 years ago

All exceptions have to be handled, but they don't have to be handled at the call site, you can have them propogate back up if you want.

When you say assertion, do you mean, that you want to program to exit? If yes, that's fairly easy to do. We have several different variations of that in the Wallaroo code base.

Speaking as a Pony core member, I'd be open to adding a primitive to exit the program with an error message to the standard library. We have an RFC process for that: https://github.com/ponylang/rfcs/

And there are several examples from Wallaroo of that here:

https://github.com/WallarooLabs/wallaroo/tree/master/lib/wal...

staticassertion2• 8 years ago

All exceptions have to be handled, but they don't have to be handled at the call site, you can have them propogate back up if you want.

Implicitly?

When you say assertion, do you mean, that you want to program to exit?

No, I mean that in some cases I know better than the compiler. For example, in a case where something is T or None, but I know it's T. If T is None, it's a bug - but I don't want my whole program to crash. Ideally it would propagate up to some boundary where there's little enough shared state (the actor boundary) that I can restart my process without having to go through the whole program being restarted.

Otherwise my actor boundary becomes the entire process, and I feel like that sort of defeats the purpose of having extremely cheap, efficient actors.

So definitely not a 'kill the program' but a 'this feature has a bug, wind up the actor and restart it, but no other actors should blow up unless this is a direct dependency of theres'.

Basically the way Erlang does it afaik

I say this as an outsider. What you have may work for you, and maybe it's the right decision. That was just my impression as someone trying to use the language.

Also OOM killing my program.

wener• 8 years ago

LITERALS "hello" // string [1; 2; 3] // array

Oh,no.

Pony 0.25.0 released

Related Stories