Printing hello world is the default of the industry for this sort of thing.
The Rust playground defaults to "Hello World" but that's just because there has to be something there, it's not on the home page of the website or anything (though it used to be).
Mainly my point is it’s weird to complain about hello world. It’s been the first program for languages for decades.
You also don't get to be the chief decider of what all of us may or may not talk about.
Playground: https://playground.ponylang.io/
They're on HP https://www.ponylang.io/ unfortunately the article link points to /discover/
I would be torn if I had to write intro documentation like this. On the one hand, people demand code examples, but on the other hand, the majority of people reading code examples will nitpick minor pet peeves in the syntax and completely detract from the actual new ideas and concepts that go way beyond just the syntax.
I found the descriptions of the concepts very enlightening and I honestly think they gave me a better idea of what the language would “feel like” to program in than a code example (or a description of the syntax) would have.
In theory, syntax should be interchangeable. It's conceivable to parse a syntax into an AST and reexpress it in another syntax without changing the AST. In practice, this is not done for many reasons (incl. tooling like diffs) but a big reason is that individual bits and bobs of the syntax are tied to the new concepts in subtle ways. There could absolutely be multiple syntaxes for the same concept, but if the concept is new, even in small and unobvious ways, then no prior existing language’s syntax will map it exactly. For this reason, a code example can't really express the new concept, especially if the syntax is superficially similar to another language that doesn't actually have that concept.
So by seeing the syntax up front I can save a lot of time because in a world where there are many languages that do the same thing it really boils down to using the one with the syntax that you like the most.
Wat? If all languages were just syntax re-skinning, we really wouldn't need more than one compiler backend...
Generally the semantic differences are much more important. Rust isn't interesting for its syntax, it's interesting for its ownership rules and borrow checker. Erlang isn't interesting because of its syntax, it's interesting for its actor model concurrency. And so on...
I mean, you do you. No one is judging. The fact remains that Rust exists primarily because there are some features that C++ cannot reasonably provide
Not only didn't they made it into C++26, it isn't clear what could land in C++29, this ignoring the assumptions regarding capabilities that static analysers are yet to provide nowadays.
Oh, that's very interesting. Rust tried to match C++'s syntax as much as possible.
Which parts do you find awful? Lifetimes and trait bounds?
But just because syntax is superficial doesn't mean that it isn't important. If a language has such poor syntax that I feel the need to write my own compiler to work around its syntax, I have to seriously question the skills and/or motivations of the author. If I am capable of writing a compiler at the syntactic level, why not just go all in and write my own compiler that implements _my_ desired semantics? A language that I find subjectively distasteful at the syntactic level is nearly guaranteed to be filled with semantic and architectural decisions that I also dislike. Consider Rust, I do not think that its syntax and abysmal compilation times can be decoupled. I would rather write my own borrow checker than subject myself to writing rust. And the reason is not the syntax, which I do strongly dislike, but the semantic properties of the language, such as horrible compilation times and compiler bugs (if a language has more than 100 open issues on github, I consider it broken beyond repair).
Err, ok, so? Don't be so afraid of criticism, I guess? Yeah, some people will nitpick. I don't see the problem.
I believe that, regardless of our personal preferences, the reality is that syntax is a major criteria for adopting a programming language.
Some people have trouble following Lisp code, and won't touch your project if it looks like chat. Others will have the opposite reaction and have their interest captured instead.
Some love short, mnemonic built-in variables and short built-in function names of the sort you see in APL or Perl (although Perl has longer-named versions optionally for a lot of things). Others love long, self-documenting names for keywords and functions. They might want no built-in variables at all.
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."
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 readable languages that have a concise-but-not-too-much syntax, that use not too many special characters, and that is read like fortran/pascal/c/etc (I don't how to define it, but for example lisp is different)
True, it just means that it's idiotic, rather.
And so no,
> Saying that a certain kind of Scotsman puts sugar on his porridge is very different from saying that no true Scotsman puts sugar on his porridge.
I categorically disagree that these would be meaningfully distinct claims, as the "[only] a certain kind of Scotsman puts sugar on his porridge" bit specifically invokes the implicit disqualification of said Scotsman from being counted as a True Scotsman.
> not the only example of it from that source
Pretty ironic of you to say that.
[0] the literal definition of the no true scotsman fallacy: https://en.wikipedia.org/wiki/No_true_Scotsman
Whereas this follows the form more of "Murder is bad" "I dunno, a lot of Scotsmen commit murder" "Ok, but no true Scotsman would commit murder"
It's the same (annoying) assertion, but the fundamental argument is about the value of murder, not the category of "Scotsmen," so it's not the same extremely obvious fallacy of redefining the literal topic at hand whenever a counterexample is presented.
It's why I called it an outright textbook example: it's an appeal to purity, where purity is determined in a circular way - the very definition of the no true scotsman fallacy, as far as I could find and understand it.
Although, I would point out that while your argument ad absurdum is generally reasonable (the fact that syntax can make the difference between a very good language and an unusable one), whitespace and malbolge also have terrible semantics that contribute to them being unusable.
As a former Lisp enthusiast (and still an enjoyer), I'd actually use my own darling as an example: Lisps have amazing semantics and are generally good languages. Their syntax is highly regular and structured and easy to parse...except that it's brain-hostile, and I'm convinced that it actively makes it harder to read and write - not just adopt, but actually use.
Are you talking about natural languages here? The so called Sapir Whorf thesis - in its strong or weak form - is rather controversial. There are some interesting findings, but the interpretation of them is still hotly debated.
In any case, none of the studies that I've seen (e.g. about colour perception, spatial reasoning, etc.) seem to be about syntax. I'd have to see some evidence that head-marking language speaker somehow think differently than dependent-marking language speakers and I haven't seen that.
> your argument ad absurdum is generally reasonable
it's a valid argument when somebody is speaking in absolutes, but I haven't seen GGP do that. There's a difference between saying "all syntax is completely arbitrary" and "syntax is not the point" - the latter suggests to me that if you stay within certain reasonable bounds (e.g. not be whitespace or malbolge), whether you use significant whitespace of braces, the language looks more like Pascal or like C, etc. are of minor importance in the grand scheme of things. Which is something you may disagree with, but it's a much more reasonable point that anything you can just counter with "but whitspace!".
I never said anything to the contrary. I specifically stated that syntax was not an important consideration in the design of Pony language. That does not imply the numerous strawmen that you and others attacked here. As Tainnor correctly and honestly noted:
"it's a valid argument when somebody is speaking in absolutes, but I haven't seen GGP do that. There's a difference between saying "all syntax is completely arbitrary" and "syntax is not the point" - the latter suggests to me that if you stay within certain reasonable bounds (e.g. not be whitespace or malbolge), whether you use significant whitespace of braces, the language looks more like Pascal or like C, etc. are of minor importance in the grand scheme of things. Which is something you may disagree with, but it's a much more reasonable point that anything you can just counter with "but whitspace!"."
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.
The syntax is the language. To show me the language you have to show me its syntax.
This is obviously false.
That was years ago. After reading your comment, I decided to check again. The same “AAA game” link is still first, and it’s still broken.
You can’t really call that “a good presentation of a language” when the very first real-world example links to nowhere—and nobody’s bothered to fix it for years.
You are not wrong, that should be fixed but no information about it is lost, I feel like you're a bit too harsh here.
Python doesn't have a notion of public/private symbols (no, "__" prefix does absolutely nothing). It also doesn't have a good type system, so it can't have function overloading.
This is why you're required to qualify almost all imports in Python, to avoid name clashes.
Nim doesn't have this problem and also "fixes" a lot of other shortcomings[1] of Python.[2]
[1] - https://github.com/yugr/python-hate
[2] - https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm...
When you're reading Nim code and you see a symbol you don't know, how can you tell where it comes from? In Rust, it's either qualified or you have to explicitly import it. What do you do in Nim?
In my experience, it's even faster to git clone, open a project in neovim and navigate with LSP than browsing code with some online interface.
All the languages you listed do not support function overloading. Qualified imports and namespaces exist to avoid name clashes first, dependency tracking is just a bonus (and a chore).
It’s crazy how many people build something and make a website for it, only to hide the thing they’ve built somewhere deep in the website. Just show me the damn thing!
Why another object language?
https://github.com/KittyMac/PonyCAT/blob/master/pony-cheat-s...
The project looks hostile to any sort of adoption.
That is indented to assist the human reader, not the compiler.
actor Main
new create(env: Env) =>
TCPListener(TCPListenAuth(env.root), Listener(env.out))
??
If so, I don't want to every see that language in my life ever again.
That's fine, we all have our preferences :D
They can tell you whether language is statically typed or not, does it have an effect typing (it necessarily needs higher order types), does it have type inference, etc,
A syntax of one is semantic of other.
Sure, some people are going to use that as an immediate gut filter for "doesn't look enough like languages I already know" or various pet peeves, but on the other side for those that love to dig deep into the syntaxes of esoteric/lesser-known languages it becomes like the first sniff when working on tasting notes of a beverage and tells you a lot up front to your "nose" faster than paragraphs of prose about the motivations of the language. "Ah, yes, I'm sensing a strong Python influence on top of earthy notes of Erlang and just a bit of floral Pascal-ness most recently from the vineyards of Typescript, perhaps?"
> The difference between an actor and a class is that an actor can have asynchronous methods, called behaviours. We’ll talk more about that later.
Who wrote this[1]? The Doctor?
[1] https://tutorial.ponylang.io/getting-started/how-it-works
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...
It's great that you have all that philosophy behind it, all sounded great, but if you don't show me a compelling example in the first minute or two, not even in tutorial, then you'll fail to capture my interest.
Playground: https://playground.ponylang.io/
They're on HP https://www.ponylang.io/ unfortunately the article link points to /discover/
The programming language documentation wasn't written for an audience primarily composed of programmers? That would be an odd choice.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
The causality model was great, but is there a way to handle backpressure now?
There are real-time safe GC algorithms. I don't know whether Pony offers that option. I would like to know.
This pony paper here describes the pony GC algorithms and compares their performance under various scenarios to other language GCs.
https://www.ponylang.io/media/papers/orca_gc_and_type_system...
The charts you want to look at are on pages 19-21.
It shows that ORCA (pony's GC) has extremely low jitter and is highly performant compared to the other industry leaders at the time of publication.
Examples include IBM's Metronome: https://www.researchgate.net/publication/220829995_The_Metro... and https://developer.ibm.com/articles/garbage-collection-tradeo...
Thanks for the ORCA link. I'll have to study it more closely but from Fig 17 it looks to have quite unpredictable jitter up to at least 20ms. Which is obviously fine for many things but not useful for other things (e.g. processing AVB streaming audio packets at line rate every 125 us).
EDIT: I originally also cited the following, however I am not sure these were the papers that I was thinking of: Baker's algorithm: https://dspace.mit.edu/bitstream/handle/1721.1/41976/AI_WP_1... also discussed here: "Baker's garbage collector performs garbage collection in real time-- the elementary object creation and access operations take time which is bounded by a constant, regardless of the size of the memory." https://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Real...
As with all things, we should use the correct language / runtime for the domain problems it's designed to solve.
The pony runtime makes other decisions (such as non-preemptable schedulers) which would have more of an effect on your use-case methinks.
Thank you for the discussion and your interest!
Read the "Early History of Pony":
https://www.ponylang.io/blog/2017/05/an-early-history-of-pon...
My point is - sure, it doesn't have a handful of massive companies stewarding it like Rust. But, on the other hand, it's made by a guy with really serious chops, who has a solid programming language related job. So while not being as industry-sanctified as Rust, or Java, it seems nonetheless like a language that could go places!
The vast majority of people I discuss it with understand the value and the problems it is designed to solve, but they either don't have domain-problems that require pony's approach more than any other language - or the lack of supporting libraries makes them nervous over adoption.
As a pony developer for 5+ years, it can be frustrating - but I do understand.
One of the innovative point of Pony is the iso reference. iso reference means that an object graph is accessible from only that iso reference. It avoids sharing mutable data.
Wow, what a phrase! Thanks for the link, very interesting stuff!
It's statically and strongly typed, and super concurrent. It's a very different vibe than anything python.
If I click "why pony" i want to know when to use it. I want to decide for myself if I want to use this
I couldn't find a page where it's clear if I should invest my time in it
How to do this: - examples - companies/projects who use X - what this language aims to do - what this language is good at
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 the parking_lot crate for Rust.
Lockfree spinlocks will only waste cycles on one CPU. A huge difference when you have dozens and hundreds of cores.
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.
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"
[1] at the very least you will need one queue for each cpu pair, but that's yet another layer of complication.
https://www.erlang.org/blog/parallel-signal-sending-optimiza...
1. One scheduler per core. 2. Schedulers run one actor behaviour at a time. 3. When a scheduler has an empty work queue, they will steal work from other schedulers. 4. The number of schedulers will scale up and down with the amount of work (but never more than number of cores).
There are various parameters you can change to alter scheduler behaviour should your pattern of use need it.
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.
That's a valid point of view, but Pony's claim to which I objected is about performance, not ease-of-use or convenience.
I think of pony actors in the same way as I think of erlang actors. They have a "mailbox", and when they receive a message, they wake up, execute some amount of code, and then go back to sleep.
This is how I think about it. This is not how it is actually implemented.
Here's the key that I think many people miss about pony.
Referential Capabilities DO NOT EXIST at runtime.
So let's talk passing a String iso from Actor A, to Actor B. (iso is the capability that guarantees that this is the only reference to this object):
// This is code in Actor A
actorB.some_behaviour_call(consume myisostring)
The reference to myisostring then gets sent to Actor B via its mailbox.
If ActorB was idle, then the message receive will cause Actor B to be scheduled and it will receive the reference to that String iso - completely isolated.
Now, if we're going to measure "performance of passing data between threads" as latency per transaction, then actor contention on a scheduler is going to be a bigger factor.
If you're measuring performance across an entire system with millions of these actions occurring, then I would argue that this approach would be faster as there is no spinning involved.
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.microsoft.com/en-us/research/project/project-ver...
https://www.microsoft.com/en-us/research/project/project-ver...
Maybe they are now mostly behind MS walls, or have indeed decided to look elsewhere for their research goals.
Not a great look, although it looks like it was only deprecated 2 weeks ago, so I'll give them a pass.
Maybe a third-party awesome list or so would be interesting.
Other than that, I guess one could get involved in the community to ask questions about things one needs for some project, or search more specifically for things one needs and hope to then find them.
https://github.com/ponylang/ponylang-website/commit/89211a89...
So checked Exceptions like Java?
Pony: Doesn't distinguish between exceptional results and runtime errors; either a function is guaranteed not to fail, or it isn't. A function that isn't is called "partial", and can only be called either from another partial function or from a try block that specifies how to handle errors. So anything that can fail in any way, including indexing into an array, has to be partial; there's no way to tell the compiler "please don't force my caller to handle the possibility of a bounds check failure, I'm sure that won't happen, and if it does then everything is terminally messed up and we should just crash". Likewise with a value of a union type being None when it shouldn't be, or otherwise being the wrong type. (They tried having integer division be partial, but apparently that was a bridge too far—so instead, any integer divided by zero is zero.) The top-level error-handling pattern would need to be implemented by making basically every non-leaf function in your codebase partial. Also, these errors can't have payloads or anything, so the top-level handler can't make use of any diagnostic information (if you want that then you need to instead return a custom union type and forgo the partial-function syntactic sugar). I haven't actually used Pony in anger but this is definitely the feature of the language that impresses me least; it's ostensibly in the name of correctness, by prohibiting programs from crashing, but you can't actually prevent the root causes of crashes without dependent types, so instead they've made this mess that makes effective error handling impossible.
Rust: Exceptional results are represented with the Result type, instances of which are just values returned from a function like any other. There's syntactic sugar (the ? operator) to propagate an error up a stack frame. A Result has a payload whose type must be specified; ergo, every function's API must effectively declare not only whether it can return exceptional results, but also what kinds. In a library, you'd typically design a structured error type to represent the possible exceptional results that your API can return, but in a binary, you may not care about that level of detail in each function's API, and instead prefer to return a catchall "some exceptional failure, idk what" type. Out of the box the language has Box<dyn Error> for this, but it's more common to use a third-party crate like anyhow or eyre that makes this pattern more ergonomic. In an application that handles errors this way, most likely every function that does I/O returns Result<T, Box<dyn Error>> (or the anyhow or eyre equivalent), while functions that just do pure computation on trusted data return non-Result types. Runtime errors use a different system, panics, which are not part of a function's API (so any function can panic); by default, panicking unwinds the call stack until it reaches a catch_unwind call or the bottom frame of the current thread's stack (allowing a top-level handler to use catch_unwind or Thread::join to catch and handle runtime errors), but when building an executable binary you can instead configure it to skip all that and immediately crash the process when a panic occurs (there are pros and cons to doing this). For this reason, library code can't rely on catch_unwind working, so it's important for libraries not to try to use panics to convey recoverable errors. A Result can be turned into a panic with the unwrap method, if you're sure that the relevant exceptional result can't occur or if you're just being lazy/writing prototype throwaway code and don't want to bother getting the function signatures right.
Swift: Exceptional results work like checked exceptions in Java, but without all the problems that make the latter not work very well in practice. Each function signature can either never throw anything (the default), throw any Error (with an arbitrary payload whose type is unknown at compile time, analogous to Rust's Box<dyn Error>), or throw a specific Error subtype with a specified payload (this last one is uncommon). When calling a throwing function, you must either handle the error or (if you throw a compatible type) propagate it up to your own caller; there are various syntax-sugar niceties to handle this. There's a Result type like in Rust but it's not commonly used as a return value, it's mostly only needed if you're storing errors in data structures or similar. So a top-level error handler is done by having all functions that do I/O be throwing functions, like in Rust but with nicer syntax. Runtime errors are not declared in function signatures and always immediately crash the process; unlike in Rust, there is no way to have a top-level handler for them. Like in Rust, you can turn an exceptional result into a runtime error (Swift's syntax for this is the try! operator).
For example, the OpenFile API returns you either a valid pony File object, or why it failed (FileEOF, FileBadFileNumber, FileExists, FilePermissionDenied, etc…).
What partial functions do is ensure that all of the error cases are actively addressed by the programmer, so you don't get panics or SEGVs.
There are basically only two possibilities: abort the process, or jump to a top-level handler that logs the error and returns a 500 response (or whatever the equivalent is, for a long-running program that's not a web server). In neither case is there any interesting decision to be made about how the direct caller should handle the error. In return, whenever you subscript an array or otherwise do anything that has preconditions or invariants, you have to add a question mark to every function that can transitively call it and every call site of same, throughout the codebase. This task requires no intelligence—it can be done algorithmically without error—so why require it?
If you could actually prevent precondition and invariant violations at compile time, that would be quite a different proposition, but Pony can't actually do that (because it requires dependent types) and the intermediate solution they've hit on appears to be the worst of all worlds.
Also, it seems perverse to have a syntax for calling fallible functions and propagating failures up the call stack, but then not allow it to be used for exceptional results, which are the kind of failure that's actually worth propagating up the call stack.
try
somearray(outofboundindex)?
// stuff
else
errorlog.write("some message")
error
end
Pony doesn't force you to deal with errors a specific way. Pony forces you to make a choice so you can't just ignore it.
Or checked result types as in many FP languages, which many seem to miss the similarity.
The switched because they changed their business focus from one of their products to another.
I'm sure we'd all agree that the best language to use is the language the best fits your problem domain.
Rust was a better fit for that new product than pony. That's not a reflection on the 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.
1. https://blog.jtfmumm.com//2016/03/06/safely-sharing-data-pon... 2. https://bluishcoder.co.nz/2017/07/31/reference_capabilities_...
Still, trading deadlocks for livelocks is a net negative as they are harder to identify and diagnose.
How could that be true? You'd be emulating the language particularities, so deadlocks would be just virtual states. Your interpreter itself being free of deadlocks doesn't mean it cannot represent them.
It's like thinking that you cannot write e.g. console emulators in Rust, because people typically ship unsafe code to consoles, yet Rust enforces memory safety. Yes, it does enforce it - so you'd be representing unsafe accesses instead, rather than actually doing them.
So what does it means that Pony is deadlock free if it can implement deadlocking programs?
A better, more rigorous claim would be that the pony runtime is deadlock free or that there are no primitive blocking operations.
I'd be hesitant to call this a "Pony runtime" property - to my understanding language runtimes just provide application bootstrapping and execution time standard library access. Pony code becomes machine code, managed by the OS as a process with some threads. This language property guarantees you that those threads will never "actually", "truly" deadlock. Code implemented on the Pony level can still progress if it chooses to do so, and Pony formally ensures it always has the option to choose so.
If your business requirements necessitate otherwise, that's a different matter, something you introduce and manage on your own.
I'm not sure if there are any languages that allow you to pass down / inherit language constraints specifically, maybe Lisp or similar can do that? But then often that unfortunately wouldn't be actually helpful, as these requirements usually come from the outside (like in your Python example, it comes from Python being specified such that you can encode deadlocking logic in your Python code).
For most everyone who aren't trying to implement the possibility of deadlocks in guestcode, this remains a useful property even without that.
A simple example is if you get into a situation where two actors are both waiting for the other to send it a message.
For example I can define a notsemaphore actor that calls a callback once an internal count reaches 0, and then I can forget to decrement it and so it will never reach 0. But technically this didn't involve synchronization so there isn't a stack trace to tell me why is my program stuck and somehow this is better.
Pony guarantees deadlock freedom by eliminating locks and other mechanisms that can lead to deadlocks. Instead, Pony uses a message-passing concurrency model and static analysis to prevent data races and deadlocks at compile time. This means developers don't need to worry about manually preventing deadlocks because the compiler handles it. The scheduler is lock-free, the order of message-delivery to all actors is guaranteed.
Here's a more detailed explanation:
Message-Passing:
Pony employs a message-passing model where actors (objects) communicate by sending messages to each other. This avoids the need for shared mutable state and locks, which are primary sources of deadlocks.
Static Analysis:
The Pony compiler performs static analysis to ensure that concurrent access to data is safe. It prevents data races and other concurrency issues that could lead to deadlocks by verifying that no two actors can simultaneously write to the same memory location.
No Locks:
Because Pony doesn't use locks, there's no possibility of threads getting stuck waiting for each other to release locks, which is a common cause of deadlocks.
Data Race Freedom:
By eliminating the possibility of data races (concurrent modification of shared mutable state), Pony also eliminates a major source of potential deadlocks.
edit: and to be clear, I'm quite interested in Pony, static typing, shared nothing threading with message passing, capabilities, per thread GC is very close to my ideal programming language. But the bogus deadlock-freedom claim make me question the other claims.
It may be a common cause of deadlocks, but it isn't the only way to have deadlocks.
A book I read on erlang had an entire chapter on how to avoid deadlocks with actors that had several examples of how you can get a deadlock with just message passing.
In fact, it is possible to implement a lock/mutex (also a semaphore) with actors and message passing.
https://www.ponylang.io/discover/
to
On the second link, as another commenter mentions, the "Try it in your browser" is one click away, near the top. On the first link, it's two clicks away, but the first of those clicks is a perhaps surprising backwards-lick to get back to the homepage...
Unfortunately, many of the diehard language enthusiasts here seem to be getting quite worked up over how inaccessible the code examples are. Instead of being able to immediately see the syntax so they can rush back here to make insightful and educated comments on how that syntax compares to $their_fave_lang, they are forced to spend up to 4 or even 5 minutes reading documents clearly describing the design of the language, and being obliged to click on their mouses up to 10 times even in some cases.
If a member of the Pony team sees this: even though it's more than a tad ridiculous and you have in fact made a lovely website with loads of clear information, maybe consider adding the "Try it in your browser" link as another option in the burger menu thing on the left. That way it follows everyone around, and you never have to suffer a HN discussion getting needlessly derailed by the resident PL fanatics.
The problem with the linked docs on the Pony website is not that it doesn't explain the semantics (it does!) but that it seems to be written at a pace appropriate for someone who has no clue what static types even are. [1] Give a concise demonstration of the syntax and the semantics, even if that means that the latter will use terminology that not everyone will understand. Then the full tutorial is there for the details.
Welcome to interface design! Your way of thinking could not be more wrong if you tried :)
How buying stuff on say Amazon works:
1. Click on picture of a car
2. Click "Buy Now"
How it would look like if we apply yours/the Pony website designers' approach:
1. Read a 10 page description of what the car is
2. Click on a link buried on page 12 that lets you buy the thing
Which approach gets more sales?
> 2. Click on a link buried on page 12 that lets you buy the thing
But the link to the playground is on page 1, the home page, and not page 12? So your whole argument is moot, since it seems the Pony people obeyed at least this part of your interface design dogma.
Or, in other words, "you could not be more wrong if you tried :)".
The issue here was that page 2 was linked in the title, so everyone was getting to page 2, and not clicking back to page 1, where the playground was, and instead clicking forward and getting lost.
And all that aside, as another commenter said, even if the playground was hidden behind the most fiendish of mazes -- perhaps not every programming language is interested in attracting the kind of people who think every corner of the universe must mirror Amazon's approach to "sales".
https://tutorial.ponylang.io/types/actors
If you know a few programming languages I think you should be able to guess what the syntax does from context.
And then the next key idea is here:
https://tutorial.ponylang.io/reference-capabilities/referenc...
(Although I think the first actual interesting I idea I saw was "Destructive read" under https://tutorial.ponylang.io/types/classes#functions , but that's clearly just an isolated quirk, not part of the core idea of the language.)
It seems really bizarre to respond to “there should be easily-accessible examples of code that demonstrate the language’s key features on the website” with “there’s a $200 conference in South Carolina where there will be a talk on it.” Honestly, it comes across as not just bizarre, but somewhat disrespectful (though I’m sure that was not your intention).
My apologies.
It seems, from some skimming of the first like 10 pages of the guide, that Pony is an object-oriented language with actors, and a built-in concept of mutability of references. What kind of references are there? You say that deadlock is impossible; how — do you have session types or something? You say that nulls don't exist; how — do you have linear typing? How do you express capabilities?
Essentially, give me a one-page overview of the static and dynamic semantics (i.e. type system and runtime semantics) that gives me all I need to know about this language to decide whether I want to learn more about it.
The language looks cool, but all documentation I've seen so far seems to assume that the reader doesn't even know what static typing is. To get knowledgeable people interested, I think it's useful to have a pitch that appeals to people who are already familiar with a bunch of languages.
It may be easier to explain (for instance) Rust's borrow-checker in prose, but if you show me a snippet of code using `&mut`, it'll click for me intuitively that something conceptual and important is happening here. That's why I want an illustrative example at the top of the front page.
For those who enjoy long form video interviews, here is Kris Jenkins of Developer Voices interviewing Sean Allen on Pony language
https://patterns.ponylang.io/data-sharing/isolated-field
Basically what I gather is:
1. Actors are like threads, but have data structures associated with them. Actors have functions like methods associated with them called "behaviors", which are called asyncronously. BUT, any given Actor will only ever have one thread of execution running at a time. So calling a "behavior" is like sending a message to that actor's thread, saying, "Please run this function when you get a chance"; "when you get a chance" being when nothing else is being run. So you know that within one Actor, all references to Actor-local data is thread-safe.
2. They have different types of references with different capabilities. Think "const *" in C, or mutable and immutable references in Rust, but on steroids. The extra complexity you do in managing the types of references means that they can get the safety guarantees of Rust without having to run a borrow checker.
So in the above example, they have a Collector actor with an internal buffer. Anyone can append a character tot he internal buffer by calling Collector.collect(...). Code execution is thread-safe because the runtime will guarantee that only one thread of Collector will run at a time. The data is of type 'iso' ("isolated"), which ensures that only one actor has a reference to it at any time.
Once the internal buffer gets up to 10, the Collector will transfer its buffer over to another Actor, called a Receiver, by calling Receiver.receive(...) with its own internal buffer, allocating a new one for subsequent .collect() calls.
But its internal buffer has a reference of type 'iso', bound to Collector. How can it transfer this data to Receiver?
The magic is in these two lines:
let to_send = _data = recover Array[U8] end
- makes a new Array[U8] of type iso
- assigns this new array t; Collector._data
- Assigns the old value of Collector._data to to_send
Now Collector._data has a new reference of type iso, and to_send has the old one.
Next we do this:
_receiver.receive(consume to_send)
Sounds like an interesting approach; it would be nice to see more examples of realistic patterns like this; perhaps simple sequential programs broken down into multiple actors, or things like a simple webserver implementation, with some sort of shared state.
This is more nuanced actually. And it could have implications and contradictions with "get stuff done". IfI can have a non-provable piece of code that serves me well 99% of the time I could save coding time at the expense of correctness and could fit the bill for my use case.
We get a lot of stuff done assuming P != NP, that no polynomial-time prime factorization algorithm for classical computers exists, that one-way functions exist, etc.
As long as assumptions are clearly stated and are routinely questioned it's fine to have them
Compared to e.g. Rust (one of the better modern examples of easy rigorous math) I really like how concise they are. What I'm missing are saturating operations. I know some people find them useless, and through a "perfect results" lens they are, but they still give you the closest representable number. And they are often intuitive for humans since that's how most analog instruments work
+ 85 replies
The usual HN post where the threads which are tangential to the topic always rise to the top.
How much irrelevant dross to readers have to read through before they get to comments on the actual product?
Time to sit back and see if this one will also rise to the top or somewhere near.
The New Wave of Programming Languages: Pony, Zig, Crystal, Vlang, & Julia - https://news.ycombinator.com/item?id=36911186 - July 2023 (9 comments)
Pony Programming Language - https://news.ycombinator.com/item?id=33970547 - Dec 2022 (82 comments)
We moved from Pony to Rust - https://news.ycombinator.com/item?id=28777306 - Oct 2021 (175 comments)
Pony – High-Performance Safe Actor Programming - https://news.ycombinator.com/item?id=25957307 - Jan 2021 (152 comments)
Pony, Actors, Causality, Types, and Garbage Collection - https://news.ycombinator.com/item?id=24398469 - Sept 2020 (29 comments)
Pony 0.29 - https://news.ycombinator.com/item?id=20370448 - July 2019 (19 comments)
Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart - https://news.ycombinator.com/item?id=19241427 - Feb 2019 (143 comments)
Pony 0.25.0 released - https://news.ycombinator.com/item?id=18212633 - Oct 2018 (38 comments)
Introduction to the Pony programming language - https://news.ycombinator.com/item?id=17195580 - May 2018 (72 comments)
Pony (programming language) Cheat Sheet - https://news.ycombinator.com/item?id=17118368 - May 2018 (1 comment)
The Snake and the Horse: How Wallaroo's Python API Works with Pony - https://news.ycombinator.com/item?id=16768706 - April 2018 (8 comments)
Some high level information about the Pony programming language - https://news.ycombinator.com/item?id=16619264 - March 2018 (10 comments)
Why we wrote our Kafka Client in Pony - https://news.ycombinator.com/item?id=16264845 - Jan 2018 (95 comments)
Why we used Pony to write Wallaroo - https://news.ycombinator.com/item?id=15558051 - Oct 2017 (84 comments)
Pony Performance Cheatsheet - https://news.ycombinator.com/item?id=14999899 - Aug 2017 (35 comments)
Pony: Combining safe memory sharing with Erlang-like actors - https://news.ycombinator.com/item?id=14676505 - July 2017 (62 comments)
An Early History of Pony - https://news.ycombinator.com/item?id=14280565 - May 2017 (8 comments)
Pony language 0.11.0 released - https://news.ycombinator.com/item?id=13846063 - March 2017 (52 comments)
On the State of Pony - https://news.ycombinator.com/item?id=12331458 - Aug 2016 (40 comments)
Using Pony for Fintech [video] - https://news.ycombinator.com/item?id=11849579 - June 2016 (6 comments)
Pony is an open-source, actor-model, high performance programming language - https://news.ycombinator.com/item?id=10902906 - Jan 2016 (57 comments)
Pony – High Performance Actor Programming - https://news.ycombinator.com/item?id=9482483 - May 2015 (124 comments)
throwthrowrow•6mo ago
tomhow•6mo ago
Pony – High-Performance Safe Actor Programming - https://news.ycombinator.com/item?id=25957307 - Jan 2021 (152 comments)