I remember this from when @adamgordonbell did an interview with Sean Allen at Wallaroo on CoRecursive. Sean talked about the challenges of figuring out if a bug was in Wallaroo’s code or the Pony compiler itself when they ran into one.
Sean joined us at Microsoft a couple of years ago. Among other things he’s helping us on Verona, which is heavily inspired by Pony (among other things).
It’s all about ecosystem. Tbh I think it’s a shame that rust is bigger than pony, not least because the explicit ownership (“capabilities”) system is much clearer than rust’s implicit model.
And also much much harder to understand (well, at least given the resources on the ponylang website). I think this is the death knell for Pony. Sylvan Clebsch is already working on Verona at MS (and I don’t think he had been contributing much to Pony over the past few years in any case).
at least given the resources on the ponylang website
Pony contributor here. We’re always looking for ways to improve the documentation. I admit that reference capabilities are one of the hardest things to grasp when learning the language, and if you have any ideas on how you’d prefer to see this covered, or have any suggestions on what the tutorial should cover, feel free to reach us on Zulip. We’re always happy to chat!
Maybe Pony’s capability model was too complex. Compare and contrast with E, which has only one form of reference (the object reference) and doesn’t require callers to care about ownership. (Not to imply that E has been widely adopted.)
Tbh I think the capability model isn’t hard to understand, it’s just not familiar. I found it easy to pick up for my one toy project, and preferred the explicit syntax to rust’s implicit one.
That said, I don’t think the website does a wonderful job of selling pony with a few glances. I have no concrete suggestions to share right now.
In my limited experience with both, I found pony much easier to understand. And yes if the two main contributors are working on Verona, I suspect language development will slow.
Java and specifically the JVM is one of the most optimized platforms out there. Several companies implemented many products using these especially for big data use cases. If you cannot make Java + JVM (or Graalvm) work for data science algos + workflows what makes you think that you can make Rust do these things where you have to implement roughly 10x code because there are no libraries that you can build on.
Google, Amazon, Netflix all publish tons of libraries that are designed for high performance computing and large scale data systems that millions of users use every single day. Can you tell the same thing about Rust?
I love the ideas of Rust but I miss roughly 90% of the libraries that I would need to be productive in it. There is also a higher barrier of entry with the concept of lifetimes and the additional complexity these introduce.
Congrats to the team! Hope this unlocks bigger opportunities tech-wise and business-wise. I’m not exactly surprised to hear the news, but I think it is a very good move. The company can now focus on delivering things while maintaining a high level of engineering skill.
Notable because Wallaroo was the biggest (only?) company using Pony in production.
I remember this from when @adamgordonbell did an interview with Sean Allen at Wallaroo on CoRecursive. Sean talked about the challenges of figuring out if a bug was in Wallaroo’s code or the Pony compiler itself when they ran into one.
Sean joined us at Microsoft a couple of years ago. Among other things he’s helping us on Verona, which is heavily inspired by Pony (among other things).
It’s all about ecosystem. Tbh I think it’s a shame that rust is bigger than pony, not least because the explicit ownership (“capabilities”) system is much clearer than rust’s implicit model.
And also much much harder to understand (well, at least given the resources on the ponylang website). I think this is the death knell for Pony. Sylvan Clebsch is already working on Verona at MS (and I don’t think he had been contributing much to Pony over the past few years in any case).
Pony contributor here. We’re always looking for ways to improve the documentation. I admit that reference capabilities are one of the hardest things to grasp when learning the language, and if you have any ideas on how you’d prefer to see this covered, or have any suggestions on what the tutorial should cover, feel free to reach us on Zulip. We’re always happy to chat!
Maybe Pony’s capability model was too complex. Compare and contrast with E, which has only one form of reference (the object reference) and doesn’t require callers to care about ownership. (Not to imply that E has been widely adopted.)
Tbh I think the capability model isn’t hard to understand, it’s just not familiar. I found it easy to pick up for my one toy project, and preferred the explicit syntax to rust’s implicit one.
That said, I don’t think the website does a wonderful job of selling pony with a few glances. I have no concrete suggestions to share right now.
In my limited experience with both, I found pony much easier to understand. And yes if the two main contributors are working on Verona, I suspect language development will slow.
The line when I closed the article. If you cannot make Java work for “modern” data science algorithms and workflows than you are holding it wrong.
Can you elaborate?
Java and specifically the JVM is one of the most optimized platforms out there. Several companies implemented many products using these especially for big data use cases. If you cannot make Java + JVM (or Graalvm) work for data science algos + workflows what makes you think that you can make Rust do these things where you have to implement roughly 10x code because there are no libraries that you can build on.
Google, Amazon, Netflix all publish tons of libraries that are designed for high performance computing and large scale data systems that millions of users use every single day. Can you tell the same thing about Rust?
I love the ideas of Rust but I miss roughly 90% of the libraries that I would need to be productive in it. There is also a higher barrier of entry with the concept of lifetimes and the additional complexity these introduce.
[Comment removed by author]
Congrats to the team! Hope this unlocks bigger opportunities tech-wise and business-wise. I’m not exactly surprised to hear the news, but I think it is a very good move. The company can now focus on delivering things while maintaining a high level of engineering skill.