We love when folks notice us, hopefully a couple people who read this end up in the Pony community. That said, the "better-than-Rust" makes me uncomfortable. Pony and Rust have different goals and make different tradeoffs with regard to memory safety. We don't think one is better than the other. They are different.
I just had a thought that made me ridiculously excited. Like in Pony, doing FFI in Rust is unsafe for obvious reasons. But would it be possible to define a subset of the typesystems of both languages to have a possibility of calling Rust code safely from Pony? (I doubt it would work another way around, since Pony needs its runtime.) That would create super cool synergy with ergonomic and ultra safe Pony and ultra performant and safe Rust.
I think that would be really great. You can already call Rust code via FFI, but it looks like that languages have a lot in common with the LLVM backend, and memory- and type-safety. Imagine the boost to productivity Pony users would get if they could call Rust code from the crates.io ecosystem from Pony, with next to no glue code?
By the way, I run the https://reddit.com/r/ponylang subreddit. I mentioned it a long time ago on the mailing list trying to get someone from the Pony team to join as a moderator, but don't think it ever fully panned out. If anyone on the team is interested, feel free to PM me on Reddit.
web framework? no. hopefully someone steps forward to do that. a couple folks have mentioned that they are building one or want to but so far nothing has materialized. personally i'm hoping that someone does a version of webmachine for Pony.
there's a http server that is part of the standard library but it wasn't written to be high-performance. it has good latency characteristics but poor throughput characteristics.
i've written a number of http servers during my career, don't really have the stomach to do another. hopefully in the not so distant future, someone writes one in Pony with an eye towards performance.
Rust is designed to be a systems programming language in that it does not ship with a garbage collector. Pony does have a garbage collector. Comparing their memory safety is comparing very different categories of languages.
It would be better to compare pony's memory safety to a GC language: go, Java, C#, Haskell, etc.
I didn't read the docs in depth, but it seems that the extra safety Pony adds over Go, Java and C# is null-dereference safety, data race safety, exception safety and deadlock safety.
Go, Java and C# all suffer from all the problem above. Go in particular (due to confusing slicing semantics and dearth of immutable data structures) and C# slightly less (due to a lot of syntactic sugar to help you with null-safety).
Haskell is a slightly different beast. I assume that with idiomatic Haskell, except for an occasional runtime error due to bad program logic, you'll rarely run into these issues.
The first three surely in the "nobody uses and don't see that changing anytime soon" category (haven't heard of the last one, special systems-programming C# edition?)
I agree that it's tragic how little alternative systems are known now. That said, linguistically, sub-structural languages (which can avoid GC) are quite different, regardless of intended usescases.
Please tell me that the referenced C# dialect used in Midori is available in some form for use, research or general learning? This would really make my week!!
You have Joe Duffy's blog entries about Midori and one entry back when it was still called M#.
Then there are the little pieces that came to C# from it.
Namely async/await, TPL, the MDIL compiler on Windows 8.x, the .NET Native compiler for UWP, the improved GC control in .NET 4.6 and the planned features for C# 7.1, 7.2 and 8.0 related to more mechanical sympathy.
Interesting. Looking forward to more comments on this.
* It looks like exceptions carry no error information. When something goes wrong, you know nothing. Is that right?
* Calling finalizers from GC is usually troublesome. They get called late, so they can't be relied to close files and such. They also have to be prevented from making trouble by doing things you can't do during GC, or "re-animating" the object being deleted. How's that handled?
* The notion that variable type is established at initialization is becoming mainstream. How about extending that to structures? The fields of structures could get their types inferred from the structure constructor. (There was a statically typed variant of Python, Shed Skin, which did this.)
> * It looks like exceptions carry no error information. When something goes wrong, you know nothing. Is that right?
Yes and no. You know something went wrong. `error` is supposed to only be used when it indicates a specific thing that went wrong. If you need error information, you should use a union type ala Rust.
There's been discussion on the Pony core team to change the name from "exception" has that carries a lot of expectations these days (folks generally expect that they will be akin to exceptions in Java et al)
pony: class Foo[A: Any val]
c#: public class MyGenericArray<T>
rust: fn foo<T>(T) { ... }
golang: none, because existing examples (outside of pony) too complicated
Which most obviously suggests a generic func? Geez, took us this long to just reach some clarity? Nice job, Pony.
> yes! I have devs with college degrees who don't understand operator precedence.
Bitwise operators in C-like languages have precedences that make no sense at all; I can't remember those either. (Even though they sort-of make sense if you consider their historical heritage... no excuses though.) But do you really see software developers with a university degree that mess up the precedence of times and plus? I shudder when thinking about them working with my code. I would really appreciate to be able to write e.g.
a + b == 0 || c * d - e > f / g
without a misunderstanding of precedence. Why is that not a basic feature in the first programming course one gets? It certainly was in mine, two years ago.
EDIT: is there any way to sanely embed an asterisk in normal text here?
I think the Rust example isn't quite fair, as the Pony and Java examples you give are for types, not functions. The Rust equivalent would be `struct Foo<T>`, which I think is as clear as the Pony example.
The web site promises a proof for type safety and links to a paper https://www.ponylang.org/media/papers/fast-cheap.pdf but the way I understand the paper it doesn't provide a proof. It contains a type system but no proofs of its properties. What am I missing here?
Glad to see this on HN. Just a couple weeks ago I stumbled onto Pony. Seems wonderful. Currently I am studying Erlang and Haskell with the hopes of combining the two. Pony seems to achieve a similar aim on it's own. I like that.
Pony actors are not really Erlang-like. In Erlang the scheduler is able to switch between processes at any point during execution (preemptive scheduler) and is also able to garbage collect unused memory in the process at any point during execution.
In Pony developers must write behaviours in a way that allows the scheduler to give CPU to other behaviours and to run GC periodically to collect unused memory. Otherwise other behaviours won't be able to run or will consume too much memory.
Erlang processes are also much smarter. They can be linked to each other to be notified when their linked counterparts die. This allows to create a well structured hierarchy of processes, each one with a different role to fulfil in the application.
A completely separate issue is their different approach to handling errors. Pony, similarly to Rust, tries to prevent the developer from crashing the application. Usually they do a decent job, but situation where the actor will need to crash or will never return are inevitable (see gotchas above, also imagine some dodgy code executed through FFI, etc).
Erlang takes a "let it crash" approach to managing those situations. Its BEAM (runtime, or VM in which the processes run) is the core that executes all processes. The core is not supposed to crash under normal circumstances but the processes are expected to crash as soon as they can't recover from an error.
Pony looks amazing. This is the first time I've heard of it, but I'm really excited to dive in. I'm only half way through the tutorial and there's already a lot to love. It feels like a cross between Python, Erlang, Rust and Haskell, with a dash of Go. The result is a surprisingly well thought-out language.
+1 rust needs more reference types and now I have more ammo to say why.
-2 alias types and especially ephemeral types. Anonymity should be no big deal (e.g. lambda is boring, closing over variables is interested). This seems like a monkey patch over not respecting that principle.
I'll keep on writing Rust and Haskell until I learn more about why I should love the actor model, but I hope this could someday kill Erlang and Elixer.
Good job for being much more interesting than your average new PL post.
This language looks wholely better and more unique (or at least once all the beam awesomeness is rewritten could be that), so those others retroactively become watered down versions that add nothing to the diversity of programming languages.
As far as I remember it is not only no pre-emption, but also no garbage collection inside a single actor method invocation. Which has some advantages but also the downside that longer-running and allocation-rich operations might need to be split up into multiple async actions.
That's a reasonable overview. There's work on pre-emption although not everyone thinks cooperative multitasking is a bad thing so pre-emption might be a choice you make on application startup.
You should not have been downvoted the way you have. Your statements are factual, just seems others think you meant there is no runtime or stdlib. But for runtime requirements, not carrying extra files or requiring extra installs is important, thanks for the info.
You really should do your homework better. Garbage collection says nothing about data races. Also, because of the compile-time memory safety inherent in the type system, they can build a much better garbage collector than whatever you are probably thinking of.
From the naive clueless knowledge of GC implementation algorithms, yes.
From the point of view of those that understand GC implementation algorithms, it is an actor local GC only executed at specific defined points, coupled with capabilities.
Rust use of affine types for memory management is great, but not all applications need such tight memory management, so it is a good productivity improvement to just be able to use a GC approach.
Shared immutable data is one option, but what I also mean is that when the type system can guarantee at compile time that the actor sending the data does not have read- or write- access to the data after sending, the system knows it can just "recycle" the old data, without run-time overhead.
Look, just read up on the type system, specifically reference capabilities[0]. It's basically what allows for safe mutability and data passing when required.
>Unless you mean that some data is shared, but cannot be modified, but this would be semantically identical to not sharing anything.
That's the gist of Rust's borrow checker. Shared data can't be modified (unless you use a Mutex or something similar, but then you need to acquire a lock, so data you can mutate is not shared).
> [...] this would be semantically identical to not sharing anything.
Erlang's data sharing (and no, not all binary data, just over a certain
threshold; if you want to nitpick, be diligent and precise) is
merely optimization trick, highly uninteresting when it comes to discussing
type systems (because its semantics are identical to not sharing anything at
all).
BTW, if you talk about Erlang, use proper Erlang's terminology. Erlang doesn't
have "actors", it has "processes".
We love when folks notice us, hopefully a couple people who read this end up in the Pony community. That said, the "better-than-Rust" makes me uncomfortable. Pony and Rust have different goals and make different tradeoffs with regard to memory safety. We don't think one is better than the other. They are different.
Anyway, back to my Sunday. Y'all enjoy.