I always wondered whether the language had or had not been named because of that show about colorful, pastel-, candy-colored equines, of which I'm totally not a fan of.
The distributed-process (Cloud Haskell) library gives you Erlang-style processes/actors in Haskell. Haskell is a good language to map these concepts to since it already has lightweight threads, pattern matching, asynchronous exceptions and other language features required to faithfully implement Erlang semantics.
Scala/Akka would be another choice but it has totally different semantics from Erlang, and you can never forget you are working in an async model.
I think there is some misunderstanding of what Pony is. It doesn't target distributed systems by the looks of it, it's more like a statically typed OO language with an alternative to threads/mutexes/channels. So you can see it being interesting to people with statically typed OO background, who understand the downsides of multithreading and want concurrency and parallelism on a single system, i.e. those coming from languages like Java and C++. It's more appropriate to compare it with Rust or Go, but not Erlang or Akka.
I'm not sure why you would say that Pony doesn't target distributed systems. In the sense that there is no "distributed pony" yet, then yes.
I spend my days writing a soon to be open sourced distributed system in Pony. The "alternative" to threads/mutexes/channels is actors which from a concurrency model perspective makes it very like Erlang. The GC model is also very like Erlang.
What's a good use for distributed Erlang? I'm writing some Elixir apps, and I can't think of a great reason to use distributed between a client and a daemon running on the same box.
One (simplified) example usage: you have an application that you need to scale from 1 BEAM process to more than 1 in order to handle the load. If you are using distributed erlang, sending a message to a remote actor is the same as sending to a local actor and scaling is seamless from the code perspective. Think of having a cluster of BEAM vms that from a programming perspective, you can treat as a single vm.
Why are you specifying that they're on the same box? You can use distributed erlang between different computers and the messaging remains the same even in those circumstances.
On top of that you also get automatic failover for distributed apps(0) that are supposed to run on only one node at a time, handled entirely by the runtime, with takeover, etc.
If you're using Elixir, you should probably actually read up on the technology you're using. These are basic concepts explained in, for example, "Programming Erlang".
I've got an Elixir app running as a daemon to manage cleaning up some certain build related files for a build system. The daemon is a release started by the init system. N clients might call the daemon, and the daemon makes sure the files needed for the build, or maybe left over from the last build, or in the correct state. The client could talk to the daemon via a socket or TCP port, but distributed Erlang would also be an option.
I would say when it comes to client-server interaction in Erlang, it's fine to make that as if it were any other language, but there are plenty of situations where you'd like to spin up several nodes of something in AWS, for example, and those would necessarily have to talk to each other.
You'll set up the ability for them to coordinate (by simply setting their longnames and setting them all up to connect to one machine, making them create a mesh network) and transparently you'll now have several machines working on something as if they were one, with minimal effort on your part.
The big downside to using distributed erlang is that it has very little to offer in terms of security. If you don't add something yourself (which admittedly isn't too hard) you'll be relying only on a common password for connecting to the mesh, as well as knowing which machine to connect to. Obviously it makes for a situation where it's best and most appropriate to use on your private network, setting up other means of communicating with public networks.
I think the actor model is orthogonal to distributed systems. Actors are a good model for concurrency in a single system or a distributed system. Just like lots of people build distributed systems in C++, Java or Go, there are a lot of people using Erlang in a single node application.
>Scala/Akka would be another choice but it has totally different semantics from Erlang, and you can never forget you are working in an async model
The actor model is asynchronous by definition. Did you maybe intend to say something else? What makes Erlang different is that the BEAM VM is made for the actor model, so it has per-actor GC and other things that are basically impossible in other languages that don't use BEAM.
Erlang and Haskell give you a sequential programming model for I/O (and everything else) within each actor process. You can read from a file, take a result from it, do a database query then post a message to another process.
In Akka, you must use asynchronous I/O directly, or use a thin abstraction such as Futures with monadic bind to accomplish the same thing. Under the covers, the Haskell and Erlang runtimes are handling this for you so that you can forget about the fact that you are doing async I/O.
In Akka, if you don't pay attention to this and use a non-NIO Java library to do I/O, you will block the entire scheduler. Whereas, every library in the Erlang and Haskell ecosystems already uses the async I/O abstractions in the runtime.
For sure the independent execution of the actors internal logic is a fundamental property of an actor system. However I think communication APIs between actors don't have to be asynchronous by definition: In Akka they are, because blocking threads woul kill the performance. In Erlang synchronous communication between actors works fine. The C# Orleans framework also favors "synchronous" communication - yes, actor communication returns Task<T> results which can be awaited, so it's async unter the hood - but I consider that an implementation detail). Pony in contrast leans to purely async APIs. There's no way to actively wait for a response from another actor. The advantage is that deadlocks are not possible at all, whereas with synchronous actor communication you can deadlock when 2 actors are waiting upon each other. The drawback are callbacks and the need to model everything as a state machine.
> In Erlang synchronous communication between actors works fine.
There is no such thing as synchronous communication in Erlang!
When coding in Erlang you better remember this. The primitive operation in Erlang is the async message send and that's it.
Sync messages are built on top of async send, blocking receive blocks and a lot of overhead involving linking and monitoring (because the process you're sending to may die before the message arrives or before it can send the response).
All this is handled by gen_somethings (`gen_server:call` does this, for example), but sync messages are not the basic primitive in Erlang. They may work, but they are not trivially implemented - I know, I tried working without OTP for a while. I reimplemented a lot of edge-cases handling in my project back then and when I finally checked library sources I was shocked to learn that it was still less than a half of what was needed...
I wrote synchronous communication, with which I meant the combination of a sending a request message and do a blocking wait for a response message. I'm aware that the pure message sending in Erlang is async. What I intended to highlight is that the "do a blocking wait for a response" part is possible in Erlang, but not in Pony or Akka (yes, you can do it in Akka, but it's not recommended for performance reasons).
I have to admit, the name of it throws me off. The intended or unintended relation with the subculture of obsessed adult men with a pre-teen show, and this programming language's name really makes me not want to take it seriously.
I love to judge things for what they are, and not what they're named or related too, but given there's so many languages fighting for my attention, this one is hard to swallow.
LLVM was originally designed for C like languages, until recently used the system linker (lld is a recent change), so any language that uses it for its backend tends to suffer from the same lengthy compilations as C and C++.
Unless they create their own intermediate language, so that they can do as much work as possible, before passing the bucket to LLVM.
Hence why Swift has SIL, Rust MIR, and so forth for other languages.
I don't think the use of the system linker is why Swift has SIL, nor Rust has MIR. It's true that one of the possible benefits of Rust's MIR is faster compilations, but it is fundamentally motivated by representing (and checking) semantic information that is unavailable at the LLVM level. Whatever linker LLVM happens to use is orthogonal to this.
We still have tons of work to do in general.
There's a paper on how to do distributed actors with Pony but as yet, we haven't implemented anything yet. We started but deprioritized it.
Sylvan (referenced as main guru in the link) is still an active member of the Pony community and he's contributing on a regular basis. His most recent commit that was merged to master was yesterday:
The Pony development community is still relatively small but we make good regular progress. We all wish the community was bigger and we were progressing more quickly but that is always going to be the case.
We have a regular weekly development Zoom call that is open to the public. Feel free to join. Info is available in the Pony development groups.io group: https://pony.groups.io/g/dev/calendar.
If you join the development list, you'll also get access to the recordings of the sync meeting going back close to a year. There's a wealth of info there for anyone cares to dig in. Probably more than anyone would care to ever listen to.
"Development status:
Everything we talked so far is real and is in use.
Runs on everything from a Raspberry PI to 4096 core SGI
Windows OSX Linux FreeBSD
Performance is competitive with C/C++, often better as core counts go up"
Having tracked Pony for a while and started using it more heavily over the last several months - I would say the Quora quote is pretty wrong and short sighted. As per SB's comment the original developers are still involved. From my perspective as a user the additions to the team have helped fill out gaps and kept momentum going (especially when the original team needed to focus elsewhere for a while).
Certainly as the new community members have stepped up the nature and style of the community has been influenced and evolves and not everyone has necessarily liked those changes (as per Quora comments) but I think the language has benefitted.
Languages, like operating systems - are often identified with the original designers - but it takes a community to grow it and ensure continued growth. Pony's community is still small but folks are actively contributing to Pony's growth and maturity. The language still has a long way to go but its fun to use and its got some interesting ideas that are worth exploring.
http://www.ponylang.org/