[HN Gopher] Pony - High-Performance Safe Actor Programming
       ___________________________________________________________________
        
       Pony - High-Performance Safe Actor Programming
        
       Author : ibraheemdev
       Score  : 246 points
       Date   : 2021-01-29 14:03 UTC (8 hours ago)
        
 (HTM) web link (www.ponylang.io)
 (TXT) w3m dump (www.ponylang.io)
        
       | lngnmn1 wrote:
       | For me this is the language mentioned by Joe Armstrong as
       | "interesting". However, it looks like poorly designed, with
       | cluttered, messy syntax and a kitchen sing syndrome.
       | 
       | Over-"engineering" is the second root of all evil, after
       | unnecessary, redundant abstractions.
        
       | namelosw wrote:
       | First Erlang/Elixir, then Ruby 3, now Python. It's great that
       | people are picking up the good idea once again.
       | 
       | Most of the time the Promise/Future or async/await add mental
       | overhead to code just for the sake of performance (because the
       | monadic operations are only for sequential operations, it only
       | make sense for applicative/parallel operations to use async/await
       | if we don't care about performance). And with the Actor model,
       | you don't need to use Promise or async 9 out of 10 times as you
       | would in most languages without sacrifice performance.
        
       | sbarre wrote:
       | For anyone wondering "Why Pony?" - they have a section called
       | just that:
       | 
       | https://www.ponylang.io/discover/#why-pony
        
         | [deleted]
        
         | Supermancho wrote:
         | There still isn't anything there that Erlang doesn't already
         | have, excepting the theoretically-strong reference
         | capabilities...which is what got me watching pony for a couple
         | years.
         | 
         | Pony needs to have something that shows how it's references are
         | more/differently useful in a multi-actor program. I suspect
         | that's a tall order.
        
           | rowland66 wrote:
           | I think that the first sentence on the why Pony page says it
           | all
           | 
           | "There's plenty to love about Pony, but more than anything
           | else, what we love most is that Pony makes it easy to write
           | fast, safe, efficient, highly concurrent programs."
           | 
           | In Erlang you can write safe highly concurrent programs, but
           | you might struggle with fast and efficient. Of course, how
           | much fast and efficient you need depends on what you are
           | trying to do.
        
           | ergl wrote:
           | One thing that reference capabilities allow you to do is pass
           | data between actors without copying. Erlang is very eager in
           | copying almost everything you put in a message to a process
           | (with the expection of big binaries, etc).
           | 
           | Whether this is has a big impact on running systems remains
           | to be seen, Erlang is very good at quickly collecting data.
           | 
           | Another thing that I would say Pony has that Erlang doesn't
           | is an easy FFI mechanism. You can write NIFs for Erlang, but
           | in my experience writing native code or wrapping C libraries
           | has been much easier in Pony.
        
             | dnautics wrote:
             | > Another thing that I would say Pony has that Erlang
             | doesn't is an easy FFI mechanism
             | 
             | (Disclaimer, self-promotion):
             | 
             | It doesn't get easier than this:
             | https://hexdocs.pm/zigler/Zig.html
             | 
             | (I'll be dropping direct c support in there in the next
             | release)
        
               | ergl wrote:
               | Zigler looks interesting! I've given it a look before,
               | would be very nice if it could support Erlang too, but I
               | imagine Elixir macros are doing a lot of work for you.
               | 
               | I think the biggest hurdles when writing NIFs are:
               | 
               | * Interacting with Erlang terms from C/Rust/Zig.
               | Admittedly both zigler and rustler help in this regard,
               | by wrapping Erlang terms. Pony is able to expose raw
               | pointers and structs to C, which I've felt easier to work
               | with.
               | 
               | * Dealing with the Beam's preemptive scheduler. This
               | isn't as big of a problem now with dirty schedulers but
               | still a mismatch compared to normal Erlang code. Pony
               | uses a cooperative scheduler everywhere, so you'll
               | already be used to splitting long tasks in different
               | steps by the time you need to use the FFI, which makes
               | the transition easier.
        
               | dnautics wrote:
               | re: preemptive scheduler:
               | 
               | https://www.youtube.com/watch?v=l848TOmI6LI
               | 
               | (this is an old api, there is a new api that makes the
               | modes completely interchangeable:
               | https://www.youtube.com/watch?v=kpRK9BC0-I8)
        
           | speed_spread wrote:
           | Totally subjective, but one thing I'd give Pony over Erlang
           | is likable, consensual syntax. Erlang is weird, for no
           | particular reason.
        
         | Someone wrote:
         | That didn't answer the question I expected it to answer ("why
         | Pony and not Brando, Gielgud, Nicholson, Streep...?"
        
           | inetsee wrote:
           | I am confused. Doing a search for "(Brando, Gielgud,
           | Nicholson, Streep) programming language" turns up nothing.
        
             | throwaway744678 wrote:
             | I believe OP tried a joke, by naming famous actors - Pony
             | being an actor programming language.
        
           | karmakaze wrote:
           | You might be looking for "An Early History of Pony"[0] linked
           | in the FAQ.
           | 
           | [0] https://www.ponylang.io/blog/2017/05/an-early-history-of-
           | pon...
        
       | mardiyah wrote:
       | So eager if one'd have done a benchmark with rust
        
         | rowland66 wrote:
         | I don't really think that a comparison to Rust is all that
         | useful. Rust and Pony are really intended for different
         | purposes. Rust is systems programming language. Pony is an
         | application programming language that provides an actor model
         | for concurrent programming and a runtime to support the actors
         | and perform garbage collection.
         | 
         | A valid comparison would be to compare a Pony program to
         | specific type of Rust program that involves considerable
         | concurrent processing of data.
         | 
         | Pony's killer feature is a type system that allows programs to
         | be written that are guaranteed to be safe from concurrency
         | bugs. Like Rust, the Pony compiler is based on LLVM, and Pony
         | programs compile to native code. Due to the Pony type system,
         | the Pony GC is very efficient. Pony performance is pretty good,
         | but as a language Pony is about much more than performance.
        
       | niclash wrote:
       | As a regular Pony user, and coding seriously in it for a few
       | months, this is what I think;
       | 
       | I rather fight the Reference Capabilities (easily the hardest
       | aspect of Pony and probably the number one reason people give up)
       | than to spend endless amount of time CHASING concurrency
       | problems, or even worse, HOPING that I didn't forget some
       | lock/mutex/whatever and ending up having data corruption.
       | 
       | Pony is forcing me to do the right thing, and doesn't allow me to
       | "I guess I could get away with X", and this reassurance is a huge
       | boon.
       | 
       | It is hard to learn, and if you are not in the concurrency space,
       | don't know what a thread is and don't care much for data
       | integrity, then Pony is not for you. The effort you need to put
       | in will not be appreciated by you.
       | 
       | If you have a strong opinion on how things must be done, Pony is
       | not for you, because it won't allow you to follow your opinion
       | all the time, because the opinion is not safe.
       | 
       | Pony is not for everyone, but for those that can think in the
       | Pony model, then it is an incredible tool to ensure your code is
       | correct, safe and performant.
        
         | niclash wrote:
         | And the Pony community has helped me out at every turn of
         | confusion and getting my head twisted into the Pony model. Big
         | kudos to them...
        
         | ibraheemdev wrote:
         | This sounds a lot like someone learning Rust. Both languages
         | solve similar problems with very different solutions that come
         | with complexity overhead.
        
           | agumonkey wrote:
           | ^ seconded
        
           | ivanbakel wrote:
           | 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?
        
             | niclash wrote:
             | I am not an expert in Rust's mechanics and only looked at
             | it superficially, but I got the impression that shared
             | references can't be guaranteed (to not exist in mutable
             | ways) all the way through an object graph. I am not
             | surprised if I am wrong about that. It wasn't the main
             | deciding factor for me...
             | 
             | My primary factor was "Actor Model" and I was struggling
             | with Erlang's lack of static types, so that put Pony in the
             | focus. An Actor Model framework on top (I recalled there
             | was one for Rust) had given me "questionable" results with
             | Akka (due to compromises/constraints in the JVM and
             | Java/Scala).
             | 
             | HTH
        
               | Nullabillity wrote:
               | In safe Rust, all mutation must be either:
               | 
               | - Statically verified to be unique (&mut)
               | 
               | - Dynamically verified to be unique (RefCell)
               | 
               | - Behind a lock (Mutex, RwLock)
               | 
               | - Explicitly opt into weaker (but still consistent)
               | guarantees (atomics)
               | 
               | - Some other abstraction built on those primitives (like
               | channels)
               | 
               | Unsafe does exist, but it's something that the code must
               | explicitly opt into, and they rules that must be followed
               | are generally "the same" across the whole Rust ecosystem
               | (rather than just accidentally stumbling into something
               | that is OK in "normal" Scala but breaks some weird Akka
               | rule).
               | 
               | In any case, the language enforces that you are self-
               | consistent: if you use locks as your escape hatch for
               | something then the code won't compile if you try to
               | access it without an active lock.
        
               | ibraheemdev wrote:
               | There are a couple of Rust actor frameworks, the most
               | popular being actix [0] and bastion [1]
               | 
               | 0: https://github.com/actix/actix 2: https://bastion.rs/
        
               | haggy wrote:
               | What issues did you run into on the JVM with Java/Scala?
               | I spent 5 years working up and down the entire akka stack
               | so I'm curious to learn from your point of view. Also did
               | you try akka typed or classic?
        
               | siscia wrote:
               | There are some escape hatches to get shared mutable
               | reference. But in general those are impossible in rust.
        
               | ibraheemdev wrote:
               | Are they really "escape hatches"? Shared mutable state is
               | as simple as `Rc::new(RefCell::new(x))`, or
               | `Arc::new(Mutex::new(x))` for thread safety.
        
               | siscia wrote:
               | `Arc<Mutex<T>>` is not a shared mutable state. You cannot
               | have two mutable reference at the same time. To mutate
               | stuff inside the mutex, you got to hold the mutex, which
               | guarantees that there are only one mutable reference at
               | any given moment.
               | 
               | `RefCell` is one "escape hatches".
        
             | mcguire wrote:
             | 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.
        
               | staticassertion wrote:
               | 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.
        
           | throwaway894345 wrote:
           | 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 matters a lot, but I've not found
           | the safety to be worthwhile in my domain.
           | 
           | EDIT: s/data races/race conditions
        
             | nextaccountic wrote:
             | > And many times the borrow checker is completely
             | inadequate at preventing data races (frequently the case
             | with distributed computing).
             | 
             | The borrow checker (in safe rust) always[0] prevents data
             | races. It can't, however, prevent race conditions (but
             | neither can pony do[1])
             | 
             | [0] https://doc.rust-lang.org/nomicon/races.html
             | 
             | [1] https://www.ponylang.io/faq/#data-race
        
               | throwaway894345 wrote:
               | 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.
        
               | staticassertion wrote:
               | Pony does not prevent race conditions. Two actors can
               | wait forever for the other to send a message,
               | deadlocking.
        
               | mateo411 wrote:
               | 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.
        
               | spooneybarger wrote:
               | I think this might help:
               | 
               | Data race vs race condition:
               | 
               | https://blog.regehr.org/archives/490
        
               | mateo411 wrote:
               | That is helpful. I was thinking that a race condition
               | would only include a data race, but this blog defined it
               | broader, so that it would include deadlock.
        
               | gpderetta wrote:
               | You can have race conditions with message passing.
        
               | mateo411 wrote:
               | 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.
        
               | stouset wrote:
               | Deadlock is one common _symptom_ of a race condition.
        
       | pjettter wrote:
       | I like Elixir, Erlang. There is Lumen, an OS initiative to bring
       | the BEAM to the browser (WASM).
       | 
       | Does Pony have such ambitions (I mean, the Pony team)?
       | 
       | My UC is an actor system in the browser and the ability to create
       | a DSL created using the same language used in programming the
       | actor system.
       | 
       | Pony is not dynamic but statically typed? Maybe it can be
       | overcome by substituting actors since any actor can create any
       | other actor?
       | 
       | Plus I'm interested in graphics. I googled but didn't see any
       | examples of integrating either web or desktop graphics, like
       | Skia.
        
         | sp33der89 wrote:
         | Since Pony uses LLVM, it should be possible to compile to WASM.
         | Not sure if it's on the immediate roadmap of the Pony team. But
         | I don't think the effort is as big as Lumen.
         | 
         | As far as graphics go, I'd say Pony is quite early stage for
         | such elaborate API's like Skia.
        
         | ibraheemdev wrote:
         | There is also the Lunatic VM [0] which is an actor system built
         | with Rust targeting WASM on the server.
         | 
         | 0: https://github.com/bkolobara/lunatic
        
       | pierrebai wrote:
       | How about, in C++, doing:
       | 
       | template <class T> using shared_immutable = std::shared_ptr<const
       | T>;
       | 
       | template <class T> using isolated = std::unique_ptr<T>;
       | 
       | 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".
        
       | lukeasrodgers wrote:
       | I've only done hobby stuff with pony, but love the idea of it,
       | and would love an opportunity to use it in production. I've found
       | the community welcoming and helpful in my limited interactions.
       | The standard library code is pretty easy to read, which somewhat
       | mitigates the dearth of tutorials, howtos on the internet.
       | 
       | The reference capability stuff can be a bit hard to wrap your
       | mind around, but mostly in a good way, and the compiler errors
       | are generally pretty helpful. If you come from an OO or
       | procedural background, there will be a sharp learning curve. My
       | experience of learning pony reference capabilities is roughly
       | similar (in terms of forcing you to think differently about data
       | sharing) to learning how to work with the rust borrow checker,
       | despite them having different goals and operational models.
        
         | zem wrote:
         | what sort of hobby stuff do you do with pony? the language
         | looks interesting but i've been unable to think of any
         | compelling reasons to use it.
        
         | ibraheemdev wrote:
         | > If you come from an OO or procedural background, there will
         | be a sharp learning curve.
         | 
         | Isn't Pony object oriented?
        
           | spooneybarger wrote:
           | It's in our tag line. But what OO means varies from person to
           | person. There's no set definition of it.
           | 
           | Pony features classes and actors are like classes that can
           | receive asynchronous messages.
           | 
           | However, unlike some OO, there's no inheritance. Unlike a lot
           | of other OO there's a heavy emphasis on asynchronous
           | messaging.
           | 
           | I wouldn't use "OO background" as an indicator of what might
           | make Pony harder to learn. I think the key parts are
           | experience with rigorous type systems and experience with
           | concurrency. Without a background in those, your path to
           | learning Pony will be harder than the path for someone who is
           | already familiar with them.
        
         | mcintyre1994 wrote:
         | What sort of hobby projects have you found it a good match for
         | out of interest?
        
       | gdsdfe wrote:
       | it's really frustrating seeing these programming languages
       | websites where you have to click in a million place before you
       | can even see what the code looks like
        
         | protomyth wrote:
         | Is there an a page with more than a few lines of code to show
         | what actual Pony programs look like?
        
           | spooneybarger wrote:
           | There are a number of simple examples in the ponyc repo:
           | 
           | https://github.com/ponylang/ponyc/tree/master/examples
           | 
           | You can find a number of pony library projects under the
           | ponylang org on GitHub:
           | 
           | https://github.com/ponylang/
        
             | ibraheemdev wrote:
             | 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/
        
               | ergl wrote:
               | 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.
        
             | waynesonfire wrote:
             | Thanks, exactly what I needed to be confident that I should
             | move on.
        
           | imglorp wrote:
           | See also the Patterns part of the tutorial.
           | 
           | https://patterns.ponylang.io/
        
         | benstrumental wrote:
         | Do you have some examples of programming language websites you
         | do like?
        
           | [deleted]
        
           | ibraheemdev wrote:
           | I really like Crystal's website [0]. It lets the code to the
           | talking and has nice big buttons for "Install", "Learn", and
           | "Try Online".
           | 
           | 0: https://crystal-lang.org/
        
           | dunefox wrote:
           | https://flix.dev/
           | 
           | This is the best page I have seen so far.
        
           | gdsdfe wrote:
           | the few that come to mind : Elvish : https://elv.sh/ Flix :
           | https://flix.dev/ Crystal : https://crystal-lang.org/ Nim :
           | https://nim-lang.org/
        
           | ccmcarey wrote:
           | Go is probably the best for this, it gives you a REPL on the
           | homepage itself: https://golang.org/
        
             | mrec wrote:
             | And Rust has https://play.rust-lang.org/ - not a REPL, but
             | a chance to kick the tyres before downloading anything.
        
       | [deleted]
        
       | faichai wrote:
       | Does anyone remember the actor based programming language Joule
       | [1]? It had a manual, and maybe some kind of private prototype,
       | but never a public release as far as I know.
       | 
       | How does Pony relate to Joule? They seem to be on a continuum,
       | what with Actors, object capabilities etc.
       | 
       | [1] http://www.cap-lore.com/Agorics/Library/joule.html
        
         | speed_spread wrote:
         | I recently read that a development branch of Java had Joule-
         | based Capabilities, but that the SecurityManager model was
         | ultimately preferred for simplicity. What a loss.
        
       | Asmod4n wrote:
       | I still am wondering how error handling should be done in pony,
       | it only tells you an error has happend, not what has caused it or
       | what kind of error happend.
        
         | andolanra wrote:
         | I tried using Pony for 2019's Advent of Code, and I ran into
         | this problem. I ended up writing a whole blog post about the
         | way that I tackled error-handling, which I don't think is _the_
         | solution (especially since the Pony team is looking at new ways
         | of expressing error-handling) but was sufficient for the
         | programs I was writing:
         | https://journal.infinitenegativeutility.com/pony-errors-and-...
        
         | spooneybarger wrote:
         | `error` in Pony is for partial functions.
         | 
         | A partial function is where you can't compute a result based on
         | the input.
         | 
         | If you need to know what went wrong (because more than one
         | thing might have gone wrong and that needs to be communicated),
         | you can use a union type for the result and match accordingly
         | (as you would in Rust as an example).
        
           | Asmod4n wrote:
           | Ah, i see. The files package does that apperently, correct?
           | But cannot find it in the net package for example.
        
             | ergl wrote:
             | Occasional Pony committer here. You're right, and improving
             | how errors are handled for socket operations has been in my
             | mind for a while.
             | 
             | If you have used it and have any ideas on what you'd like
             | to see there, feel free to drop by Zulip!
        
             | spooneybarger wrote:
             | The files package in general uses `error` and isn't very
             | helpful in letting you know what went wrong.
             | 
             | "Makes the files package better" is something that has been
             | on a "list of things to improve" for a long time.
        
       | nicktorba wrote:
       | Pony actors look similar to the python ray package actor api.
       | 
       | If anyone from the Pony teams sees this, are actors in Pony
       | conceptually similar to actors created with ray?
        
         | spooneybarger wrote:
         | I'm not familiar with the python ray package. If you are
         | familiar with actors as they exist in erlang and elixir,
         | there's a comparison of those to Pony that might help your
         | understanding.
         | 
         | https://www.youtube.com/watch?v=_0m0_qtfzLs
        
           | nicktorba wrote:
           | Thanks!
           | 
           | Turns out an easy google search answered my question as
           | well... this post https://medium.com/distributed-computing-
           | with-ray/ray-for-th... does say that ray uses the actor
           | model, and ray is listed on The Actor Model wikipedia page as
           | an Actor Model library.
        
       | cultofmetatron wrote:
       | I just spent 5 min going through the website reading about pony
       | and its goals and use cases.
       | 
       | I still have no idea what actual Pony code looks like and I'm not
       | sure where to click to find it.
       | 
       | I even clicked the link "learning pony." Of all the places to see
       | at least a hello world, I'd like one there please.
       | 
       | When I am checking out a language for the first time, I like to
       | at least see a sample of what I'll be committing to writing for
       | the next few months.
       | 
       | go lang as a sample you can run on the home page! rust used to
       | but you can still press playground to get it.
        
         | makeworld wrote:
         | I agree, but for anyone who's looking, here's the Hello World
         | page.
         | 
         | https://tutorial.ponylang.io/getting-started/hello-world.htm...
        
           | ajkjk wrote:
           | Hmm
           | 
           | > Pony doesn't care about filenames other than that they end
           | in .pony. But it might matter to you! By giving files good
           | names, it can be easier to find the code you're looking for
           | later
           | 
           | I cannot imagine anyone is going to be learning to code from
           | the first time from this Hello World page. Although, the rest
           | of the page is very much not for beginners, so maybe this was
           | a fluke.
           | 
           | Often with new programming languages I wish they would
           | present themselves in the form "Here's what you need to know
           | about this language if you're already a professional
           | developer" instead of an actual tedious tutorial.
        
             | dkarl wrote:
             | 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.
        
               | Kwpolska wrote:
               | 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.
        
               | pjmlp wrote:
               | True, but many don't realize that package private and
               | "friend" classes can share the same source file.
        
               | dkarl wrote:
               | I guess that shows how uniformly the convention is
               | followed that I wasn't aware of that! I remember finding
               | a class in a PR that had been renamed without renaming
               | the file, and we were surprised it compiled. It must not
               | have been a public class.                   $ echo "class
               | Bar { }" > Foo.java         $ javac Foo.java         $ ls
               | Bar.class Foo.java         $
        
           | openfuture wrote:
           | Good thing we had you here or there'd have been no world to
           | say hello to.
        
         | mcguire wrote:
         | Pony has a playground...
         | 
         | https://playground.ponylang.io/
         | 
         | ...but the example isn't very enlightening.
         | 
         | Here's a networking example:
         | 
         | https://github.com/ponylang/ponyc/tree/master/examples/net
         | 
         | with the Main being in net.pony and the rest being the
         | infrastructure.
         | 
         | And here's the start of an HTTP 1.1 app server (basically, just
         | the HTTP parser at this point).
         | 
         | https://github.com/tmmcguire/shetland
        
       | wpietri wrote:
       | Huh. This is something I don't think I agree with: "Incorrectness
       | is simply not allowed. It's pointless to try to get stuff done if
       | you can't guarantee the result is correct."
       | 
       | I'm sure that's true in some domains, but I think they're pretty
       | narrow. E.g., if I were building an internal API that managed
       | money, I might buy that. But I think the vast bulk of software is
       | essentially exploratory. We ship something minimal and see what
       | we next need. In that context, learning what we really need to do
       | is far more valuable than doing the not-quite-right thing with
       | provable correctness.
        
         | mattarm wrote:
         | For reference, you're pulling that quote from
         | https://www.ponylang.io/discover/#the-pony-philosophy
         | 
         | Clearly, the sentence you quote is making an unqualified
         | absolute statement, which are usually easy to pick apart and
         | tear down. After reading the whole philosophy, I'm not really
         | sure what they mean by "guarantee" and "pointless" here. I
         | doubt they're saying that all programming in "unsafe" languages
         | is "pointless."
         | 
         | I suspect they could just reword that sentence to say something
         | more clear. E.g. what kinds of correctness they weigh most
         | heavily. Does Pony protect me from all classes of all possible
         | bugs? No? Because that is impossible? Agreed. Then which kinds
         | of bugs?
         | 
         | Just before, it also says: "The Pony philosophy is neither
         | "the-right-thing" nor "worse-is-better". It is "get-stuff-
         | done"." This is admitting some sort of balance is being struck
         | here...
        
       | z3t4 wrote:
       | If you are going to create a new language in 2021 please make it
       | use scoped + name-spaced module imports. Everything becomes
       | difficult if you can't even know which variables are used where
       | and what it is / originate from. Global variables are evil.
        
       | threatofrain wrote:
       | Prior discussion from 4 months ago.
       | 
       | https://news.ycombinator.com/item?id=24398469
       | 
       | Has anything new happened to the language?
        
         | spooneybarger wrote:
         | pony core team member here.
         | 
         | There has been nothing large or dramatic in the last 4 months.
         | We are plugging away at improving ecosystem tools, the runtime,
         | and a variety of other things; incremental improvement.
         | 
         | We spent money from our open collective account recently to
         | purchase a couple Apple Silicon mac minis so we can get pony
         | working on Apple Silicon machines. That's probably the biggest
         | "outside the community" news that is coming.
         | 
         | And I'm probably stretching the definition of "outside the
         | community" there.
        
       | smallstepforman wrote:
       | Are Sylvan and Sebastian still involved with the language? The
       | momemntum dropped the moment they left ...
        
         | spooneybarger wrote:
         | Momentum dropped when Causality went out of business and it
         | became a volunteer-driven project with no one working on it for
         | pay.
         | 
         | Sylvan is still involved but not in a coding kind of way. He's
         | still involved in a variety of Pony decisions, discussions,
         | etc. It's a rather different role than what he had in the
         | beginning when he was the primary coder on it.
         | 
         | There was an uptick in contributions that were driven by
         | Wallaroo Labs that involved improvements that were needed for
         | Wallaroo, beyond that, it's all volunteers.
         | 
         | If you'd be interested in contributing, swing by the Zulip. We
         | love to get new folks involved.
        
       | dang wrote:
       | If curious see also
       | 
       | 4 months ago https://news.ycombinator.com/item?id=24398469
       | (thanks threatofrain!)
       | 
       | 2019 https://news.ycombinator.com/item?id=20370448
       | 
       | 2018 https://news.ycombinator.com/item?id=18212633
       | 
       | 2018 https://news.ycombinator.com/item?id=17195580
       | 
       | 2018 https://news.ycombinator.com/item?id=16768706
       | 
       | 2018 https://news.ycombinator.com/item?id=16264845
       | 
       | 2017 https://news.ycombinator.com/item?id=15558051
       | 
       | 2017 https://news.ycombinator.com/item?id=14999899
       | 
       | 2017 https://news.ycombinator.com/item?id=14676505
       | 
       | 2017 https://news.ycombinator.com/item?id=13846063
       | 
       | 2016 https://news.ycombinator.com/item?id=12331458
       | 
       | 2016 https://news.ycombinator.com/item?id=10902906
       | 
       | 2015 https://news.ycombinator.com/item?id=9482483
       | 
       | related from 2019 https://news.ycombinator.com/item?id=19241427
        
         | spooneybarger wrote:
         | i hope you have a tool that pulls all those links together for
         | you.
        
           | eindiran wrote:
           | I think the tool is probably this one:
           | https://hn.algolia.com/
        
       | loa_in_ wrote:
       | I never saw Pony described as high performance. Now I'm
       | interested
        
         | mcguire wrote:
         | Pony 1) isn't interpreted and 2) tries to avoid copying data
         | between actors (think threads).
        
         | rurban wrote:
         | Well, in the very first benchmarks it was the fastest of all on
         | multicore machines. Faster than C++ with pstl/openmp.
         | Lockfree/non-blocking stdlib has its advantages. It's also
         | safe, much safer than rust.
        
           | ibraheemdev wrote:
           | > It's also safe, much safer than rust.
           | 
           | Can you give an example of this? How is Pony "much" safer
           | than Rust?
        
             | spooneybarger wrote:
             | As a member of the pony core team, I'm not comfortable
             | saying Pony is safer than Rust. The approach of the two is
             | different; each with their own trade-offs.
             | 
             | Given how easy it is to use c-ffi from Pony, it can be hard
             | with existing tooling to feel confident in what your Pony
             | code might do. Once you call out via C-FFI, all safety
             | guarantees are off.
             | 
             | In this way, the c-ffi in Pony is as problematic for
             | reasoning about safety as `unsafe` is in Rust.
             | 
             | Pony allows you to turn off FFI for all packages except for
             | some that you allow but even then, FFI is an end around for
             | the memory safety and capabilities security that the
             | language otherwise provides.
             | 
             | Improving FFI tooling is an ongoing conversation amongst
             | the core team.
        
               | ObscureScience wrote:
               | Is not the Pony c-ffi, while allowing theoretically the
               | same unsafety, more uncontrolled than rust's "unsafe"? As
               | in the latter case, as I have understood it, you get all
               | the normal rust type checking, except for some pointer
               | ownership exceptions. I have not explored either of the
               | languages too the extent that I needed to use either.
        
           | pdimitar wrote:
           | Not saying that Rust is fault-proof but that's a pretty bold
           | claim. How do you back it?
        
         | ObscureScience wrote:
         | That's how I always seen it described. Not high performance as
         | in low level signal processing, but as in server software. I
         | would think of it like an alternative to Go (and Erlang), but
         | with more focus on performance, safety and more functional and
         | ruby-like rather than C-like. What they are sacrificing is
         | simplicity, and perhaps ease-of-reasoning.
        
         | spooneybarger wrote:
         | The tag line that has carried over on all the website versions
         | is:
         | 
         | "Pony is an open-source, object-oriented, actor-model,
         | capabilities-secure, high-performance programming language"
        
       | carapace wrote:
       | Would Pony be a good choice for writing a backend for a web app?
       | What's it like talking to a DB?
        
         | spooneybarger wrote:
         | 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 list of "why pony" features, but,
         | you are putting in a decent amount of work to get there.
         | 
         | That said if you release those libraries into the wild and get
         | help maintaining them, the next time someone asks there will be
         | less reason to say "you'll have to do some work".
        
           | carapace wrote:
           | 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
           | Pony?
        
             | spooneybarger wrote:
             | 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/
        
               | carapace wrote:
               | Oh cool! That might be all I need. Thanks again.
        
       | spooneybarger wrote:
       | If you are interested in learning more about Pony, please feel
       | free to join our Zulip and ask away. It's the primary hub for the
       | Pony community:
       | 
       | https://ponylang.zulipchat.com/#narrow/stream/189985-beginne...
       | 
       | Before jumping in, we suggest folks read our code of conduct
       | here:
       | 
       | https://www.ponylang.io/community/code-of-conduct/
       | 
       | And social rules here:
       | 
       | https://www.ponylang.io/community/code-of-conduct/#social-ru...
       | 
       | To understand what the general expectations are within the
       | community.
        
       | mcintyre1994 wrote:
       | Pony came up in the Corecursive podcast a few months ago, I
       | enjoyed this episode on it: https://corecursive.com/055-unproven-
       | with-sean-allen/
       | 
       | There was a big focus on both performance and stability/safety.
        
         | agbell wrote:
         | There was also a great explanation of why Pony and not Rust or
         | Erlang, at least of that use case. I was the interviewer.
         | "Pony: How I learned to stop worrying and embrace an unproven
         | technology", a talk Sean gave about Pony is really good as
         | well.
         | 
         | https://www.youtube.com/watch?v=GigBhej1gfI&t=1755s
        
         | spooneybarger wrote:
         | Hiya. That's me.
         | 
         | If there is anything you ever want to chat about from that
         | podcast or anything pony related, feel free to find me on the
         | Pony Zulip and DM me.
        
       | haskellandchill wrote:
       | 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...
        
         | haskellandchill wrote:
         | I took a stab at it, seems everything is indexed by
         | capabilities which makes sense.
         | 
         | There is "Equivalence of ephemeral capabilities" for ephemeral
         | indexing outside of iso and turn.
         | 
         | There is "Compatible capabilities with ephemeral modifiers"
         | which shows ephemeral indexing does not matter for
         | compatibility.
         | 
         | This is extended to types with "Compatible types" then "define
         | the aliasing operator +, to give us the minimum compatible
         | capability when a new alias to an object has been made" with
         | "Aliasing" presenting the cases. There is "Unaliasing" and
         | that's where I'm checking out.
         | 
         | Is there a general theory behind these kind of indexed
         | judgement rules with case splitting?
        
       | jgilias wrote:
       | 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 address. This is the point where the Rust
       | compiler starts complaining about the situation if you try to use
       | the bindings from something that can potentially be sent between
       | threads. So you use some mutex, or a lock, and maybe wrap the
       | whole thing in an atomic reference counted entity.
       | 
       | What would be the Pony way of solving a situation like this? It
       | does say that it is possible to directly call C or C++ libraries.
       | 
       | I'd really appreciate if someone from the Pony community can
       | elaborate a bit on such use cases.
        
         | spooneybarger wrote:
         | 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/#
        
           | jgilias wrote:
           | 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.
        
             | spooneybarger wrote:
             | 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 scheduler threads- generally 1
             | per scheduler thread per CPU) then "bad things canhappen".
             | Becaue you are running unsafe code that can be accessed
             | from multiple threads- but... well, maybe you can structure
             | the Pony API so that you don't do that.
             | 
             | It really depends.
        
       ___________________________________________________________________
       (page generated 2021-01-29 23:00 UTC)