Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pony: An actor-model, capabilities-secure, high-performance programming language

ponylang.io

Post reply on HN
Print view View original

71–80 of 284 posts

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#71

Post by gpderetta »

> Deadlock-Free: This one is easy because Pony has no locks at all! So they definitely don’t deadlock, because they don’t exist! This really annoys me every time I read Pony description. What does deadlock free even mean here? Deadlock-free is typically the property of an algorithm, not a language.

Does pony guarantees forward progress in all cases? Does it means that if I tried to implement a python interpreter in Pony it will statically reject the implementation? Requires me to submit a proof of deadlock freedom with any program I feed the interpreter? Or any python program running on this interpreter is magically free of deadlocks?

edit: as an aside, deadlocks have little to do with locks.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#72

Post by gpderetta »

alfanerd wrote: post #70
gpderetta wrote: post #61

Earlier quoted context omitted.

Unless you have NxN queues across actors[1], which is done on some specialized software but is inherently not scalable, queues will end up being more complex than that. [1] at the very least you will need one queue for each cpu pair, but that's yet another layer of complication.

I think you only need one queue per actor? And then one worker per CPU core? I believe that how Erlang does it, and do millions of actors without any issues...

Yes, but now you have contention on the queue.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#73

Post by jibal »

arethuza wrote: post #67
jibal wrote: post #65

Earlier quoted context omitted.

Or not. Mostly not in this case.

I agree, in the case of Pony the interesting stuff is mentioned on this page: https://www.ponylang.io/discover/why-pony/ Syntax doesn't really come into it. Edit: I'm as fond of discussions of the design of programming language syntax as everyone else - just in this case the apparent novelty of Pony is at a more fundamental level.

Indeed. I wonder how many people here even read the title of the post.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#74

Post by CharlieDigital »

pjmlp wrote: post #45

Without wanting to derail the conversation too much. Its original designer, Sylvan Clebsch, is nowadays working at Microsoft Research on languages like Verona [0], the last paper he contributed to, which has Guido as well among the collaborators, is about adding regions to dynamic languages, using Python as example implementation, https://www.microsoft.com/en-us/research/publication/dynamic... [0] - https://www.micro…

Notable the Microsoft has not one but two actor model "frameworks": Orleans (for .NET) and Dapr Actors (for containerized workloads).

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#75

Post by BlanketLogic »

gpderetta wrote: post #71

> Deadlock-Free: This one is easy because Pony has no locks at all! So they definitely don’t deadlock, because they don’t exist! This really annoys me every time I read Pony description. What does deadlock free even mean here? Deadlock-free is typically the property of an algorithm, not a language. Does pony guarantees forward progress in all cases? Does it means that if I tried to implement a python interpreter in P…

It is based on actors and "reference capabilities". These two blogs[1,2], could provide nice introduction.

1. https://blog.jtfmumm.com//2016/03/06/safely-sharing-data-pon... 2. https://bluishcoder.co.nz/2017/07/31/reference_capabilities_...

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#76

Post by adwn »

alfanerd wrote: post #58
adwn wrote: post #36

> The standard way to avoid these problems is to use locks to prevent data updates from happening at the same time. This causes big performance hits […] No. Modern mutex implementations [1] are extremely efficient, require only 1 byte of memory (no heap allocation), and are almost free when there's no contention on the lock – certainly much faster and much lower latency than sending messages between actors. [1] Like…

Sending a message between Actors can be just moving a pointer to a piece of shared memory. I think sending messages is more about the way you think about concurrency, more than the implementation. I have always found the "one thread doing "while True receive message, handle message" much easier to reason about than "remember to lock this chunk of data in case more than one thread should access it"

> Sending a message between Actors can be just moving a pointer to a piece of shared memory.

No, you also need synchronization operations on the sending and the receiving end, even if you have a single sender and a single receiver. That's because message queues are implemented on top of shared memory – there's no way around this on general-purpose hardware.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#77

Post by adwn »

adwn wrote: post #36

> The standard way to avoid these problems is to use locks to prevent data updates from happening at the same time. This causes big performance hits […] No. Modern mutex implementations [1] are extremely efficient, require only 1 byte of memory (no heap allocation), and are almost free when there's no contention on the lock – certainly much faster and much lower latency than sending messages between actors. [1] Like…

Why is this downvoted? It's factually correct, on-topic, and relevant (because it contradicts a claim on the linked website). If you disagree, say so and we can discuss it.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#78

Post by adwn »

alfanerd wrote: post #58
adwn wrote: post #36

> The standard way to avoid these problems is to use locks to prevent data updates from happening at the same time. This causes big performance hits […] No. Modern mutex implementations [1] are extremely efficient, require only 1 byte of memory (no heap allocation), and are almost free when there's no contention on the lock – certainly much faster and much lower latency than sending messages between actors. [1] Like…

Sending a message between Actors can be just moving a pointer to a piece of shared memory. I think sending messages is more about the way you think about concurrency, more than the implementation. I have always found the "one thread doing "while True receive message, handle message" much easier to reason about than "remember to lock this chunk of data in case more than one thread should access it"

> I think sending messages is more about the way you think about concurrency, more than the implementation.

That's a valid point of view, but Pony's claim to which I objected is about performance, not ease-of-use or convenience.

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#79

Post by quotemstr »

jibal wrote: post #49
poulpy123 wrote: post #44

Earlier quoted context omitted.

> The syntax is the least interesting thing about the language, and hello-world examples demonstrate almost none of the syntax. I agree for the hello world but I disagree with the syntax. It is the first thing you see and the characteristic you can never escape. It is like the layout and typesetting of a text: the substance is of course more important, but it is still very important. I personally find much more reada…

For Pony in particular, the syntax is not important ... it's simply not the point of the language.

[flagged]

Re: Pony: An actor-model, capabilities-secure, high-performance programming language

#80

Post by stared »

voidUpdate wrote: post #3

I wish these language websites would put an example of some code right there on the homepage so I can see what the language "feels" like. I finally found some code in the tutorials https://tutorial.ponylang.io/getting-started/hello-world

Also it took surprisingly many clicks to see any code. After 3 clicks I had impression that it is not yet a language, just and idea for one.
Post reply on HN