Without wanting to derail the conversation too much.
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,
The .NET ecosystem itself has another mature actor-based framework in Akka.NET, being probably closest to the Erlang/Elixir supervisor style, in C#/F#.
(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.)
Was this meant to be a reply to the top-level story, and not a specific comment?
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).
I love the syntax for checked math. a + b for wrap around, a +? b to raise an exception on under/overflow, and a +~ b for maximum performance, leaving behavior on under/overflow undefined (including floats having undefined behavior on +-Inf and NaN).
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
The difference between Pony and Rust is that Pony allows easy reference cycle.
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.
OK, so having poked around the documentation a bit, I do think the Pony documentation could use a lot more examples. But there's one reasonably concrete example here:
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
This creates a new local variable, to_send. Then it atomically:
- 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)
The "consume" ensures that to_send can't be referenced after the consume call. So the compiler can verify that Receiver.receive() will be the only one able to access the old value of _data that we passed it.
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 probably my favorite programming language I would like to use if it had more backing. Their reference capabilities in particular seem like a very good match for the actor model. Alas, it does not appear to have a large corporation behind it pushing it forward, nor a compelling niche use case (e.g. it is still GC'd).
Having a Zulip (preferably self hosted) is sympathetic, compared to having shitty options like Slack. It indicates, that the people care about privacy. A zulip chat I would consider visiting, a Slack would be a hard pass.
As always with the languages, I think about what the ecosystem looks like. What libraries exist? Seems there is a list of available packages on their website: https://www.ponylang.io/use/packages/
I clicked one at random (net_ssl) to get a sense of what a package looked like in this ecosystem and how to install it, but it takes you straight to a github page which says it's deprecated and to use a different package (ssl) instead, which is not listed on the packages page.
Not a great look, although it looks like it was only deprecated 2 weeks ago, so I'll give them a pass.
With such sanctified list of libraries, I think it is not unlikely, that more packages exist out there, that are simply not listed, or that there are repos out there, showing how to do things, but are not isolated libraries.
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.
> Deadlock-Free: This one is easy because Pony has no locks at all! So they definitely don’t deadlock, because they don’t exist!
This really annoys me every time I read Pony description. What does deadlock free even mean here? Deadlock-free is typically the property of an algorithm, not a 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.
Paxos necessarily livelocks and still seems useful. More generically, all nonblocking algorithms which are only “obstruction-free” can livelock, but techniques like randomized backoff can make them quite reliable in practice (just like Paxos/Raft).
It would be technically deadlock free because you'd have a state that is unable to progress forward but it wouldn't technically involve a synchronisation primitive. In my view a real deadlock would actually be easier to debug but I'm just a caveman.
> Does it means that if I tried to implement a python interpreter in Pony it will statically reject the implementation?
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.
It means that the language and runtime both agree not to look at your dead-end state, so no-one can say it's their fault ;)
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.
That the logic you implement directly in Pony is deadlock-free. If you implement something that can represent arbitrary logic / represents deadlocks, then you get deadlocks again. This extends to every constraint-like language feature ever in any language.
Ok, partially evaluate the interpreter against a python always-deadlocking program. Now it no longer implement arbitrary logic, but it is a very specific program. Yet it deadlocks.
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.
Within the context of your Pony program you'll never be deadlocked. The virtual machine you implement capable of universal compute, and not enforcing this constraint, can be internally deadlocked, but this doesn't prevent your other Pony code from progressing necessarily - the deadlock is an internal state for that virtual machine, formally guaranteed to be confined to it.
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.
That's a bit like saying that pthreads is deadlock free because the Unix kernel can still schedule other programs. It is an useful guarantee, but it doesn't help fix my broken program.
Yes. If you want to encode soundness guarantees, you might want to look for a language with formal verification facilities instead, like Ada-SPARK.
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.
The difference is that there's only one exception type and it can't carry payloads. This turns out not to be very different from an option type like in Rust or Swift, just with a bit of syntactic sugar around it.
In Rust and Swift they can have payloads and variants, which in Rust's case due to lack of ergonomics, there are plenty of macro crates to work around this.
A fun fact about Pony: it solves the problem of division not being total by making integer division by zero equal zero! A few proof assistants and Elm take this approach too.
> Incorrectness is simply not allowed. It’s pointless to try to get stuff done if you can’t guarantee the result is correct.
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.
Even academic mathematics and computer science work like that to a degree.
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
I didn't say that but it isn't far from what I said. I said that we have from time to time seen that indications of non public use but there is nothing I can point to.
> I wish these language websites would put an example of some code right there on the homepage so I can see what the language "feels" like. I finally found some code in the tutorials https://tutorial.ponylang.io/getting-started/hello-world
+ 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 standard way to avoid these problems is to use locks to prevent data updates from happening at the same time. This causes big performance hits […]
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.
Sending a message between Actors can be just moving a pointer to a piece of shared memory.
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"
Unless you have NxN queues across actors[1], which is done on some specialized software but is inherently not scalable, queues will end up being more complex than that.
[1] at the very least you will need one queue for each cpu pair, but that's yet another layer of complication.
I think you only need one queue per actor? And then one worker per CPU core? I believe that how Erlang does it, and do millions of actors without any issues...
The way Erlang does it is to use buckets so it looks like a single queue to the user code but really is more like multiple queues behind the scene. Scales extremely well. It's certainly not "just moving a pointer to a piece of shared memory" though...
> Sending a message between Actors can be just moving a pointer to a piece of shared memory.
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.
Nit: you can’t have a 1-byte mutex unless you implement your own wait queues like parking_lot does. Any purely futex-based mutex (ie delegating all the blocking logic to futex syscalls) must be at least 4 bytes.
Why is this downvoted? It's factually correct, on-topic, and relevant (because it contradicts a claim on the linked website). If you disagree, say so and we can discuss it.
So does a contended queue. As much as I might like the model, message passing is not a silver bullet. Any sufficiently complex message passing system will end up implementing shared memory on top of it... and mutexes.
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.
>This is a type declaration. The keyword actor means we are going to define an actor, which is a bit like a class in Python, Java, C#, C++, etc. Pony has classes too, which we’ll see later.
> 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.
I personally thought it was pretty well-written. It sticks to the details that are relevant in the moment so it doesn't detract or get bogged down, but it does let you know what other things are there so it doesn't feel limited or barebones.
This is my pet peeve. "We'll get back to that later" is almost never a useful thing to say, particularly not in writing, and it often just increments the mental burden of the reader by adding another loose end. Instead, outline the concepts you need within context and provide a "Read more" link.
I wish these language websites would put an example of some code right there on the homepage so I can see what the language "feels" like. I finally found some code in the tutorials https://tutorial.ponylang.io/getting-started/hello-world
It is funny you say this, because nearly every posting of the Pony language includes this comment. And it is always apologized as you need to go to https://tutorial.ponylang.io/ which still doesn't have source on it.
I think Nim has a good homepage, with some bullet points explaining what the language is all about coupled with several code examples. I'm not saying Nim is better, but I visited the page the other day and thought it was neat.
I remember the first time I visited the DLang website. I clicked “What is D used for?” [0] and scrolled to the very first section, “1. Industry.” The opening example was “1. Games,” so naturally I went to read more…and found the first link, “AAA game,” was dead. It led straight to an error page on Xbox.
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.
I guess you're referring to the official link to quantumbreak.com. No one has probably noticed or pointed it out yet, I do not know where to raise it since I am not a member of the fourm. But the next sentence links to the presentation about the Game (Quantumbreak) and it's integration with Dlang.
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.
Yeah, that's exactly the thing I'd hope to see on anything trying to sell me on using a new language. Tell me about what it does, and show me how it does it
The way it handles imports is weird. Default to importing everything from the module without qualification? I know you can choose to qualify everything, but that seems to go against the language's conventions.
Nim's import rules are part of its generalization of OOP's obj.foo()
syntax. That is, in Nim, you don't have to put "foo" in a specific
class, just set the first parameter of "foo" to the type of "obj",
and this only works if you don't have to qualify "foo" (similarly to OOP
languages...)
I see this comment on all language postings and I just don’t get it. I’m much more curious about the motivation behind the language. If the syntax was that of APL, Forth, or Prolog would you just instantly ignore it because it doesn’t look like Java. I think if the language motivation is compelling then you can decide to dive into a tutorial where the syntax will be explained step by step. I don’t see how syntax can be judged before it is understood. Do you accept/reject languages over simple syntax like curly braces vs begin/end or significant white space, or abbreviations you don’t like eg. def, fun, defun, function, procedure.
Examples such as Hello, World! can tell you many things.
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,
I was also wondering what kind of language this is and where they were hiding all the code. Even the tutorial requires clicking past several pages of (more) introduction before you get to see any code. Probably better to lead with the code. Less waffling, more code would be my recommendation.
The syntax is the least interesting thing about the language, and hello-world examples demonstrate almost none of the syntax.
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."
> The syntax is the least interesting thing about the language, and hello-world examples demonstrate almost none of the 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)
the way i like to put it is that the syntax is the user interface of the language. if your user interface sucks, your product will not be pleasant to use, no matter how capable it is.
You're talking from a position I don't think many would agree with, at all, and I think the responses you're getting are reflecting that.
Syntax is probably one of the single most important things in any language. It matters for writing, but especially for reading.
Bad syntax leads to all kinds of implementation mistakes. It comes with footguns primed ready to go off, probably at the worst possible time.
Bad syntax can also make it hard to re-read code and understand what it's doing (especially if the language leans heavily on "magic"), leading to difficulties when troubleshooting, or difficulties when extending existing code.
The more developers you have involved in any project, the more important good syntax becomes, because you all have to be able to read and understand each other's code, and know precisely what is happening. A lot of the bugs that end up in production tend to stem from some disconnect in understanding of the interactions between sections of code.
Aside from this being argumentum ad populum, my upvotes and some of the other comments say otherwise. And I find comments like yours full of strawmen and taking things out of context, to the point where it's simply not worthwhile to debate the substantive points.
> Syntax is probably one of the single most important things in any language. It matters for writing, but especially for reading.
That appears to be your position (and maybe even that of a majority of developers), but it apparently isn't the position of the Pony developers. If you have a language in which you can mathematically reason about code (which Pony claims very prominently), then surface concerns such as syntax seem to matter less.
It's a different design goal and it feels like many people in the comments here don't appreciate that.
Lean 4 truly lets you mathematically reason about code and has metaprogramming that truly makes syntax a surface thing, but if anything people who know this have the taste to want better syntax
Good faith argumentation, or really argumentation in general, went out the window when you started treating whether syntax matters (for this language and in general) as a universal truth / (binary) logical statement rather than just an opinion.
One of the greatest problems in argumentation over the internet is that people gravitate towards acting as if every statement is intended to define a universal truth so they can argue against that strawman.
I don't think (or rather, want to think) that people are being intentionally malicious. Instead, I think this is a scaling issue. Natural language being scaled in ways it isn't prepared to (e.g. over the internet to random strangers from all walks of life with very different intentions).
I've been looking for platforms where one can maybe more formally encode their thoughts, so that the argumentation and debating skill barrier is lowered / eliminated, along with manipulation. And I did find some, but they don't quite hit the spot, and even if they did, people aren't really on them, so it doesn't matter sadly.
I appreciate your good intentions re the site guidelines! But I'm afraid you've been breaking them multiple times in this thread by being much too aggressive with other users. This post is one example, and here are two others:
It's laudable to want work like Pony to get discussed in terms of the most interesting things about it, but the best way to do this is to describe and explain more of what's interesting. It's not helpful to comment about how bad other comments are, and certainly not to cross into attack. Those things feed flamewars, as unfortunately happened badly in this thread. That's what we're most trying to avoid.
If “reference capabilities” are the important thing about Pony, they should have a max 100-200 LoC example on the front page that uses them.
As far as I can tell reading here, “reference capabilities” don’t do anything that properly-used C semaphores haven’t done for near half a century. Or that their abstraction of that isn’t nicer to use than, say, Elixir’s, or better than Rust’s borrow checker for managing mutability. A code example could convince me otherwise.
Show us code that uses “reference capabilities” to do something. This “the syntax doesn’t matter” talk just comes off as bullshit to devs wanting to actually use a language. It would be better to commit to a syntax, post some damn examples on the site, and let devs get used to “reference capabilities.” If the syntax needs revising, just do that in Pony v2.
If you want devs to be enthusiastic about your language, make it easy for them to understand why they should be enthusiastic. That means code, front and center, first thing.
If the syntax is great (I agree it doesn't seem bad at first glance) then the website attempting to sell the language should quickly demonstrate that syntax and capabilities. This is what the argument was about. "Can we see the syntax without clicking a dozen links?" "No, the syntax is not important."
Or 3rd option, the syntax is great but the creators are poor website designers because they came from the finance industry writing high performance back end systems...
We must not be communicating clearly, because that doesn't seem to me to have anything to do with what I wrote. I thought it was clear that the discussion was about the syntactic specifics of programming languages. I certainly wasn't claiming that Pony doesn't have a syntax, or that it's not important to use the correct syntax to write a Pony program.
People like to make themselves sound smart and important by finding the most trivial and low effort ways to discount and invalidate your point, instead of expending effort to respond to a more substantial argument that I could easily read from what you wrote. It's just the nature of online forums I think. It's easy (but incorrect) to conclude this place is full of jerks, because sometimes jerks are more likely to respond at all, and you don't get a baseline of how many people read your message but didn't reply at all.
I honestly think there's a certain number of people whose insecurities get triggered when they encounter something that they don't immediately understand and instead of concluding that it's not for them or that they lack prerequisite knowledge, they get angry and dismissive.
It's really more of an inversion. No true Scotsman is
"No Scotsman would ever (commit murder)"
"What about (Scotsman that committed murder)?"
"Ok, no true Scotsman would commit murder"
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 no true scotsman if you just resolve their indirection: no true scotsman would care about syntax, because a true scotsman is someone who doesn't care for such a thing - otherwise, they're people who GP finds to be of low value, and thus their opinion doesn't count, as they're no true scotsman, not true programmers.
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.
If it's a fallacy then it's nonsensical to call it true. But in fact that comment was not at all a True Scotsman Fallacy, or any other kind of fallacy. Saying that a certain kind of Scotsman puts sugar on his porridge is vastly different from saying that no true Scotsman puts sugar on his porridge.
Speaking of fallacies, it's complete nonsense (not the only example of it from that source) to say that the comment in question was a True Scotsman Fallacy (or any other kind of fallacy). 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.
Right, saying that only programmers who don't solve genuine problems and instead merely follow trends and treat it as fashion (and are thus no true scotsman) care about syntax, implying their opinion doesn't count, is definitely not a no true scotsman fallacy. It totally doesn't suggest that true scotsman heed the notion that syntax doesn't matter, and that so by definition, anyone else is just some goober following the cargo cult, so they don't count. [0] /s
The designer's syntax decisions tell you a lot about their semantic decisions, which languages they take inspiration from, and the language's philosophy about things like flexibility, correctness, and opinionatedness.
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.
Even caling this an example is a stretch... it's a hello world...that's it. I mean, at least show some conditionals, or something. We get it, your language is amazing, ok, so...can we see it now?
Exactly. A "try language" demo should dive right into an editable executor with syntax highlighting and API-docs floating tool tip code completion. Make it as painless and fast to understand as possible.
The Go playground actually has a dropdown menu with 15 examples, of which "Hello World" is merely the first; together they do a decent job of demonstrating the language's core features.
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).
The golang playground added those through time though. It f pony gets adoption (and I don’t know why it would) they likely would go through the same transition.
Mainly my point is it’s weird to complain about hello world. It’s been the first program for languages for decades.
That's not the home page and that's not what I'm talking about if you had bother to have read what I wrote that differs from a conventional and limited "try" playground. Also, I've used Pony before and gave up on it.
You also don't get to be the chief decider of what all of us may or may not talk about.
Honestly, I get it. The document wants to tell you what's new and different under the hood, not what the language looks like superficially. Code examples don't actually tell you what the language feels like in production. It's kinda like judging a person's character by how they dress.
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.
> 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 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.
Likewise, some people love the ABC and Python model of syntactically important leading whitespace while others passionately prefer some sort of brackets (for this purpose brackets include parentheses, curly braces, square brackets, words like BEGIN and END, etc).
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.
I think the emphasis should be on "nitpick" and "detract". Syntax is important, but they want people to focus on the fundamental or underlying concepts instead of the syntax first. With regarding taking criticisms: I think the person posting this submission may not be associated with the language to begin with. I wonder if any Pony developers are even reading it. Just my 2 cents.
In a way, leading with the core ideas and not with the syntax also shows what this language is about, and selects for people who are more interested in the PL concepts than its looks. After all, syntax is the bikeshed of programming language.
On the homepage, just move the descriptions to the left a bit, and put a big block on the right side where there is some example code that shows off the concepts a bit. It's not like they're struggling for space
Yea but the syntax looks like a mix of Python and JavaScript. By just seeing that I know I don’t want to use it, by seeing the code up front I know that I don’t want to keep reading what ever rationalizations they have to justify the existence of this language.
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.
> 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 agree and disagree completely with this statement. Syntax is superficial. It is the first thing that people will notice about the language (unless you hide it from them). One quickly notices that if you don't like a language syntax, you can always write a compiler that operates at a purely syntactic level to transform your desired syntax to the actual target language.
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).
You say that but I will never use Rust because of it's awful syntax, I'll stick with C/C++ and be happy and not miss out on anything. I don't know much about erlang so I have no comments on it.
It could eventually provide some, if Safe C++ (nee Circle) proposal had gotten a warm welcome by the WG21 committee unfortunately they rather go with the mythical profiles approach.
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.
Same impression. I was reading several pages with "Interesting.. interesting.. interesting.. but where is the code?". First code I managed to find was a Github repo with examples [0], and just now trying to follow the click path that led me to it, couldn't find it anymore. I looked up the link from my browser history.
Unfortunately this is true for basically any kind of “product”.
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!
I'm going to join the choir saying that languages need a concise description of what makes them special easily accessible — but while syntax is important, with a language like Pony (where the cool stuff is in the semantics), the cool semantics should be upfront.
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.
I agree with you, but also, it is legitimately hard to explain concisely the unique aspects of Pony's semantics. My short attempt at it from a couple years ago: https://news.ycombinator.com/item?id=33980738
Thank you! This is quite illuminating. It's not enough for me to know precisely how the language works or how it feels to program in it, but it allows me to put the language in a box so that I know what concepts it introduces and what problems it tries to fix. :)
What I haven't seen anyone mention yet is that syntax exists to concisely express semantics. If you want to give me an immediate feel for your interesting semantics, show me how you express them syntactically.
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.
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.
> 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.
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
Personally, I would say that if one is a real PL fanatic, one is more interested in the semantics than the syntax. :)
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.
I gave it an honest look for 5 minutes and after still only having found a 3-line hello world I gave up (and came here to complain).
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.
Sure, if I go dig deep I'll find that. But I was talking about the sales pitch. Once it's necessary to go click links in a levels-down comment in the HN discussion section, you've already lost most folks.
I personally found the descriptions of the concepts and ideas more illuminating and interesting than a code example. If you're only looking to nitpick the superficial syntax, kinda like judging a person's character by how they dress, then I guess you're not in the target audience for this documentation.
I don't care about syntax. The concepts were too abstract though. I'm sure these descriptions make sense if you already know what it's about, but in that case you are hardly the target audience..
> Most people visiting such websites are programmers who are more often than not busy as all hell.
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.
> Apparently not too busy to visit HN and post shallow dismissals.
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".
Could be true actually, thanks for the perspective. Though I still would not describe it as complaining, it's more like "Have you thought about that group of potential users?".
I'm not necessarily a fan of the original wording "shitty behaviour", but I do find it disappointing that half of the comment section is people complaining about the lack of code examples. It's just not very interesting feedback and makes the discussion worse.
And half those comments have been misinterpeted to literally mean code. More concrete illustrations of the concepts would have been nice. Not everybody is well versed in what Erlang-like actors are, or capabilities, and how they play so nicely in the single-threaded actors. I know what a thread is. I know what type safety is. But what in Pony make that? How is Pony different from other languages that provide these things? If you require your audience to first read a book to know whether they are interested, then your audience will be much smaller than necessary.
Instead of dismissing these comments as rants and shitty behavior, maybe consider them as an indication how things could be improved. You can inore that (free) advice of course, just like people are free to ignore you. Your choice to make.
This is by definition a critical comment which teaches something, ie if you don't present viewers with pertinent information about your project, they cannot take an interest in your project. I think it should be noted that both GP and another few highly rated comments are making this exact point.
"by definition"? It's apparently something you believe, but it certainly isn't a tautology. And I don't think that's an accurate characterization of that comment, at all.
Without wanting to derail the conversation too much.
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...
Notable the Microsoft has not one but two actor model "frameworks": Orleans (for .NET) and Dapr Actors (for containerized workloads).
The .NET ecosystem itself has another mature actor-based framework in Akka.NET, being probably closest to the Erlang/Elixir supervisor style, in C#/F#.
Highly recommend Akka(.NET). Batteries included framework that scales really well.
Probably even more, most folks aren't aware of how many research is sponsored by Microsoft Research across all their university sites.
Is Verona still receiving attention? Seems like a quiet project.
Last I chatted with Tobias Wrigstad, work is still happening on Verona.
The paper I mentioned, is also done as part of Verona project
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.
If you want to dive right into what seems like the first key "interesting" idea, it's here:
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.)
August 15th and 16th there will be a talk on Pony at the Carolina Code Conference in Greenville, SC.
https://carolina.codes
Was this meant to be a reply to the top-level story, and not a specific comment?
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).
I just clicked the first reply button in a hurry when I saw the Pony thread. It's hard to turn off the conference promoter mode. :-)
My apologies.
Moved to toplevel now :)
I love the syntax for checked math. a + b for wrap around, a +? b to raise an exception on under/overflow, and a +~ b for maximum performance, leaving behavior on under/overflow undefined (including floats having undefined behavior on +-Inf and NaN).
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
It's interesting that Rust and Pony have différent default for addition.
The difference between Pony and Rust is that Pony allows easy reference cycle.
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.
And that it has a nice garbage collector, which is good enough due to the way capabilities work, being per actor, and how references work.
OK, so having poked around the documentation a bit, I do think the Pony documentation could use a lot more examples. But there's one reasonably concrete example here:
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:
This creates a new local variable, to_send. Then it atomically:- 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:
The "consume" ensures that to_send can't be referenced after the consume call. So the compiler can verify that Receiver.receive() will be the only one able to access the old value of _data that we passed it.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 probably my favorite programming language I would like to use if it had more backing. Their reference capabilities in particular seem like a very good match for the actor model. Alas, it does not appear to have a large corporation behind it pushing it forward, nor a compelling niche use case (e.g. it is still GC'd).
I loved playing with this a few years ago, but have lost track of it for a while.
The causality model was great, but is there a way to handle backpressure now?
I was randomly looking at examples and I think this is one showing that: https://github.com/ponylang/ponyc/blob/main/examples/under_p...
Notable for the GC (ORCA) and the sharing model. They have a Zulip[0] and a weekly office hours.
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...
Having a Zulip (preferably self hosted) is sympathetic, compared to having shitty options like Slack. It indicates, that the people care about privacy. A zulip chat I would consider visiting, a Slack would be a hard pass.
Discussion from 4 years ago: https://news.ycombinator.com/item?id=25957307
Thanks!
Pony – High-Performance Safe Actor Programming - https://news.ycombinator.com/item?id=25957307 - Jan 2021 (152 comments)
There is a nice Podcast about choosing the right programming language for a project and in this, the final choice is relevant to this post :)
https://corecursive.com/055-unproven-with-sean-allen/
Related. Others?
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)
As always with the languages, I think about what the ecosystem looks like. What libraries exist? Seems there is a list of available packages on their website: https://www.ponylang.io/use/packages/
I clicked one at random (net_ssl) to get a sense of what a package looked like in this ecosystem and how to install it, but it takes you straight to a github page which says it's deprecated and to use a different package (ssl) instead, which is not listed on the packages page.
Not a great look, although it looks like it was only deprecated 2 weeks ago, so I'll give them a pass.
Thanks. I had missed that.
https://github.com/ponylang/ponylang-website/commit/89211a89...
With such sanctified list of libraries, I think it is not unlikely, that more packages exist out there, that are simply not listed, or that there are repos out there, showing how to do things, but are not isolated libraries.
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.
> Deadlock-Free: This one is easy because Pony has no locks at all! So they definitely don’t deadlock, because they don’t exist! This really annoys me every time I read Pony description. What does deadlock free even mean here? Deadlock-free is typically the property of an algorithm, not a 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.
It is based on actors and "reference capabilities". These two blogs[1,2], could provide nice introduction.
1. https://blog.jtfmumm.com//2016/03/06/safely-sharing-data-pon... 2. https://bluishcoder.co.nz/2017/07/31/reference_capabilities_...
That's quite interesting, but it doesn't answer the question: Would the python program running on an interpreter written in pony deadlock or not?
It would livelock
I wouldn't call it a livelock, because I wouldn't expect the runtime to be doing any (useless) work on behalf of the program.
Still, trading deadlocks for livelocks is a net negative as they are harder to identify and diagnose.
Paxos necessarily livelocks and still seems useful. More generically, all nonblocking algorithms which are only “obstruction-free” can livelock, but techniques like randomized backoff can make them quite reliable in practice (just like Paxos/Raft).
It would be technically deadlock free because you'd have a state that is unable to progress forward but it wouldn't technically involve a synchronisation primitive. In my view a real deadlock would actually be easier to debug but I'm just a caveman.
> Does it means that if I tried to implement a python interpreter in Pony it will statically reject the implementation?
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.
Well, yes, that's my point. So what does it means that Pony is deadlock-free?
It means that the language and runtime both agree not to look at your dead-end state, so no-one can say it's their fault ;)
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.
As someone that has spent the last week debugging a possible deadlock in pure async message passing code, I'm not amused :).
That the logic you implement directly in Pony is deadlock-free. If you implement something that can represent arbitrary logic / represents deadlocks, then you get deadlocks again. This extends to every constraint-like language feature ever in any language.
Ok, partially evaluate the interpreter against a python always-deadlocking program. Now it no longer implement arbitrary logic, but it is a very specific program. Yet it deadlocks.
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.
Within the context of your Pony program you'll never be deadlocked. The virtual machine you implement capable of universal compute, and not enforcing this constraint, can be internally deadlocked, but this doesn't prevent your other Pony code from progressing necessarily - the deadlock is an internal state for that virtual machine, formally guaranteed to be confined to it.
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.
That's a bit like saying that pthreads is deadlock free because the Unix kernel can still schedule other programs. It is an useful guarantee, but it doesn't help fix my broken program.
Yes. If you want to encode soundness guarantees, you might want to look for a language with formal verification facilities instead, like Ada-SPARK.
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.
"Exception-Safe¶ There are no runtime exceptions. All exceptions have defined semantics, and they are always caught."
So checked Exceptions like Java?
The difference is that there's only one exception type and it can't carry payloads. This turns out not to be very different from an option type like in Rust or Swift, just with a bit of syntactic sugar around it.
In Rust and Swift they can have payloads and variants, which in Rust's case due to lack of ergonomics, there are plenty of macro crates to work around this.
Yeah, to be clear, it's similar to an option type rather than a result type.
Checked exceptions like CLU, Modula-3 and C++, before Java came into the world.
Or checked result types as in many FP languages, which many seem to miss the similarity.
A fun fact about Pony: it solves the problem of division not being total by making integer division by zero equal zero! A few proof assistants and Elm take this approach too.
https://youtu.be/u9da3UzEhEI
For those who enjoy long form video interviews, here is Kris Jenkins of Developer Voices interviewing Sean Allen on Pony language
> Incorrectness is simply not allowed. It’s pointless to try to get stuff done if you can’t guarantee the result is correct.
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.
Even academic mathematics and computer science work like that to a degree.
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
It's a great concept but the ecosystem, tooling, and stewardship are really crap.
It's sad that the only company using it in production switched to using Rust.
The only company "publicly" using it. I know Sean has mentioned there's a lot of fintech (i think) using it, just not blogging about it.
I didn't say that but it isn't far from what I said. I said that we have from time to time seen that indications of non public use but there is nothing I can point to.
Here is a talk about Pony
https://www.youtube.com/watch?v=WlGSpYFntUU
I think this is the first time I've seen a github badge (with number of stars) that's for the website itself and not the language repo!
Sorry for another complaint, but after skimming through I only see boasting paragraphs without any real information
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
I lost track of how many links I had to click to get to a screen that had a line of code.
> I wish these language websites would put an example of some code right there on the homepage so I can see what the language "feels" like. I finally found some code in the tutorials https://tutorial.ponylang.io/getting-started/hello-world
+ 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.
Bringing more pony play into computing.
What's new next we can see?
I keep being irritated by the fact that Pony does not have operator precedences. You have to parenthesize arithmetics.
Took a while to find the Hello World. It looks like a sort of oop python.
Don't be tricked by syntax.
It's statically and strongly typed, and super concurrent. It's a very different vibe than anything python.
It doesn't look anything like Python (which is fine at OOP itself).
More like Pascal/Algol/Ada inspired than Python.
> The standard way to avoid these problems is to use locks to prevent data updates from happening at the same time. This causes big performance hits […]
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.
Sending a message between Actors can be just moving a pointer to a piece of shared memory.
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"
Unless you have NxN queues across actors[1], which is done on some specialized software but is inherently not scalable, queues will end up being more complex than that.
[1] at the very least you will need one queue for each cpu pair, but that's yet another layer of complication.
I think you only need one queue per actor? And then one worker per CPU core? I believe that how Erlang does it, and do millions of actors without any issues...
Yes, but now you have contention on the queue.
The way Erlang does it is to use buckets so it looks like a single queue to the user code but really is more like multiple queues behind the scene. Scales extremely well. It's certainly not "just moving a pointer to a piece of shared memory" though...
https://www.erlang.org/blog/parallel-signal-sending-optimiza...
> I think sending messages is more about the way you think about concurrency, more than the implementation.
That's a valid point of view, but Pony's claim to which I objected is about performance, not ease-of-use or convenience.
> Sending a message between Actors can be just moving a pointer to a piece of shared memory.
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.
Nit: you can’t have a 1-byte mutex unless you implement your own wait queues like parking_lot does. Any purely futex-based mutex (ie delegating all the blocking logic to futex syscalls) must be at least 4 bytes.
Why is this downvoted? It's factually correct, on-topic, and relevant (because it contradicts a claim on the linked website). If you disagree, say so and we can discuss it.
A contended mutex is a system call and likely stalls all the CPUs on your machine.
Lockfree spinlocks will only waste cycles on one CPU. A huge difference when you have dozens and hundreds of cores.
So does a contended queue. As much as I might like the model, message passing is not a silver bullet. Any sufficiently complex message passing system will end up implementing shared memory on top of it... and mutexes.
> A contended mutex is a system call […]
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.
>This is a type declaration. The keyword actor means we are going to define an actor, which is a bit like a class in Python, Java, C#, C++, etc. Pony has classes too, which we’ll see later.
> 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
I personally thought it was pretty well-written. It sticks to the details that are relevant in the moment so it doesn't detract or get bogged down, but it does let you know what other things are there so it doesn't feel limited or barebones.
This is my pet peeve. "We'll get back to that later" is almost never a useful thing to say, particularly not in writing, and it often just increments the mental burden of the reader by adding another loose end. Instead, outline the concepts you need within context and provide a "Read more" link.
I wish these language websites would put an example of some code right there on the homepage so I can see what the language "feels" like. I finally found some code in the tutorials https://tutorial.ponylang.io/getting-started/hello-world
It is funny you say this, because nearly every posting of the Pony language includes this comment. And it is always apologized as you need to go to https://tutorial.ponylang.io/ which still doesn't have source on it.
https://github.com/KittyMac/PonyCAT/blob/master/pony-cheat-s...
The project looks hostile to any sort of adoption.
I think Nim has a good homepage, with some bullet points explaining what the language is all about coupled with several code examples. I'm not saying Nim is better, but I visited the page the other day and thought it was neat.
https://nim-lang.org/
The D language home page has something similar with a drop down with code examples
https://dlang.org/
I was about to mention Dlangs website aswell, very well designed and clearly presents the language
I remember the first time I visited the DLang website. I clicked “What is D used for?” [0] and scrolled to the very first section, “1. Industry.” The opening example was “1. Games,” so naturally I went to read more…and found the first link, “AAA game,” was dead. It led straight to an error page on Xbox.
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.
[0] https://dlang.org/areas-of-d-usage.html
I guess you're referring to the official link to quantumbreak.com. No one has probably noticed or pointed it out yet, I do not know where to raise it since I am not a member of the fourm. But the next sentence links to the presentation about the Game (Quantumbreak) and it's integration with Dlang.
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.
Yeah, that's exactly the thing I'd hope to see on anything trying to sell me on using a new language. Tell me about what it does, and show me how it does it
Yeah I think Nim's website is well-made. You can see the features / pros of the language, with many different (and IMO cool) examples.
It still looks great with Javascript off, 3rd party frames disabled and no remote fonts, too, for us privacy nuts
Nim feels like the perfect language to me. Keep meaning to give it a shot for something.
The way it handles imports is weird. Default to importing everything from the module without qualification? I know you can choose to qualify everything, but that seems to go against the language's conventions.
Nim's import rules are part of its generalization of OOP's obj.foo() syntax. That is, in Nim, you don't have to put "foo" in a specific class, just set the first parameter of "foo" to the type of "obj", and this only works if you don't have to qualify "foo" (similarly to OOP languages...)
Highly recommend you give it a go! Good community, great libraries and the language itself is just bonkers performant without even trying.
I see this comment on all language postings and I just don’t get it. I’m much more curious about the motivation behind the language. If the syntax was that of APL, Forth, or Prolog would you just instantly ignore it because it doesn’t look like Java. I think if the language motivation is compelling then you can decide to dive into a tutorial where the syntax will be explained step by step. I don’t see how syntax can be judged before it is understood. Do you accept/reject languages over simple syntax like curly braces vs begin/end or significant white space, or abbreviations you don’t like eg. def, fun, defun, function, procedure.
Examples such as Hello, World! can tell you many things.
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.
I've always loved Factor's homepage, which includes a random snippet of non-trivial (i.e. small but not ‘hello world’) code: https://factorcode.org/
(also, velociraptors)
I was also wondering what kind of language this is and where they were hiding all the code. Even the tutorial requires clicking past several pages of (more) introduction before you get to see any code. Probably better to lead with the code. Less waffling, more code would be my recommendation.
The syntax is the least interesting thing about the language, and hello-world examples demonstrate almost none of the syntax.
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."
> The syntax is the least interesting thing about the language, and hello-world examples demonstrate almost none of the 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)
the way i like to put it is that the syntax is the user interface of the language. if your user interface sucks, your product will not be pleasant to use, no matter how capable it is.
For Pony in particular, the syntax is not important ... it's simply not the point of the language.
If the syntax is not important, that would mean coding in whitespace or malboge would be as easy as coding in python
[flagged]
You're talking from a position I don't think many would agree with, at all, and I think the responses you're getting are reflecting that.
Syntax is probably one of the single most important things in any language. It matters for writing, but especially for reading.
Bad syntax leads to all kinds of implementation mistakes. It comes with footguns primed ready to go off, probably at the worst possible time. Bad syntax can also make it hard to re-read code and understand what it's doing (especially if the language leans heavily on "magic"), leading to difficulties when troubleshooting, or difficulties when extending existing code.
The more developers you have involved in any project, the more important good syntax becomes, because you all have to be able to read and understand each other's code, and know precisely what is happening. A lot of the bugs that end up in production tend to stem from some disconnect in understanding of the interactions between sections of code.
"I don't think many would agree with"
Aside from this being argumentum ad populum, my upvotes and some of the other comments say otherwise. And I find comments like yours full of strawmen and taking things out of context, to the point where it's simply not worthwhile to debate the substantive points.
> Syntax is probably one of the single most important things in any language. It matters for writing, but especially for reading.
That appears to be your position (and maybe even that of a majority of developers), but it apparently isn't the position of the Pony developers. If you have a language in which you can mathematically reason about code (which Pony claims very prominently), then surface concerns such as syntax seem to matter less.
It's a different design goal and it feels like many people in the comments here don't appreciate that.
Lean 4 truly lets you mathematically reason about code and has metaprogramming that truly makes syntax a surface thing, but if anything people who know this have the taste to want better syntax
Good faith argumentation, or really argumentation in general, went out the window when you started treating whether syntax matters (for this language and in general) as a universal truth / (binary) logical statement rather than just an opinion.
One of the greatest problems in argumentation over the internet is that people gravitate towards acting as if every statement is intended to define a universal truth so they can argue against that strawman.
I don't think (or rather, want to think) that people are being intentionally malicious. Instead, I think this is a scaling issue. Natural language being scaled in ways it isn't prepared to (e.g. over the internet to random strangers from all walks of life with very different intentions).
I've been looking for platforms where one can maybe more formally encode their thoughts, so that the argumentation and debating skill barrier is lowered / eliminated, along with manipulation. And I did find some, but they don't quite hit the spot, and even if they did, people aren't really on them, so it doesn't matter sadly.
Indeed; thank you. That's certainly what happened here, together with ad hominem whataboutism.
[flagged]
I appreciate your good intentions re the site guidelines! But I'm afraid you've been breaking them multiple times in this thread by being much too aggressive with other users. This post is one example, and here are two others:
https://news.ycombinator.com/item?id=44728708
https://news.ycombinator.com/item?id=44722043
It's laudable to want work like Pony to get discussed in terms of the most interesting things about it, but the best way to do this is to describe and explain more of what's interesting. It's not helpful to comment about how bad other comments are, and certainly not to cross into attack. Those things feed flamewars, as unfortunately happened badly in this thread. That's what we're most trying to avoid.
[flagged]
Please don't perpetuate flamewars on HN, no matter how wrong someone else is or you feel they are. It just makes things worse.
https://news.ycombinator.com/newsguidelines.html
Apologies. Been trying to work on it, it's not easy.
Then make your arguments instead of making us try to read your mind. Why is Pony special?
See: https://www.ponylang.io/discover/why-pony/
I don't think that Pony is claiming to be novel in the area of syntax?
If “reference capabilities” are the important thing about Pony, they should have a max 100-200 LoC example on the front page that uses them.
As far as I can tell reading here, “reference capabilities” don’t do anything that properly-used C semaphores haven’t done for near half a century. Or that their abstraction of that isn’t nicer to use than, say, Elixir’s, or better than Rust’s borrow checker for managing mutability. A code example could convince me otherwise.
Show us code that uses “reference capabilities” to do something. This “the syntax doesn’t matter” talk just comes off as bullshit to devs wanting to actually use a language. It would be better to commit to a syntax, post some damn examples on the site, and let devs get used to “reference capabilities.” If the syntax needs revising, just do that in Pony v2.
If you want devs to be enthusiastic about your language, make it easy for them to understand why they should be enthusiastic. That means code, front and center, first thing.
A high performance Actor-based language is fairly unique. Pony is also very fast for a garbage collected language.
Also the syntax is great, probably my favourite language ever syntactically. Dunno why there's a pointless argument about it in these comments...
The reference capabilities are fairly novel as well. Apart from the lack of tooling, writing in Pony is great.
If the syntax is great (I agree it doesn't seem bad at first glance) then the website attempting to sell the language should quickly demonstrate that syntax and capabilities. This is what the argument was about. "Can we see the syntax without clicking a dozen links?" "No, the syntax is not important."
Or 3rd option, the syntax is great but the creators are poor website designers because they came from the finance industry writing high performance back end systems...
Having looked at some source examples, I'm pretty sure Pony has syntax errors just like every other parsed language.
We must not be communicating clearly, because that doesn't seem to me to have anything to do with what I wrote. I thought it was clear that the discussion was about the syntactic specifics of programming languages. I certainly wasn't claiming that Pony doesn't have a syntax, or that it's not important to use the correct syntax to write a Pony program.
People like to make themselves sound smart and important by finding the most trivial and low effort ways to discount and invalidate your point, instead of expending effort to respond to a more substantial argument that I could easily read from what you wrote. It's just the nature of online forums I think. It's easy (but incorrect) to conclude this place is full of jerks, because sometimes jerks are more likely to respond at all, and you don't get a baseline of how many people read your message but didn't reply at all.
Yes, thank you. I found the amount of bad faith in the responses is really rather shocking, but you have a good point about self-selection.
I honestly think there's a certain number of people whose insecurities get triggered when they encounter something that they don't immediately understand and instead of concluding that it's not for them or that they lack prerequisite knowledge, they get angry and dismissive.
[flagged]
"Eschew flamebait. Avoid generic tangents."
https://news.ycombinator.com/newsguidelines.html
This is textbook no true scotsman fallacy, you're aware, right?
It's really more of an inversion. No true Scotsman is "No Scotsman would ever (commit murder)" "What about (Scotsman that committed murder)?" "Ok, no true Scotsman would commit murder"
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 no true scotsman if you just resolve their indirection: no true scotsman would care about syntax, because a true scotsman is someone who doesn't care for such a thing - otherwise, they're people who GP finds to be of low value, and thus their opinion doesn't count, as they're no true scotsman, not true programmers.
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.
And? Doesn't mean it's not true. It just means you can't use it to win an argument against a nerd.
If it's a fallacy then it's nonsensical to call it true. But in fact that comment was not at all a True Scotsman Fallacy, or any other kind of fallacy. Saying that a certain kind of Scotsman puts sugar on his porridge is vastly different from saying that no true Scotsman puts sugar on his porridge.
> Doesn't mean it's not true.
True, it just means that it's idiotic, rather.
oof I'm pretty sure that's a fallacy, let me just consult the manual here...
Speaking of fallacies, it's complete nonsense (not the only example of it from that source) to say that the comment in question was a True Scotsman Fallacy (or any other kind of fallacy). 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.
Right, saying that only programmers who don't solve genuine problems and instead merely follow trends and treat it as fashion (and are thus no true scotsman) care about syntax, implying their opinion doesn't count, is definitely not a no true scotsman fallacy. It totally doesn't suggest that true scotsman heed the notion that syntax doesn't matter, and that so by definition, anyone else is just some goober following the cargo cult, so they don't count. [0] /s
> 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
Keep us updated.
[flagged]
The way a Ferrari looks is the least interesting part of it too. I still want to see the thing front and center on its homepage.
The syntax is the language. To show me the language you have to show me its syntax.
"The syntax is the language."
This is obviously false.
The designer's syntax decisions tell you a lot about their semantic decisions, which languages they take inspiration from, and the language's philosophy about things like flexibility, correctness, and opinionatedness.
Or not. Mostly not in this case.
I agree, in the case of Pony the interesting stuff is mentioned on this page:
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.
Indeed. I wonder how many people here even read the title of the post.
It's not only about showing off syntax. It's also about showing what type of applications the language makes easy to implement.
But that's not what was asked for. To find that out, one must dig fairly deeply into the documentation ... at least read the About page.
Example pony applications: https://github.com/ponylang/ponyc/tree/main/examples
Playground: https://playground.ponylang.io/
They're on HP https://www.ponylang.io/ unfortunately the article link points to /discover/
Even caling this an example is a stretch... it's a hello world...that's it. I mean, at least show some conditionals, or something. We get it, your language is amazing, ok, so...can we see it now?
Exactly. A "try language" demo should dive right into an editable executor with syntax highlighting and API-docs floating tool tip code completion. Make it as painless and fast to understand as possible.
You mean this executor[0] which is linked right there on the page we are discussing here?
[0]: http://playground.ponylang.io/
They should probably put more than three lines of code in there?
The rust and golang versions are exactly the same.
Printing hello world is the default of the industry for this sort of thing.
The Go playground actually has a dropdown menu with 15 examples, of which "Hello World" is merely the first; together they do a decent job of demonstrating the language's core features.
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).
The golang playground added those through time though. It f pony gets adoption (and I don’t know why it would) they likely would go through the same transition.
Mainly my point is it’s weird to complain about hello world. It’s been the first program for languages for decades.
That's not the home page and that's not what I'm talking about if you had bother to have read what I wrote that differs from a conventional and limited "try" playground. Also, I've used Pony before and gave up on it.
You also don't get to be the chief decider of what all of us may or may not talk about.
Also it took surprisingly many clicks to see any code. After 3 clicks I had impression that it is not yet a language, just and idea for one.
Honestly, I get it. The document wants to tell you what's new and different under the hood, not what the language looks like superficially. Code examples don't actually tell you what the language feels like in production. It's kinda like judging a person's character by how they dress.
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.
> 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 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.
Likewise, some people love the ABC and Python model of syntactically important leading whitespace while others passionately prefer some sort of brackets (for this purpose brackets include parentheses, curly braces, square brackets, words like BEGIN and END, etc).
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.
> people reading code examples will nitpick minor pet peeves in the syntax and completely detract from the actual news ideas and concepts
Err, ok, so? Don't be so afraid of criticism, I guess? Yeah, some people will nitpick. I don't see the problem.
I think the emphasis should be on "nitpick" and "detract". Syntax is important, but they want people to focus on the fundamental or underlying concepts instead of the syntax first. With regarding taking criticisms: I think the person posting this submission may not be associated with the language to begin with. I wonder if any Pony developers are even reading it. Just my 2 cents.
In a way, leading with the core ideas and not with the syntax also shows what this language is about, and selects for people who are more interested in the PL concepts than its looks. After all, syntax is the bikeshed of programming language.
On the homepage, just move the descriptions to the left a bit, and put a big block on the right side where there is some example code that shows off the concepts a bit. It's not like they're struggling for space
Yea but the syntax looks like a mix of Python and JavaScript. By just seeing that I know I don’t want to use it, by seeing the code up front I know that I don’t want to keep reading what ever rationalizations they have to justify the existence of this language.
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.
> 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 agree and disagree completely with this statement. Syntax is superficial. It is the first thing that people will notice about the language (unless you hide it from them). One quickly notices that if you don't like a language syntax, you can always write a compiler that operates at a purely syntactic level to transform your desired syntax to the actual target language.
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).
You say that but I will never use Rust because of it's awful syntax, I'll stick with C/C++ and be happy and not miss out on anything. I don't know much about erlang so I have no comments on it.
> I will never use Rust because of it's awful syntax, I'll stick with C/C++
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?
> and not miss out on anything
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
It could eventually provide some, if Safe C++ (nee Circle) proposal had gotten a warm welcome by the WG21 committee unfortunately they rather go with the mythical profiles approach.
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.
Same impression. I was reading several pages with "Interesting.. interesting.. interesting.. but where is the code?". First code I managed to find was a Github repo with examples [0], and just now trying to follow the click path that led me to it, couldn't find it anymore. I looked up the link from my browser history.
[0] https://github.com/ponylang/ponyc/tree/main/examples
Unfortunately this is true for basically any kind of “product”.
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!
Probably hiding the fact that it's whitespace significant
It's not.
I also (usually) go looking right away to see if the syntax makes me feel warm and fuzzy. I’m so shallow.
Agreed. Pony even has nice syntax. Web page is pretty bad though.
I wish these new languages would put an elevator pitch on first page.
Why another object language?
[dead]
I'm going to join the choir saying that languages need a concise description of what makes them special easily accessible — but while syntax is important, with a language like Pony (where the cool stuff is in the semantics), the cool semantics should be upfront.
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.
I agree with you, but also, it is legitimately hard to explain concisely the unique aspects of Pony's semantics. My short attempt at it from a couple years ago: https://news.ycombinator.com/item?id=33980738
Thank you! This is quite illuminating. It's not enough for me to know precisely how the language works or how it feels to program in it, but it allows me to put the language in a box so that I know what concepts it introduces and what problems it tries to fix. :)
What I haven't seen anyone mention yet is that syntax exists to concisely express semantics. If you want to give me an immediate feel for your interesting semantics, show me how you express them syntactically.
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.
I don't have a one-page overview of Pony, but I did listen to https://corecursive.com/055-unproven-with-sean-allen/ in the car a couple of times and that made me want to try it.
Request to HN mods: that the link be changed from
https://www.ponylang.io/discover/
to
https://www.ponylang.io/
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.
> 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.
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?
Ok, I've done that and put the other links at the top.
Personally, I would say that if one is a real PL fanatic, one is more interested in the semantics than the syntax. :)
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.
[1]: https://news.ycombinator.com/item?id=44722779
I gave it an honest look for 5 minutes and after still only having found a 3-line hello world I gave up (and came here to complain).
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.
Example pony applications: https://github.com/ponylang/ponyc/tree/main/examples
Playground: https://playground.ponylang.io/
They're on HP https://www.ponylang.io/ unfortunately the article link points to /discover/
Sure, if I go dig deep I'll find that. But I was talking about the sales pitch. Once it's necessary to go click links in a levels-down comment in the HN discussion section, you've already lost most folks.
They aren't selling anything, and they didn't write their documentation with HN in mind ... the OP is probably not associated with them.
>they didn't write their documentation with HN in mind
The programming language documentation wasn't written for an audience primarily composed of programmers? That would be an odd choice.
[flagged]
I personally found the descriptions of the concepts and ideas more illuminating and interesting than a code example. If you're only looking to nitpick the superficial syntax, kinda like judging a person's character by how they dress, then I guess you're not in the target audience for this documentation.
I don't care about syntax. The concepts were too abstract though. I'm sure these descriptions make sense if you already know what it's about, but in that case you are hardly the target audience..
It's entirely possible to not want to look at an ugly person without casting aspersions as to their character.
And you cannot have both at the same time, because...?
[flagged]
[flagged]
> Most people visiting such websites are programmers who are more often than not busy as all hell.
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.
> Not everything is for everyone and expecting every project to cater to your very specific needs is rather entitled.
Wild response to simply receiving feedback on the design of a website.
I'm afraid UI/UX design principles are universal, a website about a language is going to have to hit certain criteria to be any good.
> Apparently not too busy to visit HN and post shallow dismissals.
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".
Could be they meant the "shitty behaviour" was the complaining, not the moving on.
Could be true actually, thanks for the perspective. Though I still would not describe it as complaining, it's more like "Have you thought about that group of potential users?".
I'm not necessarily a fan of the original wording "shitty behaviour", but I do find it disappointing that half of the comment section is people complaining about the lack of code examples. It's just not very interesting feedback and makes the discussion worse.
And half those comments have been misinterpeted to literally mean code. More concrete illustrations of the concepts would have been nice. Not everybody is well versed in what Erlang-like actors are, or capabilities, and how they play so nicely in the single-threaded actors. I know what a thread is. I know what type safety is. But what in Pony make that? How is Pony different from other languages that provide these things? If you require your audience to first read a book to know whether they are interested, then your audience will be much smaller than necessary.
Instead of dismissing these comments as rants and shitty behavior, maybe consider them as an indication how things could be improved. You can inore that (free) advice of course, just like people are free to ignore you. Your choice to make.
I feel this comment is already much more constructive than your original one.
Btw I'm not affiliated with Pony in any way, so I have no influence on what and how things could be improved in the docs.
dang recently pointed me to the HN guidelines. I think this one applies here:
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
This is by definition a critical comment which teaches something, ie if you don't present viewers with pertinent information about your project, they cannot take an interest in your project. I think it should be noted that both GP and another few highly rated comments are making this exact point.
"by definition"? It's apparently something you believe, but it certainly isn't a tautology. And I don't think that's an accurate characterization of that comment, at all.
new lang? show me Hello World on home page or I bounce
not hard, kids