9 ms·

The Pony Programming Language

196 points by curling_grad 4y ago

wiremine 4y ago
A previous conversation: https://news.ycombinator.com/item?id=17195580 https://news.ycombinator.com/item?id=17195580 On a sort-of-related topic: I've been checking out the Inko programming language, which has some similar goals/ideals as Pony: https://inko-lang.org/ https://inko-lang.org/ Inko lists Erlang and Pony as inspiration for its concurrency model: "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."
- ch4s3 4y ago
  Building a typed, OO language inspired by Erlang on top of Rust seems like a bit of a platypus if that makes sense. I'm really wondering who is using this other than former Pony users.
- treuks 4y ago
  looks cool to me, really wish they had standard library documentation and better editor support, but it's obviously waaay too young for this to be critical. i can see this maturing into a really nice web-backend language though. typed elixir with rust error handling and algebraic types? sign me up
- 0xTadash1 4y ago
  I always wonder when I come across a text like this what a lightweight process is. Is it different from just a thread? Or is it a type of lightweight/virtual thread?
  - aidenn0 4y ago
    There are multiple definitions of LWPs. I think the way it is being used here is a user-scheduled thread. In the old Unix days it meant "kernel thread"
  - jeremyjh 4y ago
    Yes it is a lightweight thread or “green” thread. Coroutines that are scheduled by the languages runtime across a pool of multiple OS threads and are implemented using an event loop that resumes a coroutine whenever the IO it was blocked on is available, sort of like if in Node all the async/await keywords were implemented for you automatically on every IO OP. Some languages (Erlang, Go, Haskell) have green threads with preemptive scheduling on CPU loops (though Go only preempts at function boundaries IIRC) but Pony does not, actors have to cooperate.
    - Matthias247 4y ago
      > though Go only preempts at function boundaries IIRC I think this was improved with more recent Go versions and now it is really preemptive
Thaxll 4y ago
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. https://web.archive.org/web/20171028135810/https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-write-wallaroo/ https://web.archive.org/web/20171028135810/https://blog.wall... Then: https://www.wallaroo.ai/blog/wallaroo-move-to-rust https://www.wallaroo.ai/blog/wallaroo-move-to-rust
- wiremine 4y ago
  I'm not sure, but the last commit on the github repo was 12 hours ago.
- Davidbrcz 4y ago
  Last time I checked, it was language backed by a research group.
- Mikeb85 4y ago
  Development has definitely slowed and the creator has moved on to other things. I've played around with it and my main takeaway is that it's easier to create an actor system in an existing language than to create an entire ecosystem around Pony.
- jcarr25- 4y ago
  They used Pony as a good fit for their first project. They later made a second project with better market fit, and for that project Rust was a better fit.
- dang 4y ago
  Can you please make your substantive points without breaking the site guidelines? They include: "Don't be snarky." "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
krylon 4y ago
I looked into pony a couple of years ago. The type system was gorgeous, but the library ecosystem was very spartan. 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.
pard68 4y ago
Minor nit, it takes far too many clicks to see what the language looks like.
- qorrect 4y ago
  Came here to say this also, couldn't find any code samples after 5 clicks and gave up.
  - TruthWillHurt 4y ago
    I went much deeper than 5 clicks, into tutorial, about, getting started - no code. Only thing remotely like the syntax is the cheat sheet.
- aidenn0 4y ago
  I didn't take me too many clicks; from ponlyang.io I cliked "try it in your browser" and it dumped me to a hello world. Alternatively there is an examples folder on the linked GH page.
- Pet_Ant 4y ago
  https://tutorial.ponylang.io/getting-started/how-it-works.html#compiling-your-program https://tutorial.ponylang.io/getting-started/how-it-works.ht...
jevgeni 4y ago
is it just me, or is it super difficult to find code samples - even in the tutorial?
- warpspin 4y ago
  No, it's not just you. Huge mistake, in my opinion. If I see a page for a new programming language, I want to be one click away from code samples.
- augustk 4y ago
  Indeed, like vapourware almost.
- kulibali 4y ago
  The fourth link on the home page is "Example Pony Applications"
- Pet_Ant 4y ago
  https://tutorial.ponylang.io/getting-started/how-it-works.html#compiling-your-program https://tutorial.ponylang.io/getting-started/how-it-works.ht...
  - jevgeni 4y ago
    Thank you! I realized that the left-side menu is actually a TOC, which for some reason I didn't register at first.
nikivi 4y ago
Was reading docs on actors https://tutorial.ponylang.io/types/actors.html https://tutorial.ponylang.io/types/actors.html And I wonder what makes pony actors different to Go's goroutines?
- insanitybit 4y ago
  Pony actors: 1. Have a typed, nominal interface (called behaviors) 2. Have state Those are probably the main differences, just with regards to actors.
- jerf 4y ago
  In general, your latter question is better asked as "what makes actors different from threads?", because in practice a goroutine is just a thread. (What makes Go different from C++ in the 1990s is more community practice around what concurrency patterns are most commonly used, rather than technical differences in the language. Technically Go is just a mutable threaded language; for this purpose details about how the threading is accomplished are not that important.) In general the big difference with actors is that they are isolated from each other in some manner that means they can't just reach in to some other actor's memory space and manipulate the memory concurrently. Languages are starting to blur the lines here. Rust's lifetime annotation is not on its own sufficient to call Rust an "actor-based language" but the fact that they also prevent threads/async processes from just reaching in and manipulating other threads/async process's value unexpectedly means you've certainly taken a big step in that direction. And while Go provides no language-level technical support for actors, I still have a lot of things that are de facto actors in Go that uses scoping and export rules to confine the ability of other goroutines to interfere with a particular "actor"'s values, combined with an API that enforces message-based communication even though it works through what look like normal methods. This is not enforced at all technically by the language but it works better with community code than it does in older thread-based languages because the Go community is more recent and you can generally rely on libraries using somewhat more modern concurrency primitives, like providing services based on actors or actor-like objects. There are some things in programming where if you mostly follow some practice, you get most of the benefit. There are other things in programming where the benefit only kicks in if you do it almost entirely correctly; an example of the latter is Haskell's rigid insistence on functional programming and immutability, I'm not convinced that it's worth doing 90% of that but when you fully commit and build the language around it, there is an interesting spike in capability at the end. After programming in this space for well over a decade now, I kinda feel like actors are in the former case. I'm not sure you truly need a full language-level dedication to them to get most of their benefits. There is a last level of confidence and surety you can get in a language like Erlang, but I still think in practice that's just a last incremental benefit rather than a sudden burst in utility as you get to 100% purity. I think it's fine to program an actor here and an actor there in other languages and you get the benefits right there on the spot. Even what benefit there is, things like Rust gain in a different way. Still, I've been watching Pony with some interest.
zengid 4y ago
Fun fact: the person who created Pony, Sylvan Clebsch, has been working on a Microsoft Research project called Verona. From it's README [0]: > 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. [0] https://github.com/microsoft/verona/tree/master https://github.com/microsoft/verona/tree/master
- zozbot234 4y ago
  Quite a bit of PL research is now going in very similar directions; trying to extend Rust's ownership model in a way that can express more patterns of code, while still being reasonably intuitive and ergonomic. (The PL community is already familiar with separation logic, which is quite general and powerful. The assumption is that a middle-of-the-road approach could be very helpful.)
- krylon 4y ago
  Without bothering to look at it first, that sounds like interesting things will come from this. Let's hope they don't share the fate of Singularity/Midori.
CobrastanJorji 4y ago
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.
- deleted 4y ago
  [deleted]
- emmelaich 4y ago
  Where is that list?
  - theIV 4y ago
    https://www.ponylang.io/discover/#why-not-pony https://www.ponylang.io/discover/#why-not-pony
- rtpg 4y ago
  I think it's a bit of a cop out. 3 variations on "we're not big yet!" Examples of things that might be true (I do not know how true this is! Inferring off of what is seen, and I am not judging Pony on any level) - "prototyping UI work in Pony will not work, as there are no great known patterns for writing small UIs that play well with the consequences of our design decisions prioritizing correctness" - "our actor based model works well for the vast majority of highly concurrent programs, but can make realtime systems hard to get right" (I have had this experience in Rust trying tokio vs just opting for manual threading) - "restrictive syntax means that solution spaces involing DSLs will leave you wanting." I think everything is good and great, but it's valuable to lay out the priorities and what are less of a priority. Of course tooling kinda sucks for newer languages. Of course! Tell me about things that will likely always be a bit miserable.
  - lolinder 4y ago
Vedor 4y ago
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.
jwmcq 4y ago
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.
- cpeterso 4y ago
  The language was developed by people in London. > The big reveal on why it’s called “Pony”? Back in the flight sim days, when I would make my friends groan by telling them yet again about all the things I was going to do when I wrote a programming language, one of the people I would tell was Nathan Mehl. And one time, when I gave him yet another laundry list, he said: “yeah, and I want a pony”. But perhaps they didn't want to admit "pony" is also a reference to the slang term.. https://www.ponylang.io/blog/2017/05/an-early-history-of-pony/ https://www.ponylang.io/blog/2017/05/an-early-history-of-pon...
- twic 4y ago
  I've lived in London and the south pretty much all my life, and i'm not sure i've ever heard it used to mean that. It's rhyming slang, right? Not sure how many cabbies are in the market for memory-safe systems programming languages really.
  - jfk13 4y ago
    Also in/from the south (though outside London), and was not familiar with that usage at all. A search does turn up some confirmation, though (e.g. https://www.phrases.org.uk/meanings/287275.html https://www.phrases.org.uk/meanings/287275.html).
- quotha 4y ago
  A pony is a small horse dude
  - tmtvl 4y ago
    No, a small horse dude is a gnometaur. You're thinking about a sporty tiger mascot for a breakfast cereal.
twic 4y ago
To me, the interesting thing about Pony is its system of reference capabilities: https://blog.beardhatcode.be/2018/10/pony-capabilities.html https://blog.beardhatcode.be/2018/10/pony-capabilities.html 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.
no_wizard 4y ago
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. Aside from Elixir being a bigger community the core goals and purpose seem very similar to me
dang 4y ago
Related: Ask HN: Why didn't Pony take off? - https://news.ycombinator.com/item?id=31606084 https://news.ycombinator.com/item?id=31606084 - June 2022 (3 comments) We moved from Pony to Rust - https://news.ycombinator.com/item?id=28777306 https://news.ycombinator.com/item?id=28777306 - Oct 2021 (175 comments) Pony – High-Performance Safe Actor Programming - https://news.ycombinator.com/item?id=25957307 https://news.ycombinator.com/item?id=25957307 - Jan 2021 (152 comments) Pony, Actors, Causality, Types, and Garbage Collection - https://news.ycombinator.com/item?id=24398469 https://news.ycombinator.com/item?id=24398469 - Sept 2020 (29 comments) Pony: Lock-less, data-race-free concurrency - https://news.ycombinator.com/item?id=24201754 https://news.ycombinator.com/item?id=24201754 - Aug 2020 (1 comment) Pony 0.33.1 - https://news.ycombinator.com/item?id=21784698 https://news.ycombinator.com/item?id=21784698 - Dec 2019 (2 comments) Pony 0.29 - https://news.ycombinator.com/item?id=20370448 https://news.ycombinator.com/item?id=20370448 - July 2019 (19 comments) Pony 0.27.0 has been released - https://news.ycombinator.com/item?id=19285762 https://news.ycombinator.com/item?id=19285762 - March 2019 (1 comment) Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart - https://news.ycombinator.com/item?id=19241427 https://news.ycombinator.com/item?id=19241427 - Feb 2019 (143 comments) Pony 0.25.0 released - https://news.ycombinator.com/item?id=18212633 https://news.ycombinator.com/item?id=18212633 - Oct 2018 (38 comments) Show HN: Pony Programming Workshop - https://news.ycombinator.com/item?id=17619483 https://news.ycombinator.com/item?id=17619483 - July 2018 (5 comments) Introduction to the Pony programming language - https://news.ycombinator.com/item?id=17195580 https://news.ycombinator.com/item?id=17195580 - May 2018 (72 comments) The Snake and the Horse: How Wallaroo's Python API Works with Pony - https://news.ycombinator.com/item?id=16768706 https://news.ycombinator.com/item?id=16768706 - April 2018 (8 comments) Some high level information about the Pony programming language - https://news.ycombinator.com/item?id=16619264 https://news.ycombinator.com/item?id=16619264 - March 2018 (10 comments) Why we wrote our Kafka Client in Pony - https://news.ycombinator.com/item?id=16264845 https://news.ycombinator.com/item?id=16264845 - Jan 2018 (95 comments) Dynamic Tracing a Pony and Python Program with DTrace - https://news.ycombinator.com/item?id=15953050 https://news.ycombinator.com/item?id=15953050 - Dec 2017 (2 comments) Why we used Pony to write Wallaroo - https://news.ycombinator.com/item?id=15558051 https://news.ycombinator.com/item?id=15558051 - Oct 2017 (84 comments) Pony Performance Cheatsheet - https://news.ycombinator.com/item?id=14999899 https://news.ycombinator.com/item?id=14999899 - Aug 2017 (35 comments) Pony: Combining safe memory sharing with Erlang-like actors - https://news.ycombinator.com/item?id=14676505 https://news.ycombinator.com/item?id=14676505 - July 2017 (62 comments) An Early History of Pony - https://news.ycombinator.com/item?id=14280565 https://news.ycombinator.com/item?id=14280565 - May 2017 (8 comments) Pony language 0.11.0 released - https://news.ycombinator.com/item?id=13846063 https://news.ycombinator.com/item?id=13846063 - March 2017 (52 comments) On the State of Pony - https://news.ycombinator.com/item?id=12331458 https://news.ycombinator.com/item?id=12331458 - Aug 2016 (40 comments) Using Pony for Fintech [video] - https://news.ycombinator.com/item?id=11849579 https://news.ycombinator.com/item?id=11849579 - June 2016 (6 comments) Using the Actor-Model Language Pony for FinTech - https://news.ycombinator.com/item?id=11297836 https://news.ycombinator.com/item?id=11297836 - March 2016 (1 comment) Pony Patterns: Waiting - https://news.ycombinator.com/item?id=10927475 https://news.ycombinator.com/item?id=10927475 - Jan 2016 (3 comments) Pony is an open-source, actor-model, high performance programming language - https://news.ycombinator.com/item?id=10902906 https://news.ycombinator.com/item?id=10902906 - Jan 2016 (57 comments) Inside the Pony TCP Stack - https://news.ycombinator.com/item?id=10762196 https://news.ycombinator.com/item?id=10762196 - Dec 2015 (1 comment) Pony – High Performance Actor Programming - https://news.ycombinator.com/item?id=9482483 https://news.ycombinator.com/item?id=9482483 - May 2015 (124 comments)
lowbloodsugar 4y ago
>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. 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. 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.
- rurban 4y ago
  It does solve all the problems related to concurrency, because there is no blocking IO. Blocking is forbidden. Pony guarantees freedom of race conditions and dead locks.
zfxfr 4y ago
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"
- reidrac 4y ago
  There are a few, but you are right that they could be more accessible: https://github.com/ponylang/ponyc/tree/main/examples https://github.com/ponylang/ponyc/tree/main/examples (I had the same problem)
samsquire 4y ago
I am interested in Pony due to the compiler maintaining safety while multithreading. I am working on a multithreaded language that has its own interpreter and compiler that codegens targeting it. I use message passing but shared memory mailboxes using a lockfree algorithm. 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. 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.
- insanitybit 4y ago
  (This is all based on my recollection) Pony does this through reference capabilities, ownership, and garbage collection. Basically in Pony you can describe memory as: 1. Single Ownership, Immutable 2. Single Ownership, Mutable 3. Shared Ownership, Immutable 4. Shared Ownership, Mutable If you're moving (1) or (2) that's basically free. If you're sharing (3) you just need an atomic reference count. If you're sharing (4) you need an atomic reference count and some sort of synchronizing primitive, such as a mutex (or maybe the runtime can understand how to schedule things such that they don't race, don't know). In Pony these reference capabilities all have names that I don't remember and there are also ways to "recover" a capability, basically translating one into another, which was one of the more complex features for me to get my head around. That's basically how I recall it working, although the reference counting implementation is very interesting and they wrote a paper about it (Orca).
  - zozbot234 4y ago
    Worth noting that Rust also supports "Shared Ownership, Immutable" data - that's what Arc<T> gives you when T has no interior mutability, and thus implements Sync by default. (By contrast, a T with interior mutability needs explicit atomicity or synchronization, or else cannot have its access shared by multiple threads.)
    - samsquire 4y ago
      This is powerful. I'm not sure how to implement shared memory semantics in an interpreter since each interpreter has its own state.
bketelsen 4y ago
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. 1: https://www.youtube.com/watch?v=s4W4Jb-AAVI https://www.youtube.com/watch?v=s4W4Jb-AAVI

196 points by curling_grad 4y ago

A previous conversation: https://news.ycombinator.com/item?id=17195580 https://news.ycombinator.com/item?id=17195580 On a sort-of-related topic: I've been checking out the Inko programming language, which has some similar goals/ideals as Pony: https://inko-lang.org/ https://inko-lang.org/ Inko lists Erlang and Pony as inspiration for its concurrency model: "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."

ch4s3 4y ago
Building a typed, OO language inspired by Erlang on top of Rust seems like a bit of a platypus if that makes sense. I'm really wondering who is using this other than former Pony users.
treuks 4y ago
looks cool to me, really wish they had standard library documentation and better editor support, but it's obviously waaay too young for this to be critical. i can see this maturing into a really nice web-backend language though. typed elixir with rust error handling and algebraic types? sign me up
0xTadash1 4y ago
I always wonder when I come across a text like this what a lightweight process is. Is it different from just a thread? Or is it a type of lightweight/virtual thread?
- aidenn0 4y ago
  There are multiple definitions of LWPs. I think the way it is being used here is a user-scheduled thread. In the old Unix days it meant "kernel thread"
- jeremyjh 4y ago
  Yes it is a lightweight thread or “green” thread. Coroutines that are scheduled by the languages runtime across a pool of multiple OS threads and are implemented using an event loop that resumes a coroutine whenever the IO it was blocked on is available, sort of like if in Node all the async/await keywords were implemented for you automatically on every IO OP. Some languages (Erlang, Go, Haskell) have green threads with preemptive scheduling on CPU loops (though Go only preempts at function boundaries IIRC) but Pony does not, actors have to cooperate.
  - Matthias247 4y ago
    > though Go only preempts at function boundaries IIRC I think this was improved with more recent Go versions and now it is really preemptive

Thaxll 4y ago

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. https://web.archive.org/web/20171028135810/https://blog.wallaroolabs.com/2017/10/why-we-used-pony-to-write-wallaroo/ https://web.archive.org/web/20171028135810/https://blog.wall... Then: https://www.wallaroo.ai/blog/wallaroo-move-to-rust https://www.wallaroo.ai/blog/wallaroo-move-to-rust

wiremine 4y ago
I'm not sure, but the last commit on the github repo was 12 hours ago.
Davidbrcz 4y ago
Last time I checked, it was language backed by a research group.
Mikeb85 4y ago
Development has definitely slowed and the creator has moved on to other things. I've played around with it and my main takeaway is that it's easier to create an actor system in an existing language than to create an entire ecosystem around Pony.
jcarr25- 4y ago
They used Pony as a good fit for their first project. They later made a second project with better market fit, and for that project Rust was a better fit.
dang 4y ago
Can you please make your substantive points without breaking the site guidelines? They include: "Don't be snarky." "Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

krylon 4y ago

I looked into pony a couple of years ago. The type system was gorgeous, but the library ecosystem was very spartan. 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.

pard68 4y ago

Minor nit, it takes far too many clicks to see what the language looks like.

qorrect 4y ago
Came here to say this also, couldn't find any code samples after 5 clicks and gave up.
- TruthWillHurt 4y ago
  I went much deeper than 5 clicks, into tutorial, about, getting started - no code. Only thing remotely like the syntax is the cheat sheet.
aidenn0 4y ago
I didn't take me too many clicks; from ponlyang.io I cliked "try it in your browser" and it dumped me to a hello world. Alternatively there is an examples folder on the linked GH page.
Pet_Ant 4y ago
https://tutorial.ponylang.io/getting-started/how-it-works.html#compiling-your-program https://tutorial.ponylang.io/getting-started/how-it-works.ht...

jevgeni 4y ago

is it just me, or is it super difficult to find code samples - even in the tutorial?

warpspin 4y ago
No, it's not just you. Huge mistake, in my opinion. If I see a page for a new programming language, I want to be one click away from code samples.
augustk 4y ago
Indeed, like vapourware almost.
kulibali 4y ago
The fourth link on the home page is "Example Pony Applications"
Pet_Ant 4y ago
https://tutorial.ponylang.io/getting-started/how-it-works.html#compiling-your-program https://tutorial.ponylang.io/getting-started/how-it-works.ht...
- jevgeni 4y ago
  Thank you! I realized that the left-side menu is actually a TOC, which for some reason I didn't register at first.

nikivi 4y ago

Was reading docs on actors https://tutorial.ponylang.io/types/actors.html https://tutorial.ponylang.io/types/actors.html And I wonder what makes pony actors different to Go's goroutines?

insanitybit 4y ago
Pony actors: 1. Have a typed, nominal interface (called behaviors) 2. Have state Those are probably the main differences, just with regards to actors.
jerf 4y ago
In general, your latter question is better asked as "what makes actors different from threads?", because in practice a goroutine is just a thread. (What makes Go different from C++ in the 1990s is more community practice around what concurrency patterns are most commonly used, rather than technical differences in the language. Technically Go is just a mutable threaded language; for this purpose details about how the threading is accomplished are not that important.) In general the big difference with actors is that they are isolated from each other in some manner that means they can't just reach in to some other actor's memory space and manipulate the memory concurrently. Languages are starting to blur the lines here. Rust's lifetime annotation is not on its own sufficient to call Rust an "actor-based language" but the fact that they also prevent threads/async processes from just reaching in and manipulating other threads/async process's value unexpectedly means you've certainly taken a big step in that direction. And while Go provides no language-level technical support for actors, I still have a lot of things that are de facto actors in Go that uses scoping and export rules to confine the ability of other goroutines to interfere with a particular "actor"'s values, combined with an API that enforces message-based communication even though it works through what look like normal methods. This is not enforced at all technically by the language but it works better with community code than it does in older thread-based languages because the Go community is more recent and you can generally rely on libraries using somewhat more modern concurrency primitives, like providing services based on actors or actor-like objects. There are some things in programming where if you mostly follow some practice, you get most of the benefit. There are other things in programming where the benefit only kicks in if you do it almost entirely correctly; an example of the latter is Haskell's rigid insistence on functional programming and immutability, I'm not convinced that it's worth doing 90% of that but when you fully commit and build the language around it, there is an interesting spike in capability at the end. After programming in this space for well over a decade now, I kinda feel like actors are in the former case. I'm not sure you truly need a full language-level dedication to them to get most of their benefits. There is a last level of confidence and surety you can get in a language like Erlang, but I still think in practice that's just a last incremental benefit rather than a sudden burst in utility as you get to 100% purity. I think it's fine to program an actor here and an actor there in other languages and you get the benefits right there on the spot. Even what benefit there is, things like Rust gain in a different way. Still, I've been watching Pony with some interest.

zengid 4y ago

Fun fact: the person who created Pony, Sylvan Clebsch, has been working on a Microsoft Research project called Verona. From it's README [0]: > 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. [0] https://github.com/microsoft/verona/tree/master https://github.com/microsoft/verona/tree/master

zozbot234 4y ago
Quite a bit of PL research is now going in very similar directions; trying to extend Rust's ownership model in a way that can express more patterns of code, while still being reasonably intuitive and ergonomic. (The PL community is already familiar with separation logic, which is quite general and powerful. The assumption is that a middle-of-the-road approach could be very helpful.)
krylon 4y ago
Without bothering to look at it first, that sounds like interesting things will come from this. Let's hope they don't share the fate of Singularity/Midori.

CobrastanJorji 4y ago

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.

deleted 4y ago
[deleted]
emmelaich 4y ago
Where is that list?
- theIV 4y ago
  https://www.ponylang.io/discover/#why-not-pony https://www.ponylang.io/discover/#why-not-pony
rtpg 4y ago
I think it's a bit of a cop out. 3 variations on "we're not big yet!" Examples of things that might be true (I do not know how true this is! Inferring off of what is seen, and I am not judging Pony on any level) - "prototyping UI work in Pony will not work, as there are no great known patterns for writing small UIs that play well with the consequences of our design decisions prioritizing correctness" - "our actor based model works well for the vast majority of highly concurrent programs, but can make realtime systems hard to get right" (I have had this experience in Rust trying tokio vs just opting for manual threading) - "restrictive syntax means that solution spaces involing DSLs will leave you wanting." I think everything is good and great, but it's valuable to lay out the priorities and what are less of a priority. Of course tooling kinda sucks for newer languages. Of course! Tell me about things that will likely always be a bit miserable.
- lolinder 4y ago

Vedor 4y ago

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.

jwmcq 4y ago

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.

cpeterso 4y ago
The language was developed by people in London. > The big reveal on why it’s called “Pony”? Back in the flight sim days, when I would make my friends groan by telling them yet again about all the things I was going to do when I wrote a programming language, one of the people I would tell was Nathan Mehl. And one time, when I gave him yet another laundry list, he said: “yeah, and I want a pony”. But perhaps they didn't want to admit "pony" is also a reference to the slang term.. https://www.ponylang.io/blog/2017/05/an-early-history-of-pony/ https://www.ponylang.io/blog/2017/05/an-early-history-of-pon...
twic 4y ago
I've lived in London and the south pretty much all my life, and i'm not sure i've ever heard it used to mean that. It's rhyming slang, right? Not sure how many cabbies are in the market for memory-safe systems programming languages really.
- jfk13 4y ago
  Also in/from the south (though outside London), and was not familiar with that usage at all. A search does turn up some confirmation, though (e.g. https://www.phrases.org.uk/meanings/287275.html https://www.phrases.org.uk/meanings/287275.html).
quotha 4y ago
A pony is a small horse dude
- tmtvl 4y ago
  No, a small horse dude is a gnometaur. You're thinking about a sporty tiger mascot for a breakfast cereal.

twic 4y ago

To me, the interesting thing about Pony is its system of reference capabilities: https://blog.beardhatcode.be/2018/10/pony-capabilities.html https://blog.beardhatcode.be/2018/10/pony-capabilities.html 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.

no_wizard 4y ago

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. Aside from Elixir being a bigger community the core goals and purpose seem very similar to me

dang 4y ago

Related: Ask HN: Why didn't Pony take off? - https://news.ycombinator.com/item?id=31606084 https://news.ycombinator.com/item?id=31606084 - June 2022 (3 comments) We moved from Pony to Rust - https://news.ycombinator.com/item?id=28777306 https://news.ycombinator.com/item?id=28777306 - Oct 2021 (175 comments) Pony – High-Performance Safe Actor Programming - https://news.ycombinator.com/item?id=25957307 https://news.ycombinator.com/item?id=25957307 - Jan 2021 (152 comments) Pony, Actors, Causality, Types, and Garbage Collection - https://news.ycombinator.com/item?id=24398469 https://news.ycombinator.com/item?id=24398469 - Sept 2020 (29 comments) Pony: Lock-less, data-race-free concurrency - https://news.ycombinator.com/item?id=24201754 https://news.ycombinator.com/item?id=24201754 - Aug 2020 (1 comment) Pony 0.33.1 - https://news.ycombinator.com/item?id=21784698 https://news.ycombinator.com/item?id=21784698 - Dec 2019 (2 comments) Pony 0.29 - https://news.ycombinator.com/item?id=20370448 https://news.ycombinator.com/item?id=20370448 - July 2019 (19 comments) Pony 0.27.0 has been released - https://news.ycombinator.com/item?id=19285762 https://news.ycombinator.com/item?id=19285762 - March 2019 (1 comment) Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart - https://news.ycombinator.com/item?id=19241427 https://news.ycombinator.com/item?id=19241427 - Feb 2019 (143 comments) Pony 0.25.0 released - https://news.ycombinator.com/item?id=18212633 https://news.ycombinator.com/item?id=18212633 - Oct 2018 (38 comments) Show HN: Pony Programming Workshop - https://news.ycombinator.com/item?id=17619483 https://news.ycombinator.com/item?id=17619483 - July 2018 (5 comments) Introduction to the Pony programming language - https://news.ycombinator.com/item?id=17195580 https://news.ycombinator.com/item?id=17195580 - May 2018 (72 comments) The Snake and the Horse: How Wallaroo's Python API Works with Pony - https://news.ycombinator.com/item?id=16768706 https://news.ycombinator.com/item?id=16768706 - April 2018 (8 comments) Some high level information about the Pony programming language - https://news.ycombinator.com/item?id=16619264 https://news.ycombinator.com/item?id=16619264 - March 2018 (10 comments) Why we wrote our Kafka Client in Pony - https://news.ycombinator.com/item?id=16264845 https://news.ycombinator.com/item?id=16264845 - Jan 2018 (95 comments) Dynamic Tracing a Pony and Python Program with DTrace - https://news.ycombinator.com/item?id=15953050 https://news.ycombinator.com/item?id=15953050 - Dec 2017 (2 comments) Why we used Pony to write Wallaroo - https://news.ycombinator.com/item?id=15558051 https://news.ycombinator.com/item?id=15558051 - Oct 2017 (84 comments) Pony Performance Cheatsheet - https://news.ycombinator.com/item?id=14999899 https://news.ycombinator.com/item?id=14999899 - Aug 2017 (35 comments) Pony: Combining safe memory sharing with Erlang-like actors - https://news.ycombinator.com/item?id=14676505 https://news.ycombinator.com/item?id=14676505 - July 2017 (62 comments) An Early History of Pony - https://news.ycombinator.com/item?id=14280565 https://news.ycombinator.com/item?id=14280565 - May 2017 (8 comments) Pony language 0.11.0 released - https://news.ycombinator.com/item?id=13846063 https://news.ycombinator.com/item?id=13846063 - March 2017 (52 comments) On the State of Pony - https://news.ycombinator.com/item?id=12331458 https://news.ycombinator.com/item?id=12331458 - Aug 2016 (40 comments) Using Pony for Fintech [video] - https://news.ycombinator.com/item?id=11849579 https://news.ycombinator.com/item?id=11849579 - June 2016 (6 comments) Using the Actor-Model Language Pony for FinTech - https://news.ycombinator.com/item?id=11297836 https://news.ycombinator.com/item?id=11297836 - March 2016 (1 comment) Pony Patterns: Waiting - https://news.ycombinator.com/item?id=10927475 https://news.ycombinator.com/item?id=10927475 - Jan 2016 (3 comments) Pony is an open-source, actor-model, high performance programming language - https://news.ycombinator.com/item?id=10902906 https://news.ycombinator.com/item?id=10902906 - Jan 2016 (57 comments) Inside the Pony TCP Stack - https://news.ycombinator.com/item?id=10762196 https://news.ycombinator.com/item?id=10762196 - Dec 2015 (1 comment) Pony – High Performance Actor Programming - https://news.ycombinator.com/item?id=9482483 https://news.ycombinator.com/item?id=9482483 - May 2015 (124 comments)

lowbloodsugar 4y ago

>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. 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. 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.

rurban 4y ago
It does solve all the problems related to concurrency, because there is no blocking IO. Blocking is forbidden. Pony guarantees freedom of race conditions and dead locks.

zfxfr 4y ago

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"

reidrac 4y ago
There are a few, but you are right that they could be more accessible: https://github.com/ponylang/ponyc/tree/main/examples https://github.com/ponylang/ponyc/tree/main/examples (I had the same problem)

samsquire 4y ago

I am interested in Pony due to the compiler maintaining safety while multithreading. I am working on a multithreaded language that has its own interpreter and compiler that codegens targeting it. I use message passing but shared memory mailboxes using a lockfree algorithm. 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. 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.

insanitybit 4y ago
(This is all based on my recollection) Pony does this through reference capabilities, ownership, and garbage collection. Basically in Pony you can describe memory as: 1. Single Ownership, Immutable 2. Single Ownership, Mutable 3. Shared Ownership, Immutable 4. Shared Ownership, Mutable If you're moving (1) or (2) that's basically free. If you're sharing (3) you just need an atomic reference count. If you're sharing (4) you need an atomic reference count and some sort of synchronizing primitive, such as a mutex (or maybe the runtime can understand how to schedule things such that they don't race, don't know). In Pony these reference capabilities all have names that I don't remember and there are also ways to "recover" a capability, basically translating one into another, which was one of the more complex features for me to get my head around. That's basically how I recall it working, although the reference counting implementation is very interesting and they wrote a paper about it (Orca).
- zozbot234 4y ago
  Worth noting that Rust also supports "Shared Ownership, Immutable" data - that's what Arc<T> gives you when T has no interior mutability, and thus implements Sync by default. (By contrast, a T with interior mutability needs explicit atomicity or synchronization, or else cannot have its access shared by multiple threads.)
  - samsquire 4y ago
    This is powerful. I'm not sure how to implement shared memory semantics in an interpreter since each interpreter has its own state.

bketelsen 4y ago

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. 1: https://www.youtube.com/watch?v=s4W4Jb-AAVI https://www.youtube.com/watch?v=s4W4Jb-AAVI