I want to thank whoever wrote the "Why Not To Use Pony" bullet points. They're quite honest and helpful. Most of these sorts of pages are 110% "rah rah our language is the best for every possible situation, which makes it hard to figure out how to evaluate them. For me personally, this has seemed worst with database products. No matter what the database's actual pros and cons are, their project pages will swear that they are the best at every possible scenario that might involve data.
Fun fact: the person who created Pony, Sylvan Clebsch, has been working on a Microsoft Research project called Verona. From it's README [0]:<p>> <i>Project Verona is a research programming language to explore the concept of concurrent ownership. We are providing a new concurrency model that seamlessly integrates ownership.</i><p>[0] <a href="https://github.com/microsoft/verona/tree/master" rel="nofollow">https://github.com/microsoft/verona/tree/master</a>
A previous conversation: <a href="https://news.ycombinator.com/item?id=17195580" rel="nofollow">https://news.ycombinator.com/item?id=17195580</a><p>On a sort-of-related topic: I've been checking out the Inko programming language, which has some similar goals/ideals as Pony:<p><a href="https://inko-lang.org/" rel="nofollow">https://inko-lang.org/</a><p>Inko lists Erlang and Pony as inspiration for its concurrency model:<p>"Inko uses lightweight processes for concurrency, and its concurrency model is inspired by Erlang and Pony. Processes are isolated from each other and communicate by sending messages. Processes and messages are defined as classes and methods, and the compiler type-checks these to ensure correctness."
I looked into pony a couple of years ago. The type system was <i>gorgeous</i>, but the library ecosystem was very spartan.<p>I hope they get there eventually, I liked the language itself a lot. The learning curve is very steep at first, but I felt that I got over hump after a couple of days playing with it after work.
To me, the interesting thing about Pony is its system of reference capabilities:<p><a href="https://blog.beardhatcode.be/2018/10/pony-capabilities.html" rel="nofollow">https://blog.beardhatcode.be/2018/10/pony-capabilities.html</a><p>They feel a lot like Rust's system of ownership and borrowing, but oriented more towards safe communication in an actor system rather than safe memory management.
It seems to this shares a lot of similarities with Elixir. The biggest thing that stood out to me is Pony appears to be object oriented in approach where as Elixir is function in approach.<p>Aside from Elixir being a bigger community the core goals and purpose seem very similar to me
I used Pony for a small hobby project around 2 years ago. It looked promising and I had a lot of fun using Pony. My biggest gripe was lack of high quality materials to actually learn the language, especially that some concepts were new to me. The community on Zulip, including the main contributors like Sean Allen, were very welcoming and helpful.
>Actors themselves, however, are sequential. That is, each actor will only execute one behaviour at a time. This means all the code in an actor can be written without caring about concurrency: no need for locks or semaphores or anything like that.<p>I mean, sure, it's nice not to have to build this behavior in Java, but it can (and I and many other have) be built in Java, and then there's still Java's massive code base available. I have yet to do it in Rust, but Rust probably has great support for just this.<p>But let's not pretend that this solves all problems related to "concurrency", such as race conditions. In fact it specifically only solves problems where the individual state of an actor is completely independent of any other actor. Sure, that's a lot of places if done right, but in those places, a queue driven FSM in Java does the job.
Was reading docs on actors<p><a href="https://tutorial.ponylang.io/types/actors.html" rel="nofollow">https://tutorial.ponylang.io/types/actors.html</a><p>And I wonder what makes pony actors different to Go's goroutines?
I am interested in Pony due to the compiler maintaining safety while multithreading.<p>I am working on a multithreaded language that has its own interpreter and compiler that codegens targeting it.<p>I use message passing but shared memory mailboxes using a lockfree algorithm.<p>I am trying to solve a multithreading problem which is the sharing of objects between threads. I want shared memory semantics between separate interpreters but avoiding copying.<p>For an interpreter to be aware of an object it needs to have a pointer to it. So I need to update a book keeping for the object to refer to it.
I wish there was some code samples. Just to get an idea of how it looks like. I browsed the website but could not find any.. Except for the playgroud with only one "hello world"
If you're curious about how Pony works, I did a Youtube stream(1) a few years back with Sean Allen from Wallaroo Labs. He patiently walked me through many of Pony's features.<p>1: <a href="https://www.youtube.com/watch?v=s4W4Jb-AAVI" rel="nofollow">https://www.youtube.com/watch?v=s4W4Jb-AAVI</a>
Isn't that language dead? Some startup used a new language because apparently nothing else in the world could fit their use case ( which was simple ) only to move to Rust after chocking discovery that it was a terrible idea from the start.<p><a href="https://web.archive.org/web/20171028135810/https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-write-wallaroo/" rel="nofollow">https://web.archive.org/web/20171028135810/https://blog.wall...</a><p>Then:<p><a href="https://www.wallaroo.ai/blog/wallaroo-move-to-rust" rel="nofollow">https://www.wallaroo.ai/blog/wallaroo-move-to-rust</a>
I wonder if there's somewhere that people can propose a name for things and people can tell them why they might want to use something else - 'Pony' is fairly common slang for 'crap' in London / Southern England.