5 ms·
Pony 0.25.0 released
- qaq 8y agoPony looks interesting anyone using it in prod. ?
- bketelsen 8y agowallaroo labs is using it at scale, that's the only company I'm familiar with.
- pjmlp 8y agoIt 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.
- spooneybarger 8y agoHi, I'm the VP of Engineering at Wallaroo Labs. Pony existed prior to Wallaroo Labs using it, but we have been very instrumental in pushing the language and runtime forward. We've contributed a lot of code to Pony. If you are interested in the early history of Pony you can learn more from Sylvan's post here: https://www.ponylang.io/blog/2017/05/an-early-history-of-pony/ https://www.ponylang.io/blog/2017/05/an-early-history-of-pon...
- pjmlp 8y agoThanks for the heads up and link.
- spooneybarger 8y agoYou're welcome!
- dom96 8y agoAFAIK Sylvan no longer does much Pony work. At least as far as the contribution graphs on GitHub show[1]. 1 - https://github.com/ponylang/ponyc/graphs/contributors https://github.com/ponylang/ponyc/graphs/contributors
- spooneybarger 8y agoThe GitHub contribution graph can be deceptive. The stuff Sylvan is working on these days tends to be deeper things that take a long time to get correct and often is a small amount of code. He definitely isn't churning out tons of code for Pony these days. He is still, however, actively involved. From time to time, big new things from him show up. The latest one has been cooking for several months now and probably won't show up for a few more.
- espeed 8y agoYou're referring to the distributed Actor model?
- spooneybarger 8y agoThere are others, but we at Wallaroo Labs are the only ones that I know of that are talking about it.
- qaq 8y agoAfter digging around doesn't look like there is a usable PG client :(
- spooneybarger 8y agoSeveral 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".
- losvedir 8y agoCongrats 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 8y agoI 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?
- Zalastax 8y agoThey 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 https://learnyousomeerlang.com/supervisors
- vberg 8y agohttps://learnyousomeerlang.com https://learnyousomeerlang.com https://learnyousomeerlang.com/supervisors https://learnyousomeerlang.com/supervisors This book is imho a fantastic read that helped me understand Erlang a lot.
- pdimitar 8y agoIt 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.
- piinbinary 8y agoI'm curious, how many people work on Pony now? What scale of effort does it take to get a language to this point?
- spooneybarger 8y agoThere 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 https://opencollective.com/ponyc
- pjmlp 8y agoCongratulations on the release from my side as well. The more languages the merrier, specially type safe ones for distributed computing.
- spooneybarger 8y agoPony core team member here, Thanks!
- spooneybarger 8y agoO 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 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 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/ https://codesync.global/conferences/code-mesh-2018/tutorial/ Tickets are still available. _edited to fix broken links_
- espeed 8y agoWhat 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?
- spooneybarger 8y agoIdeally 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.
- staticassertion 8y agoI 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.
- spooneybarger 8y agoAll 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/ https://github.com/ponylang/rfcs/ And there are several examples from Wallaroo of that here: https://github.com/WallarooLabs/wallaroo/tree/master/lib/wallaroo_labs/mort https://github.com/WallarooLabs/wallaroo/tree/master/lib/wal...
- staticassertion 8y 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 8y agoLITERALS "hello" // string [1; 2; 3] // array Oh,no.