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

Pony – High-Performance Safe Actor Programming

ponylang.io

Post reply on HN
Print view View original

121–130 of 159 posts

Re: Pony – High-Performance Safe Actor Programming

#121

Post by pixel_fcker »

throwaway894345 wrote: post #79
ibraheemdev wrote: post #48

Earlier quoted context omitted.

This sounds a lot like someone learning Rust. Both languages solve similar problems with very different solutions that come with complexity overhead.

At least with Rust, very few domains involve so much parallelism that one benefits from the overhead that the borrow checker adds to the development process. And many times the borrow checker is completely inadequate at preventing race conditions (frequently the case with distributed computing). Of course, Rust can recoup those losses elsewhere, by having better tooling or competing in domains where performance matte…

What domain is that?

Re: Pony – High-Performance Safe Actor Programming

#123

Post by magicalhippo »

spooneybarger wrote: post #112
jgilias wrote: post #110

Earlier quoted context omitted.

It's sort of a general question though. What happens if I use a C library from Pony that does or can potentially do unsafe things. I'm not sure I understand how such situations can be solved without some kind of a locking mechanism. I mean, the answer can be 'just rewrite the underlying library in Pony'. Which would be fair enough.

That's an incredibly general question. "It depends on the specifics" would be the general answer. Once you use FFI, there's no guarantee of memory safety as the C code has access to the entire address space of the process. There is no sandboxing of foreign code at this time. If the code you are calling isn't thread safe and you run your Pony program with more than 1 scheduler thread (pony actors get run on 1 or more…

> maybe you can structure the Pony API so that you don't do that

So from what I could gather from a quick glance through the tutorial, that would be to restrict the C code calls to a single actor, and have other actors call, I guess primarily through the async behaviors?

Re: Pony – High-Performance Safe Actor Programming

#124

Post by magicalhippo »

ergl wrote: post #33
ibraheemdev wrote: post #29

Earlier quoted context omitted.

I think you should consider showing some code on the front page, like D [0] or Ruby [1], or maybe have a "Try Pony" button that links to an online playground. 0: https://dlang.org/ 1: https://www.ruby-lang.org/en/

We do have an online playground! You can try it here: https://playground.ponylang.io/ It's linked from the page, but we should make it more obvious.

Even when I knew it was there it took me a while to find it, so yeah, at the very least put it under its own header, first or second one.

Re: Pony – High-Performance Safe Actor Programming

#125

Post by spooneybarger »

magicalhippo wrote: post #123
spooneybarger wrote: post #112

Earlier quoted context omitted.

That's an incredibly general question. "It depends on the specifics" would be the general answer. Once you use FFI, there's no guarantee of memory safety as the C code has access to the entire address space of the process. There is no sandboxing of foreign code at this time. If the code you are calling isn't thread safe and you run your Pony program with more than 1 scheduler thread (pony actors get run on 1 or more…

> maybe you can structure the Pony API so that you don't do that So from what I could gather from a quick glance through the tutorial, that would be to restrict the C code calls to a single actor, and have other actors call, I guess primarily through the async behaviors?

That would be the general approach if possible with c code that isn't thread safe. It's a matter of if that is possible with a given library (it's difficult for example with GTK).

Re: Pony – High-Performance Safe Actor Programming

#126

Post by throwaway894345 »

pixel_fcker wrote: post #121
throwaway894345 wrote: post #79

Earlier quoted context omitted.

At least with Rust, very few domains involve so much parallelism that one benefits from the overhead that the borrow checker adds to the development process. And many times the borrow checker is completely inadequate at preventing race conditions (frequently the case with distributed computing). Of course, Rust can recoup those losses elsewhere, by having better tooling or competing in domains where performance matte…

What domain is that?

Distributed systems

Re: Pony – High-Performance Safe Actor Programming

#127

Post by throwaway894345 »

staticassertion wrote: post #99
throwaway894345 wrote: post #85

Earlier quoted context omitted.

Right, I should have said "race conditions"; it hadn't occurred to me that the two weren't synonymous. My point wasn't that Pony does prevent race conditions, but rather that non-data-race race conditions are much more common in my domain (distributed computing) or really any domain where multiprocess architectures are common so I don't benefit much from the static guarantees that Rust affords.

Pony does not prevent race conditions. Two actors can wait forever for the other to send a message, deadlocking.

I didn’t say that Pony prevents race conditions. I agree that Pony (nor indeed any language) prevents race conditions.

Re: Pony – High-Performance Safe Actor Programming

#128

Post by pvg »

eindiran wrote: post #117
spooneybarger wrote: post #115

Earlier quoted context omitted.

i hope you have a tool that pulls all those links together for you.

I think the tool is probably this one: https://hn.algolia.com/

dang simply remembers all the item?id=N. Which is easy because they're sequential. To make the list, mentally go through the numbers and paste in the urls that are relevant.

Re: Pony – High-Performance Safe Actor Programming

#129

Post by yokljo »

throwaway894345 wrote: post #79
ibraheemdev wrote: post #48

Earlier quoted context omitted.

This sounds a lot like someone learning Rust. Both languages solve similar problems with very different solutions that come with complexity overhead.

At least with Rust, very few domains involve so much parallelism that one benefits from the overhead that the borrow checker adds to the development process. And many times the borrow checker is completely inadequate at preventing race conditions (frequently the case with distributed computing). Of course, Rust can recoup those losses elsewhere, by having better tooling or competing in domains where performance matte…

Rust's borrow checker is not only for multi threading and memory safety. It allows someone designing an API for any kind of data structure to guarantee that the user is using it correctly, by making their code not compile when they are using it incorrectly (basically what any type system provides, but fancier). What you call borrow checker overhead, some would call fixing problems before they occur.

Re: Pony – High-Performance Safe Actor Programming

#130

Post by hntemppony »

haskellandchill wrote: post #52

Anyone know the judgement rules behind the interesting parts of Pony's type system? I'm about to crack the dissertation to see what's up but would love a concise description. https://www.ponylang.io/media/papers/a_prinicipled_design_of...

The interesting parts:

Capabilities describe both uniqueness and read-write ability. `iso` is fully unique and hence sendable, `trn` and `val` are write-unique (but `val` is also sendable since it isn't writable). The `tag` capability allows identity/message sending and is fully sendable

Recover blocks and automatic receiver recovery allow creation/usage of isolated data if only sendables are used from the external environment.

Only sendables can be included in messages.

Actors have `ref` access to themselves but `tag` access to other actors.

Post reply on HN