5 ms·

This looks interesting. There are a few things I wonder about. From the first page of the tutorial (http://tutorial.ponylang.org/ http://tutorial.ponylang.org/

This looks interesting. There are a few things I wonder about. From the first page of the tutorial (http://tutorial.ponylang.org/ http://tutorial.ponylang.org/): > It's exception safe. There are no runtime exceptions. All exceptions have defined semantics, and they are always handled. This seems contradictory. Are there exceptions or not? EDIT. Apparently there are (http://tutorial.ponylang.org/expressions/exceptions/ http://tutorial.ponylang.org/expressions/exceptions/). But then I don't understand what the above means. > It's deadlock free. This one is easy, because Pony has no locks at all! This is nonsense. Deadlock happens when multiple processes/threads are waiting for each other. It is not caused by locks. From another tutorial page (http://tutorial.ponylang.org/types/static-vs-dynamic/ http://tutorial.ponylang.org/types/static-vs-dynamic/): > There's no such thing as null, so your program will never try to dereference null. But there is "None" (http://tutorial.ponylang.org/types/primitives/ http://tutorial.ponylang.org/types/primitives/). How is "None" so different from this "null" that we want to avoid? On the positive side: As I said this looks interesting. The type system appears to have been well thought out. Intersections look like a sane way to provide functionality that other PLs either implement poorly (perhaps via "multiple inheritance"), or simply disallow. And if the type system really does offer all the claimed guarantees, then it is a very good thing indeed. The partial applications, the concurrency model, and the handling of immutability are also clearly features that someone has given a lot of thought to. I cannot judge the results at this point, but I like well-thought-out things. :-) And the notion of "apply", along with the shortcut syntax, seems like it provides a standard, easy to understand way to make lot of code pretty simple. I hope to be able to look into this PL more closely in the near future.

steveklabnik 11y ago
> How is `None` so different from this "null" that we want to avoid? The difference is the defaults. Languages "with null" generally assume that any value can be null. Other languages, like Pony, do not allow any type to be null. Pony's "None" type is an example of a "unit type": a type with only one possible value. It's a totally different thing.
- betenoire 11y ago
  you may be safe from "dereferencing null", but you'll still have to check for those edge cases, whether it's called Null or None
  - steveklabnik 11y ago
    No, because random values cannot be None. The only thing that can be None is something with the type "None".
    - betenoire 11y ago
      I see many examples where they do exactly what I described, checking for "None" as a parameter value. Sure, it's explicitly named as a possible value, but you STILL have to make the check yourself. http://tutorial.ponylang.org/pattern-matching/match/#matching-on-type-and-value http://tutorial.ponylang.org/pattern-matching/match/#matchin... I see how it can be used in new and different ways, and is definitely safer, but it's not like the idea of "that thing you want isn't here" goes away by introducing a None type.
      - steveklabnik 11y ago
        I think I prefer the Option type to using a union with None here, for the reason that you state. I'm coming at this from a type theory / language design perspective: unit types are very different than nullable types, though if you write a union type with unit as one of the possibilities, well... EDIT: Sorry, I was thinking of sum vs product here, union types are sum types. So this is the same thing as Option. Sounds good. The advantage of using a union type is that you _have_ to check. This is significantly better than nulls.
        tonyg 11y ago
        They're both sums, but Pony (and e.g. Typed Racket) has unlabelled unions, while Haskell/ML have labelled unions. Pony's (X | None) is not like Haskell's Maybe X in that in Haskell, X could be unit, while in Pony that would collapse the type to just None. In other words, in Haskell, Maybe (Maybe X) makes sense; in Pony and Typed Racket, it doesn't.
sesquipedalian 11y ago
I found the statement regarding runtime exceptions confusing as well. Perhaps what is meant by that statement is that Pony lacks unchecked (i.e. Java) rather than runtime exceptions.
- ggchappell 11y ago
  Yes, that's probably it. Or to put it more simply: an exception will never crash a program.
weddpros 11y ago
>> It's deadlock free. This one is easy, because Pony has no locks at all! > This is nonsense. Deadlock happens when multiple processes/threads are waiting for each other. It is not caused by locks. Actually deadlocks happen when 2+ resources are not locked in the same order by 2+ processes/threads... As far as I know, in Pony there's no way to send a blocking message to another actor, so there's no lock, so there's no deadlock. Please correct me if I'm wrong
- ggchappell 11y ago
  I shall refer to a higher authority: > A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause. That is from Modern Operating Systems, 4th ed. (2015), by A.S. Tanenbaum & H. Bos, page 439. (By "process" they really mean "process or thread".) One way for thread A to wait on thread B is as you said: thread A can request a lock that thread B currently owns; then A waits for B. So requesting locks in opposite orders can result in deadlock. But of course if there are no locks, then no such waiting occurs, and so deadlock from this cause is impossible. But there are other ways to wait. If var_a and var_b are shared variables, then code like the following might result in deadlock (The following code is in C; to simplify things, I'm assuming that data races and memory-access ordering are not issues.) Thread A does: var_a = 1; while (var_b != 0) ; var_a = 0; And thread B does: var_b = 1; while (var_a != 0) ; var_b = 0; If Pony is capable of executing code like the above, then deadlock is possible.
  - betenoire 11y ago
    There are many ways code can grind and thrash to a halt, like your code shows. But a deadlock refers specifically to the idea of two processes waiting until the other is done before they proceed. It's a scheduling problem, and a lock is used for synchronization. If there are no locks (spinlocks, semaphores, etc), there are no deadlocks by name (just other problems).
    - ggchappell 11y ago
      > ... there are no deadlocks by name (just other problems). Okay, supposing we have a definition of deadlock that agrees with your usage: sure. But then these "other problems" you mention will have exactly the same practical effect as deadlock, right? A program will hang, sometimes unpredictably, based on more or less random decisions made by some low-level scheduling algorithm. And in that case, Pony's guarantee of no deadlock is (1) completely correct, and (2) completely meaningless, from the point of view of a programmer whose concern is that his code will behave as required. Am I wrong? EDIT. Maybe: https://news.ycombinator.com/item?id=10903876 https://news.ycombinator.com/item?id=10903876
6502nerdface 11y ago
> > It's exception safe. There are no runtime exceptions. All exceptions have defined semantics, and they are always handled. > This seems contradictory. Are there exceptions or not? EDIT. Apparently there are (http://tutorial.ponylang.org/expressions/exceptions/ http://tutorial.ponylang.org/expressions/exceptions/). But then I don't understand what the above means. I think the author is using a terminological Java-ism. In Java, a "runtime exception" (RuntimeException and subclasses) is an exception that doesn't have to be handled, and therefore may be thrown unhandled at runtime. Pony has exceptions, but no unhandled exceptions, i.e. no "runtime exceptions" in Java speak.
- ggchappell 11y ago
  Yes, that's probably what is meant. So the point is that a program will never crash due to an exception.

steveklabnik 11y ago

> How is `None` so different from this "null" that we want to avoid? The difference is the defaults. Languages "with null" generally assume that any value can be null. Other languages, like Pony, do not allow any type to be null. Pony's "None" type is an example of a "unit type": a type with only one possible value. It's a totally different thing.

betenoire 11y ago
you may be safe from "dereferencing null", but you'll still have to check for those edge cases, whether it's called Null or None
- steveklabnik 11y ago
  No, because random values cannot be None. The only thing that can be None is something with the type "None".
  - betenoire 11y ago
    I see many examples where they do exactly what I described, checking for "None" as a parameter value. Sure, it's explicitly named as a possible value, but you STILL have to make the check yourself. http://tutorial.ponylang.org/pattern-matching/match/#matching-on-type-and-value http://tutorial.ponylang.org/pattern-matching/match/#matchin... I see how it can be used in new and different ways, and is definitely safer, but it's not like the idea of "that thing you want isn't here" goes away by introducing a None type.
    - steveklabnik 11y ago
      I think I prefer the Option type to using a union with None here, for the reason that you state. I'm coming at this from a type theory / language design perspective: unit types are very different than nullable types, though if you write a union type with unit as one of the possibilities, well... EDIT: Sorry, I was thinking of sum vs product here, union types are sum types. So this is the same thing as Option. Sounds good. The advantage of using a union type is that you _have_ to check. This is significantly better than nulls.
      - tonyg 11y ago
        They're both sums, but Pony (and e.g. Typed Racket) has unlabelled unions, while Haskell/ML have labelled unions. Pony's (X | None) is not like Haskell's Maybe X in that in Haskell, X could be unit, while in Pony that would collapse the type to just None. In other words, in Haskell, Maybe (Maybe X) makes sense; in Pony and Typed Racket, it doesn't.

sesquipedalian 11y ago

I found the statement regarding runtime exceptions confusing as well. Perhaps what is meant by that statement is that Pony lacks unchecked (i.e. Java) rather than runtime exceptions.

ggchappell 11y ago
Yes, that's probably it. Or to put it more simply: an exception will never crash a program.

weddpros 11y ago

>> It's deadlock free. This one is easy, because Pony has no locks at all! > This is nonsense. Deadlock happens when multiple processes/threads are waiting for each other. It is not caused by locks. Actually deadlocks happen when 2+ resources are not locked in the same order by 2+ processes/threads... As far as I know, in Pony there's no way to send a blocking message to another actor, so there's no lock, so there's no deadlock. Please correct me if I'm wrong

ggchappell 11y ago
I shall refer to a higher authority: > A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause. That is from Modern Operating Systems, 4th ed. (2015), by A.S. Tanenbaum & H. Bos, page 439. (By "process" they really mean "process or thread".) One way for thread A to wait on thread B is as you said: thread A can request a lock that thread B currently owns; then A waits for B. So requesting locks in opposite orders can result in deadlock. But of course if there are no locks, then no such waiting occurs, and so deadlock from this cause is impossible. But there are other ways to wait. If var_a and var_b are shared variables, then code like the following might result in deadlock (The following code is in C; to simplify things, I'm assuming that data races and memory-access ordering are not issues.) Thread A does: var_a = 1; while (var_b != 0) ; var_a = 0; And thread B does: var_b = 1; while (var_a != 0) ; var_b = 0; If Pony is capable of executing code like the above, then deadlock is possible.
- betenoire 11y ago
  There are many ways code can grind and thrash to a halt, like your code shows. But a deadlock refers specifically to the idea of two processes waiting until the other is done before they proceed. It's a scheduling problem, and a lock is used for synchronization. If there are no locks (spinlocks, semaphores, etc), there are no deadlocks by name (just other problems).
  - ggchappell 11y ago
    > ... there are no deadlocks by name (just other problems). Okay, supposing we have a definition of deadlock that agrees with your usage: sure. But then these "other problems" you mention will have exactly the same practical effect as deadlock, right? A program will hang, sometimes unpredictably, based on more or less random decisions made by some low-level scheduling algorithm. And in that case, Pony's guarantee of no deadlock is (1) completely correct, and (2) completely meaningless, from the point of view of a programmer whose concern is that his code will behave as required. Am I wrong? EDIT. Maybe: https://news.ycombinator.com/item?id=10903876 https://news.ycombinator.com/item?id=10903876

6502nerdface 11y ago

> > It's exception safe. There are no runtime exceptions. All exceptions have defined semantics, and they are always handled. > This seems contradictory. Are there exceptions or not? EDIT. Apparently there are (http://tutorial.ponylang.org/expressions/exceptions/ http://tutorial.ponylang.org/expressions/exceptions/). But then I don't understand what the above means. I think the author is using a terminological Java-ism. In Java, a "runtime exception" (RuntimeException and subclasses) is an exception that doesn't have to be handled, and therefore may be thrown unhandled at runtime. Pony has exceptions, but no unhandled exceptions, i.e. no "runtime exceptions" in Java speak.

ggchappell 11y ago
Yes, that's probably what is meant. So the point is that a program will never crash due to an exception.