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

51–60 of 284 posts

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

#51

Post by otabdeveloper4 »

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…

A contended mutex is a system call and likely stalls all the CPUs on your machine.

Lockfree spinlocks will only waste cycles on one CPU. A huge difference when you have dozens and hundreds of cores.

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

#52

Post by zelphirkalt »

burnt-resistor wrote: post #5

Notable for the GC (ORCA) and the sharing model. They have a Zulip[0] and a weekly office hours. Sylvan Clebsch is now working on Project Verona[1]. 0. https://ponylang.zulipchat.com 1. https://www.microsoft.com/en-us/research/project/project-ver...

Having a Zulip (preferably self hosted) is sympathetic, compared to having shitty options like Slack. It indicates, that the people care about privacy. A zulip chat I would consider visiting, a Slack would be a hard pass.

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

#53

Post by SiempreViernes »

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.

Having looked at some source examples, I'm pretty sure Pony has syntax errors just like every other parsed language.

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

#55

Post by jibal »

SiempreViernes wrote: post #53
jibal wrote: post #49

Earlier quoted context omitted.

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

Having looked at some source examples, I'm pretty sure Pony has syntax errors just like every other parsed language.

We must not be communicating clearly, because that doesn't seem to me to have anything to do with what I wrote. I thought it was clear that the discussion was about the syntactic specifics of programming languages. I certainly wasn't claiming that Pony doesn't have a syntax, or that it's not important to use the correct syntax to write a Pony program.

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

#56

Post by adwn »

otabdeveloper4 wrote: post #51
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…

A contended mutex is a system call and likely stalls all the CPUs on your machine. Lockfree spinlocks will only waste cycles on one CPU. A huge difference when you have dozens and hundreds of cores.

> A contended mutex is a system call […]

Because modern mutexes are so cheap (only 1 byte directly in the data structure, no heap allocation), you can do very fine-grained locking. This way, a mutex will almost never be contended. Keep in mind that a reader waiting on an empty queue or a writer waiting on a full queue will also involve syscalls.

> […] and likely stalls all the CPUs on your machine.

Huh? Where did you get this idea? Only the waiting thread will be blocked, and it won't "stall" the core, let alone the entire CPU.

By the way, if all your threads are waiting on a single mutex, then your architecture is wrong. In the equivalent case, all your actors would be waiting on one central actor as well, so you'd have the same loss of parallelism.

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

#57

Post by xnorswap »

zelphirkalt wrote: post #54

As always with the languages, I think about what the ecosystem looks like. What libraries exist? Seems there is a list of available packages on their website: https://www.ponylang.io/use/packages/

I clicked one at random (net_ssl) to get a sense of what a package looked like in this ecosystem and how to install it, but it takes you straight to a github page which says it's deprecated and to use a different package (ssl) instead, which is not listed on the packages page.

Not a great look, although it looks like it was only deprecated 2 weeks ago, so I'll give them a pass.

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

#58

Post by alfanerd »

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"

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

#59

Post by pxeger1 »

jibal wrote: post #20
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

The syntax is the least interesting thing about the language, and hello-world examples demonstrate almost none of the syntax. This bit from the About page is notable: "never write a programming language. That’s like rule #1. Everybody will just tell you it isn’t needed and then argue about syntax."

The designer's syntax decisions tell you a lot about their semantic decisions, which languages they take inspiration from, and the language's philosophy about things like flexibility, correctness, and opinionatedness.

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

#60

Post by gpderetta »

otabdeveloper4 wrote: post #51
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…

A contended mutex is a system call and likely stalls all the CPUs on your machine. Lockfree spinlocks will only waste cycles on one CPU. A huge difference when you have dozens and hundreds of cores.

So does a contended queue. As much as I might like the model, message passing is not a silver bullet. Any sufficiently complex message passing system will end up implementing shared memory on top of it... and mutexes.
Post reply on HN