
Pony is an open-source, actor-model, high performance programming language - kordless
http://www.ponylang.org/
======
betenoire
The audience of a programming language are developers. Developers like code,
code speaks to us. Actual code samples are a few clicks away:
[http://tutorial.ponylang.org/getting-
started/helloworld/](http://tutorial.ponylang.org/getting-started/helloworld/)

pony-lang devs: put some examples on the home page!

~~~
m8rl
Actually, more example code at
[http://tutorial.ponylang.org/examples/examples/](http://tutorial.ponylang.org/examples/examples/)

~~~
voaie
Still don't understand those capability types (iso, trn, ...). Need more
tutorials!

------
BenoitP
The papers[1] is where is the meat is.

> Ownership and Reference Counting [...] We propose Pony-ORCA, a fully
> concurrent protocol for garbage collection in the actor paradigm

> with shared memory [...] introduces a new form of write uniqueness

> a dedicated actor for the detection of (cyclic) garbage

So, Erlang + shared state? Rust + GC + green threads?

I'm very happy there is activity in this space; I feel like there a whole
class of massively online realtime applications just waiting to happen.

5k users first person shooter anyone?

[1]
[https://github.com/ponylang/ponylang.github.io/tree/master/p...](https://github.com/ponylang/ponylang.github.io/tree/master/papers)

~~~
steveklabnik

      > Rust + GC + green threads?
    

I haven't used Pony much yet, but when I first saw it, this was my first
connection. In some, but not all, ways, it is like what Rust used to be at a
certain moment in its history. The languages have different goals, so it's not
like I think this means Rust is better or something.

~~~
Matthias247
No, I don't think the similarity is big. Pony is all the way about
asynchronous/nonblocking messaging. Rust with green threads was favoring
synchronous/blocking calls, just like Go, which probably also suits the
ownership model better.

So Pony might be better compared to Erlang with a strong type system and
without a blocking receive method than to Rust or Go.

~~~
steveklabnik
Yeah, I mean, this is why comparing languages solely based on feature lists is
a bad idea; it's also about things like idioms. It's more like, "in some ways,
Rust was trying to be similar to Erlang, and in some ways, Pony is trying to
be similar to Erlang, so in some ways, Pony and Rust are kinda similar."
Emphasis on the 'kinda'.

(And I'm thinking about Rust _pre_ ownership model, here. And Rust does have
non-blocking IO, just not in the standard library. It's not imcompatible with
ownership.)

------
3pt14159

        wget -O - http://releases.ponylang.org/buildbot@lists.ponylang.org.gpg.key | sudo apt-key add -
    

This is not secure. Non https connections cannot be trusted. It is trivial for
a cafe owner to MITM this and now he is generally trusted with your apt-get.
BAD.

------
ggchappell
This looks interesting.

There are a few things I wonder about. From the first page of the tutorial
([http://tutorial.ponylang.org/](http://tutorial.ponylang.org/)):

> It's exception safe. There are no runtime exceptions. All exceptions have
> defined semantics, and they are always handled.

This seems contradictory. Are there exceptions or not? EDIT. Apparently there
are
([http://tutorial.ponylang.org/expressions/exceptions/](http://tutorial.ponylang.org/expressions/exceptions/)).
But then I don't understand what the above means.

> It's deadlock free. This one is easy, because Pony has no locks at all!

This is nonsense. Deadlock happens when multiple processes/threads are waiting
for each other. It is not caused by locks.

From another tutorial page ([http://tutorial.ponylang.org/types/static-vs-
dynamic/](http://tutorial.ponylang.org/types/static-vs-dynamic/)):

> There's no such thing as null, so your program will never try to dereference
> null.

But there _is_ "None"
([http://tutorial.ponylang.org/types/primitives/](http://tutorial.ponylang.org/types/primitives/)).
How is "None" so different from this "null" that we want to avoid?

On the positive side:

As I said this looks interesting. The type system appears to have been well
thought out. _Intersections_ look like a sane way to provide functionality
that other PLs either implement poorly (perhaps via "multiple inheritance"),
or simply disallow.

And if the type system really does offer all the claimed guarantees, then it
is a very good thing indeed.

The partial applications, the concurrency model, and the handling of
immutability are also clearly features that someone has given a lot of thought
to. I cannot judge the results at this point, but I like well-thought-out
things. :-) And the notion of "apply", along with the shortcut syntax, seems
like it provides a standard, easy to understand way to make lot of code pretty
simple.

I hope to be able to look into this PL more closely in the near future.

~~~
steveklabnik

      > How is `None` so different from this "null" that we want to avoid?
    

The difference is the defaults. Languages "with null" generally assume that
any value can be null. Other languages, like Pony, do not allow any type to be
null.

Pony's "None" type is an example of a "unit type": a type with only one
possible value. It's a totally different thing.

~~~
ggchappell
Ah, I guess I misunderstood. From the tutorial:

> Pony often uses the primitive None to indicate that something has "no
> value".

So that is not a special value that we can assign to any variable.

"None" would seem to be pretty pointless all by itself, but I guess we could
do a union of any old type with "None", to get a result much like Haskell's
"Maybe". And then the Pony type system would give us much the same guarantees
as Haskell's would; so we get a nullable variable that still allows for
typesafe operations -- e.g., dereferencing, if applicable. (I guess ....)

~~~
steveklabnik
Yeah, when I read the parent comment, I thought that None was part of a type
like Maybe, but the next sentence describes it as a unit type:

    
    
      > Of course, it does have a value, so that you can check what it is, and the value is the single instance of None.

~~~
ggchappell
Yes, but, as I noted, Pony has type unions
([http://tutorial.ponylang.org/types/type-
expressions/](http://tutorial.ponylang.org/types/type-expressions/)). So you
can roll your own Maybe types.

From the page I linked above:

> var x: (String | None)

> Here we have an example of using a union to express an optional type, where
> x might be a String, but it also might be None.

That's pretty clearly a Maybe.

~~~
steveklabnik
Maybe (at least in Haskell/Rust) is a sum type, not a union type, though.

EDIT: Ugh, sorry, those are the same, I was thinking of sum vs _product_ type,
ignore me.

~~~
vram22
Is a union type (at least in Haskell/Rust) structured like a union in C, where
alternative types of values (e..g. int, float, char) occupy the same bytes,
just not at the same time? Or is separate space allocated for the different
types of values? Asking because, if a function returns a union type, with one
type within it representing an integer (which can have any value), and if the
function also wants to return an error condition, then no valid integer value
can be used to indicate the error, because all integer values are valid return
values from the function. In this case I would think that a union type should
have separate space allocated for the integer value and the error-signalling
value. (Something like what golang does with its return values?)

~~~
steveklabnik
There are two major forms of sum type implementations that I'm aware of:
tagged and untagged. What you're describing is a tagged union, for exactly the
reason you state: there's an extra field for a discriminant which lets you
choose the tag. Untagged unions are C's unions, where there's no discriminant,
and you just have to know which type is valid at a given time.

Rust supports tagged unions, but can also optimize them to untagged in certain
circumstances. We will probably add some kind of untagged union as well,
mostly for FFI, but they're very unsafe, for the above reasons.

~~~
vram22
Got it, thanks. Interesting about Rust's design goals and tradeoffs.

------
cobaltblue
Whence the high performance claim? I tried finding some benchmarks, and
apparently they used to be on the home page since this was on HN about a year
ago, but I didn't find any recent ones. It would be nice to see it compared
to, say, Rust, Nim, Haskell, OCaml, C...

~~~
ggchappell
That's a good point.

But I do see where the claim is coming from. Pony is aimed at the same kind of
compile-to-bare-metal that we do with C, C++, Fortran, etc. Furthermore,
Pony's design explicitly deals with many of the issues that get in the way of
aggressive optimization in other PLs: pointer aliasing, dynamic type checking,
data races, etc.

So Pony was clearly designed with high performance in mind. And it seems
likely to me that the efforts made in that direction are practical, workable
ones.

But that is not the same as saying, "We can write a Pony compiler that
generates fast code." And it is certainly not the same as, "We _have written_
a Pony compiler that generates fast code."

~~~
smaddox
Looks like they use LLVM backend, so they'll get low level optimisation for
"free". The GC is also interesting: fully concurrent and lock-free.

------
z3t4
I find this interesting, but a bit too complex.

As a hardcore JavaScript programmer I make use of clusters or spawn child
process to handle "actors" and I think that is much easier to reason about.

I would be happy if Pony had some examples of how to manage "world" state. For
example if two objects in a 2D world intersects, or when one actor fires a
laser, decide if another actor was hit by it.

I'm writing server code for MMO's and it seems like Erlang, Pony, etc would be
the magic tool for such systems, but I never seem to "get it".

~~~
fenollp
Erlang is far from "a bit too complex": it's just not.

What is difficult from devs coming from the imperative world is getting
recursion & bind-variables-only-once (what is commonly known as "the syntax is
ugly").

Please, have a look at
[http://learnyousomeerlang.com/content](http://learnyousomeerlang.com/content)

------
desireco42
I think it is fair to say that developers don't have most sensibility when it
comes to UX, and often UI, so I think let's allow Pony Lang maintainers to
make site a little bit easier to read and attract us.

Honestly, these days, we have a lot of choices, you really need to woo us,
show us why would we want to program in this language.

------
mhuangw
Definitely seems more practical than the other pony language, FIM++

