Pony language 0.11.0 released | Hacker News Reader

Pony language 0.11.0 released

pony.groups.io

130 pointsspooneybarger52 comments

Pony is an open-source, object-oriented, actor-model, capabilities-secure, high performance programming language.

http://www.ponylang.org/

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 answer would be no, but we have no objections to equines of any color.

I think it's named after rhyming slang for crap (pony and trap).

also nope:

it's from the phrase "and I want a pony"

Originally from here:

http://www.gocomics.com/calvinandhobbes/1987/01/13

that would be it

>that show about colorful, pastel-, candy-colored equines, of which I'm totally not a fan of.

Have you watched the last couple of seasons? I liked them more.

Have you seen the FIM++ language? Perhaps somebody should re-write the interpreter in Pony.

https://github.com/JaredMFProgramming/fimpp

Oh man, but that's nothing compared to this: https://github.com/ErisBlastar/cplusequality

Actors + type safety is a huge selling point for Pony that, to my knowledge, no other language is really providing.

I'm definitely keeping an eye on it and I'm very excited to see its development continue.

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.

In the end, it is its own thing.

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.

It's more object oriented don't you think?

If you have each part of your code running on different processes, then failures are isolated.

Unless I'm reading your question wrong...

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

0 - http://erlang.org/doc/design_principles/distributed_applicat...

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.

No need to leave c++ for great actors:

https://actor-framework.org/

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

I think if you replaced "an async model" with "a shared event loop" I agree with the expressed frustration.

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.

> The actor model is asynchronous by definition

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

There's Fantom, a JVM based language with baked in actor model. I guess Scala should count too, to some extent.

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.

The 2017 Pony Community Survey just went up. If you are a Pony user or have played around with, we'd love to hear from you.

https://goo.gl/forms/5qAmppwIEkvvEFkq1

Here is a really great, very high performance, full featured c++ library for actors:

https://actor-framework.org/

I wonder, where does ponylang fall short? I think that might be an interesting way to compare it to other languages.

I'm on the core team and I'm working on a "Why Pony?" talk that starts with all the reasons you wouldn't want to use Pony. There are many.

I'd be happy to discuss via email if you want. My address is in my profile.

Curious what the deployment story for this looks like compared to things like Crystal. Is it compiled?

Yes. Pony compiles to LLVM bytecode and from there to native binaries.

So it has Rust and C++'s compile time problems?

It shares LLVM pros and cons of other languages that compile to LLVM bytecode.

can you elaborate on what you mean, as it relates to Pony?

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.

What would you suggest someone use instead? As someone looking to write his own language, I'm very interested in alternatives to LLVM.

Using a system like LLVM locks you into C-like behavior. You can work around it, but it's harder and can come with unnecessary overheads.

Nanopass is one approach to compiling that tends to be more general.

However, LLVM is great if you just want to compile without learning the intracies of assembly. It even gives you access to multiple backends.

Linking against a framework let's you get up to speed faster, and someone else handles the security in your compiler, for the most part.

But, when you need flexibility, you'll probably need to do it yourself.

(See Scala and Dotty, as Scala becomes even less Java-like).

With zapcc these times are gone, but yes.

It doesn't have the rust problems with manual locking and deadlocks, and the C++ syntax horrors. It's also smaller and faster than those.

Pony is amazing, I am curious about the object capability model applied to distributed systems.

http://erights.org/talks/thesis/markm-thesis.pdf has several chapters dedicated to the concept. Happy reading.

that's an awesome paper. thank you for posting it.

Thanks.

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.

https://www.doc.ic.ac.uk/~scd/Disributed_Pony_Sept_13.pdf

Can anyone comment on the level of development?

I came across one comment where the author seemed to think the main gurus were no longer working on it. e.g. here: https://www.quora.com/What-is-your-experience-with-using-Pon...

I myself don't have much knowledge of Pony,which is why I ask...

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:

https://github.com/ponylang/ponyc/commit/eaf1dcd525c691feae1...

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.

Sylvan is busily working with his team on the feature for distributed actors at Microsoft Research.

* Type-system for machine specific data (local vs foreign actors, e.g file descriptors, ...)

* Node failure

* Distributed GC (pointer identity => random id)

* Distributed work-stealing (CNF-ACK protocol, user-specific scheduler rules: moving cost, ...)

There's also more work going for more formal proofs.

Here is a bit of explanation: https://www.youtube.com/watch?v=KIziz1c41ww

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

Esp. the last 10 slides.

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.

Reply on news.ycombinator.com