On the State of Pony
pony.groups.io
pony.groups.io
The two major things that I stumbled on when I first started using Pony was that there is no blocking constructs in the language and dealing with capabilities.
I've had exposure to memory safe languages using types before (ATS, Rust) so the Pony system of capabilities wasn't too difficult to understand once I was able to map them to things I was familiar with. Before that I struggled to understand why things weren't compiling. Now that things have somewhat clicked I'm pretty productive with the language.
Dealing with writing non-blocking code was a matter of thinking in terms of callbacks and promises - something familiar to a lot of Node programmers I suspect.
Once I got past those two things I find the language very nice to write in and easy to reason about the code. Sometimes I hit walls of struggling to work out why things aren't compiling and they eventually end up being the compiler showing me what I was trying to do would be unsafe due to data races, etc.
The language is still young though so definitely something to approach with a bit of understanding that things may break.
You have the stomach for a relatively immature language
Re Erlang/Elixir the number 1 selling point would be if you need performance that you can't get from Erlang/Elixir.
Re Akka on the JVM, the number 1 selling point would be you want predictable latencies from your GC that you can't get from the JVM.
Along with those, you get a type system that enforces data-race safety which now that I am using Pony daily, is the #1 selling point for me.
Most message passing on BEAM is done via copying. Pony can share the memory directly because the compiler enforces safe sharing via deny capabilities. You can only send 3 basic types to another actor:
iso -> mutable memory that you have the sole reference to val -> immutable reference. you can read but you can't write tag -> an opaque reference. good for sending messages to actors or doing identity comparisons
The type system certainly helps as well. It allows us to give LLVM hints on optimizations it can make. The type system also helps because we can do "dangerous but fast" things safely because we can prove they are safe in this instance.
Compiling to native code via LLVM is another area for performance wins.
That said, Erlang has over 20 years of rock solid production usage behind it and that unto itself is a quite a selling point. At this point in time, I'd suggest Pony to Erlang/Elixir users if they need more performance, otherwise, I'd stick with Erlang for now.
> The type system also helps because we can do "dangerous but fast"
> things safely because we can prove they are safe in this instance.
Static typing would mean the engine can know for sure what |foo| is and where to look for |bar|, allowing faster, guaranteed-correct code to be emitted ahead of time. Dynamic typing makes it harder to offer speed, correctness, security, and good memory usage all at once.
Mercury has uniqueness types, so can be remain referentially transparent while compiling to code that mutates. The compiler has fairly advanced automatic parallelization and can in some cases do compile-time garbage collection (i.e. it knows at compile time when an object will become inaccessible).
--
See e.g. https://bluishcoder.co.nz/2010/06/02/safer-c-code-using-ats....
That said, thanks for your work on Rust! Count me a big fan of the language.
Also, I think saying that the ATS has no unsafe{} sections is misleading: it isn't explicitly marked in the source, but the compiler still cannot check the "ownership" annotations in the imports are correct, or that, say, the preconditions of the functions (which may lead to undefined behaviour when violated) are satisfied. In other words, all of that code is implicitly surrounded in an `unsafe` block.
A Rust API designed for people to use will also not have unsafe code, e.g. https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhe...
(The linearity is essentially handled by destructors: the common case is the clean-up is just that, clean-up, and so destructors work well. It is definitely more annoying to 100%-type-check APIs that have more interesting clean-up/closing procedures but these are rarer.)
You end up with a definition that checks at compile time that:
* We don't exceed the memory bounds of the source buffer
* We don't exceed the memory bounds of the destination buffer
* The destination buffer is at least the minimium size required by the function documentation
* We can't treat the destination buffer as a string if the function fails
* We can't treat the destination buffer as an array of bytes if the function succeeds
* Off by one errors due to null terminator handling are removed
* Checking to see if the function call failed is enforced
And there's no overhead at runtime.
Aren't you mixing up flexibility for the programmer with flexibility for the compiler?
The more restrictions the programmer has, the more flexibility the compiler has to change instructions and still produce the same results.
It's garbage collector is superior, having to do much less work than in beam.
The data workload for each thread is much smaller. objects are tiny, messages are mostly referenced (shared) and not copied.
erlang does more. it already supports distributed actors, so there's a little overhead also.
One nice thing about the Pony GC is it can GC actors that are waiting for messages but will never receive one. In some other languages I've used I end up with processes idling in a receive on channel living forever but never able to exit because nothing is going to put a message in the channel.
But it is still quite on the early days.
I honestly find a Code of Conduct unwelcoming, as it indicates that it's very likely that what I write will be attacked due to my identity, and that I may at any time be written out of the community in a modern version of damnatio memoriæ, even if I maintain a strict wall between my personal and professional lives (witness the people who attempted to shut down LambaConf because they disagree with Curtis Yarvin).
A Code of Conduct longer than 'be professional' is a signal that the community which professes it is hostile. They are, of course, free to be hostile; I am free to choose not to join them.
People who protested against LambdaConf 2016 organized alternative confrence MoonConf at the same place at the same time. Two conferences had cordial relationship. Nothing people worried about actually happened.
Don't be an asshole.
Don't be an asshole to women.
Don't be an asshole to sexual or racial minorities.
Be a decent human being. Don't harass people.
If someone's identity is predicated on being an asshole, it will drive non-assholes out. I'm glad that assholes will self-select themselves out of such situations.
But perhaps I am prejudiced. I prefer the company of non-assholes.
Perhaps the title should say "Pony Language".