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

101–110 of 159 posts

Re: Pony – High-Performance Safe Actor Programming

#101

Post by staticassertion »

mcguire wrote: post #94
ivanbakel wrote: post #56

Earlier quoted context omitted.

Pony and Rusts' solutions to the concurrency problem are almost identical - forbid shared mutability through the type system. In what way are they very different?

Rust is essentially C++ with restrictions that make threads safer. Pony is a completely new language based on the actor model where "threading" is a first-class operation and the type system is formally designed to make guarantees that make threads safer. Pony really wants you to think differently about your problem and solution.

While Pony is awesome, I think what you describe is a weakness and not a strength. If Pony were to move more of its hardest concepts to standard libraries, it would be a far simpler language, even if it maintained the actor/behavior concepts.

Much of Pony can be done with Arc/Mutex/&/move in Rust, but with special syntax, and it's that special syntax that kills the language frankly.

You can implement actors in Rust pretty easily. I've done it multiple times, including in a way that provides a pony-like nominal interface. It isn't as powerful, and it isn't as efficient, because frankly I'm not very good at this sort of thing and don't have time to work on it, but it's possible.

What pony gives is some syntactic sugar in some important places (the actor keyword, the be keyword) and a very strong runtime.

Re: Pony – High-Performance Safe Actor Programming

#102

Post by mateo411 »

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.

Is deadlock considered a race condition?

I typically think of a race condition an issue with concurrency where data might be modified by another thread which causes the program to return incorrect results.

Re: Pony – High-Performance Safe Actor Programming

#103

Post by spooneybarger »

jgilias wrote: post #95

Ok, so let's take an example. In a very hand-wavy way, the ZeroMQ messaging queue works without a central messaging broker or service, but purely as a library. In theory, you can implement ZMQ messaging primitives in your language of choice, but this is a lot of work, so it is usually used through bindings to libzmq C library. I don't know exactly how it works, but at some point it writes things to some memory addres…

I don't know enough about ZMG to answer this. What little I know about it is mostly from a pure Pony version that a member of the core team worked on quite some time ago.

Joe is probably the best person to talk to if you want to use ZMG as a reference point, you can find him on the Pony Zulip.

https://ponylang.zulipchat.com/#

Re: Pony – High-Performance Safe Actor Programming

#104

Post by spooneybarger »

carapace wrote: post #92
spooneybarger wrote: post #67

Earlier quoted context omitted.

That really depends on your idea of what makes something a good choice. Most web apps generally need a lot of libraries to be "a good choice". Pony is lacking in libraries for "web development", so you'd need to do a lot of work that you wouldn't in other languages. That's the case with most areas with Pony. You'll invest time in developing libraries you wouldn't in many other languages. In return, you get the nice l…

Thanks for taking the time to reply. (FWIW, I'm in the market for a new language. I've been mostly using Python in the past, but now I want something like Erlang or Pony, or maybe Nim, or Zig or D or OCaml or ...?) It sounds like there is not (yet!) a package like Cowboy for Erlang for Pony? There is TCP server support but not HTTP and Rails-like stuff, eh? If you don't mind me asking, what about using SQLite from Po…

There's an http server and a small "sinatra" like web framework.

- https://github.com/ponylang/http_server

- https://github.com/theodus/jennet

Someone might have done SQLite for Pony, but I'm not aware of it. Writing network protocol stuff in Pony is usually pretty easy and the C-FFI is usually pretty easy which generally makes writing database connectivity (for at least happy path basics) fairly easy. (Add lots of caveats here).

If you'd like to talk more in-depth, swing by the Zulip and myself and other folks from the community can help out with answers.

https://ponylang.zulipchat.com/

Re: Pony – High-Performance Safe Actor Programming

#105

Post by gpderetta »

mateo411 wrote: post #102
staticassertion wrote: post #99

Earlier quoted context omitted.

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

Is deadlock considered a race condition? I typically think of a race condition an issue with concurrency where data might be modified by another thread which causes the program to return incorrect results.

You can have race conditions with message passing.

Re: Pony – High-Performance Safe Actor Programming

#106

Post by pjmlp »

Kwpolska wrote: post #88
dkarl wrote: post #78

Earlier quoted context omitted.

That comment might be for programmers coming from languages where filenames do matter to the compiler, or languages like Java where the convention is so universally followed that many programmers don't know you can break it. Someone programming for the first time already "knows" that filenames don't matter, so it's probably not for them.

In Java, the “each public class is in its own file named after the class” rule is enforced by the compiler and there’s no switch to disable this behavior.

True, but many don't realize that package private and "friend" classes can share the same source file.

Re: Pony – High-Performance Safe Actor Programming

#107

Post by spooneybarger »

mateo411 wrote: post #102
staticassertion wrote: post #99

Earlier quoted context omitted.

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

Is deadlock considered a race condition? I typically think of a race condition an issue with concurrency where data might be modified by another thread which causes the program to return incorrect results.

I think this might help:

Data race vs race condition:

https://blog.regehr.org/archives/490

Re: Pony – High-Performance Safe Actor Programming

#108

Post by mateo411 »

gpderetta wrote: post #105
mateo411 wrote: post #102

Earlier quoted context omitted.

Is deadlock considered a race condition? I typically think of a race condition an issue with concurrency where data might be modified by another thread which causes the program to return incorrect results.

You can have race conditions with message passing.

Yes, that makes sense.

A race condition happens when data/state is mutated because of the order in which concurrent processes occur. This could happen with threads, message passing, or many other ways.

I think this is distinct from deadlock which occurs when there is at least one circular dependency in the order when different "processes" must perform their operations.

Re: Pony – High-Performance Safe Actor Programming

#109

Post by pierrebai »

How about, in C++, doing:

template using shared_immutable = std::shared_ptr;

template using isolated = std::unique_ptr;

That's basically how you'd guarantee that shared data is immutable and data passed along is held by only one thread.

Sure, sure, if you try, you can explicitly take out raw pointers out of them. You can also take an axe to your computer but, as they say, "just don't do that".

Re: Pony – High-Performance Safe Actor Programming

#110

Post by jgilias »

spooneybarger wrote: post #103
jgilias wrote: post #95

Ok, so let's take an example. In a very hand-wavy way, the ZeroMQ messaging queue works without a central messaging broker or service, but purely as a library. In theory, you can implement ZMQ messaging primitives in your language of choice, but this is a lot of work, so it is usually used through bindings to libzmq C library. I don't know exactly how it works, but at some point it writes things to some memory addres…

I don't know enough about ZMG to answer this. What little I know about it is mostly from a pure Pony version that a member of the core team worked on quite some time ago. Joe is probably the best person to talk to if you want to use ZMG as a reference point, you can find him on the Pony Zulip. https://ponylang.zulipchat.com/#

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.

Post reply on HN