Well, isn't that a zero content statement?
Sure, if you can't help in managing problems (and hard problems) the language is not that good.
But I'd argue a language succeeds or fails in helping you manage problems through its syntax, expressiveness, paradigms, models, and other attributes (like community size, lib ecosystem, tooling, speed, etc).
The amount of times new language conversations nitpick c-style semicolons and curly brace blocks, lisp's parentheses, prolog ending statements with a ., or Python's significant whitespace ... It's exhausting. If I never have to read the words "visual line noise" causing "cognitive load" again I'll be happy. It's not that those aren't occasionally interesting but they are over trodden topics.
I've found myself steering conversations like this: "It's not the language it's the runtime!" Whats interesting about erlang, go, and pony are the runtimes. The languages play a role in how they expose those goodies but that's a conversation well beyond whitespace and semicolons.
In addition to being the submitter, I'm also the author and a member of the Pony core team. I'll check the comments here from time to time and answer what I can.
You could consider some runnable demos like python and rust's. , 
Also, pony is still an early product. It's secure, but it still needs more work before extremely important work happens using pony.
In that regard, it's better to attract only those who propel themselves then to attract a bunch of users who wont/cant contribute and will impose their demands on the core team.
It's just not time to market yet.
There's a good talk by Scott Fritchie on the differences between Pony and Erlang that I would suggest.
Like Erlang, each Pony actor has a mailbox that is processed in a serial fashion so that only one message is being processed.
In Erlang, you have selective receive that allows you to receive messages out of order that they arrived. Pony has causal messaging where each message has to be handled in the order it was received. Otherwise they are same in terms of how received messages are handled.
There's no `receive` in Pony as the behaviors are called directly.
I would not call that "very limited and bare bones". Its different.
The Pony runtime takes care of scheduling an actor to run when there is a message for that actor. The actor runs through the behavior and then waits to be scheduled again by the runtime when another message is available. If you want to filter messages you need to arrange a way to do that in your code. There's no way to inspect the message queue.
I can elaborate a bit on what is in the tutorial.
With the current semantics, you as the application programmer can check for division by zero and throw `error` if you want. Otherwise, every division operation would be partial which given that pony forces you to handle all partial functions, can get to be very painful.
We are working on adding value dependent types and will be revisiting the divide by 0 question. Some work was done on that for a thesis a couple years back but hasn't been integrated into Pony by the author as they have had time constraints since leaving school. You can check out a video about the work here: https://vimeo.com/175746403
It's definitely something that folks bring up. We aren't thrilled with the current functionality but feel its better than the previous functionality and are looking to slow improve the situation over time.
It can definitely bite the uninitiated if they aren't careful.
PS: This is the approach PHP took in the early days too.
For a recent discussion about this on the Isabelle mailing list, see here https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2018-Mar... (search for 1/0)
>>> 0.3 * 3.0
There's are a lot of areas of computer science that touch on these sorts of problems. And people love to do Wat! talks for all those fun edge cases where how computers work and how programming languages work run up against our expectations of what we expect to be correct.
Throwing an error is actually “wrong” as the result should actually be undefined/null but most languages throw for practical reasons.
So in fact it’s most languages that are being “wrong but functional”. Pony is just functioning differently.
If it’s raised and documented well there’s no reason it wouldn’t work as undefined (could throw type errors on usage after that for example).
Well, it can be argued that physics dictates an error is intrinsically better than 0, and that programs care about physics at least as much as about mathematics.
I know it's kind of stupid, but relying on such a huge behemoth was my biggest turnoff.
Also you can use the Visual C++ Build Tools, which is just the compiler without the IDE.
if not x() then error end
if not y() then error end
// which error happened?
Looking at your example, I would say, if you care about which error happened, you should be using separate try blocks.
Errors aren't meant for flow control like that so really, you shouldn't be indicating error inside a try like that.
One option that Pony could have gone with is to use union types to always indicate errors:
(My Result | MyError)
There's overhead to that though. You always have to match on the type. For situation where an error is unlikely, partial functions are nice. Partial functions are not exceptions though, and aren't designed to do flow control so trying to use like some might use exceptions (to do flow control) is going to be painful (as your example points out) because they weren't designed for that use case.
You should use a union type for that situation. Note, the current File API in the Pony standard library doesn't do that and it's something that we intend to fix before version 1.0. At this point, now one has gotten frustrated enough with it to open an RFC to propose an updated API. Someone will at some point though. But... volunteer project, limited time, itch to scratch etc.
Fortunately Rust doesn’t do this and has a big example right at the top of its front page.
I’m primarily working in JS these days and it felt very familiar and approachable so...
Would like to see a summary of what those tradeoffs are. Very curious!
Both are difficult for folks just learn the languages to grasp. When I tried doing async programming in Rust, I found the borrow checker especially hard to deal with. Pony's reference capabilities, once you understand them, apply quite naturally to async code. This is important as most actions in Pony involve sending asynchronous messages between actors. There are certain patterns of passing around isolated regions of memory that are a pain in the ass to do in Pony that are very easy to do in Rust (once you know how to work with the borrow checker). It's something we are aware of on the Pony and are working to address.
Reference capabilities are part of the type of variables. This can make writing your own generics really hard unto you have a really good grasp of the type system and reference capabilities. It's the steepest learning curve in all of Pony.
Reference capabilities exist only at compile time but, something about how people think about them leads people to wanting to be able to match on them at runtime. I suspect this is something about how we teach them. It's a bit of a hurdle for some folks and can lead to some confusion early on.
Someone who has spent more time writing Rust and helping people learn Rust could come up with a similiar list. From time to time, Steve Klabnik and I have talked about similiarities in how problems folks have in learning the two languages.
I prefer reference capabilities to the borrow checker because reference capabilities more closely align with how I think about data safety.
I'd like to do a comprehensive comparison someday, but just don't have the time...
An early version of the Pony runtime is in use at one of the large banks in the UK.
There's a couple other uses that I've heard of that I'm not at liberty to talk about.
Publicly, Wallaroo Labs (where I work) is the only company talking about their usage.
It's still early days for Pony. Pre-1.0 and all that. Plenty of improvements that we want to make to the language, the standard library and ecosystem before it makes it to 1.0.
Pony normally works out of the box, because quite a bit can just be passed by value. You can pass by reference using reference capabilities, but there's a lot less cognitive overhead there, and a lot less fighting the compiler. I think, in the future, Pony could even derive the capabilities required automagically in many cases.
I'd say the biggest issue is less around safety, but around the I/O, and FFI models.
> Yes you're right, we will put some code samples in earlier on.
Unfortunately for me the language felt a bit big and like it was doing too much (I guess you could say Elixir is in that same boat and I eventually got over that). It has the same "kitchen sink" problem as C++ and Scala. The use case for safe shared memory is interesting though and I'm keeping an ear to the project in passing
When people say this, do they mean that it's compiled to assembly? So what's native about it is the instruction set, yes?
Rubbish; nonsense, or 'of poor quality'. Often shortened just to 'pony'.
What's the origin of the phrase 'Pony and trap'?
This is Cockney rhyming slang - pony and trap -> crap.