Printing hello world is the default of the industry for this sort of thing.
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...
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.
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)
I don't think that Pony is claiming to be novel in the area of syntax?
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.
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!
> 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/
Most people visiting such websites are programmers who are more often than not busy as all hell.
If you show me 10 lines of code and a mini flow-chart demonstrating how Pony's actor runtime does stuff better then I'll definitely be intrigued and go browse the website for longer time (and more carefully). Is that a "shitty behaviour in society"?
But if the maintainers / creators do in fact want to give homework to visitors then that's their prerogative and their right. But as the other poster has said, I owe them no more than one minute of my time and they are not making a good use of it.
Yours is a confusing take for me. Glad you have all that free time though. I don't. My curiosity lasts one minute because I am only looking for game changers, not another endless hobby to sink time into. And if you can't intrigue me that way then I am out.
Would I be missing out on stuff by doing things that way? Very definitely! But, well, I can't worry about everything.
Apparently not too busy to visit HN and post shallow dismissals.
I agree with GP. Not everything is for everyone and expecting every project to cater to your very specific needs is rather entitled. If you're not interested, feel free to move on - I do that all the time for most of the content on here.
Indeed, as you have just excellently demonstrated. I did not dismiss anything, I generalized, which I believe we're all aware is never accurate. Thought that much was obvious and did not warrant a response like yours.
> If you're not interested, feel free to move on
Exactly what I did, and then I and a few others explained why. No idea why that was met with emotional responses that classify mine and others as "shitty behaviour".
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
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.)
The causality model was great, but is there a way to handle backpressure now?
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.
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...
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.
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.
So checked Exceptions like Java?
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_...
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.
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.
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.
For those who enjoy long form video interviews, here is Kris Jenkins of Developer Voices interviewing Sean Allen on Pony language
throwthrowrow•6h ago
tomhow•6h ago
Pony – High-Performance Safe Actor Programming - https://news.ycombinator.com/item?id=25957307 - Jan 2021 (152 comments)