[spooneybarger]

From the Pony side:

Biggest strength would be performance. Biggest weakness would be maturity. I think almost every pro/con I can think of can fall into those 2 buckets right now.

I'm a big fan of type systems so Pony having one is a big win for me.

The maleability of Pony and its immaturity helped us in some ways. We were able to treat it as a runtime for us to help mold and fit to our needs. That wouldn't have been possible with Erlang.

[59nadir]

> Biggest weakness would be maturity.

Has there been any progress towards a preemptive scheduler? Otherwise, I'd think that's the most obvious weakness.

[spooneybarger]

There's pros and cons to preemptive and cooperative scheduling policies. I wouldn't be comfortable labelling either as weakness. It really depends on context.

I've heard rumor of someone working on a preemptive scheduler. The current cooperative one is about to have runtime backpressure added to it which is going to be a really nice scheduling win.

https://github.com/ponylang/ponyc/pull/2264

[59nadir]

For the kinds of systems that are built with Erlang, which is a niche that Pony seems to want to occupy, I would argue it's inherently better to have preemptive scheduling. A cooperative scheduler will always be an open invitation for bugs relating to CPU hogging. Not having to worry about these things is priceless.

[model_m_warrior]

Are Ponys classes akin to Erlang modules or does it take a more enterprise-y perspective on OOP?

[scottlf]

Howdy. Erlang's modules are involved in code namespace for the compiler & runtime (i.e., the 'M' of the 'MFA' triple of Module + Function name + Arity that names a function) as well being the unit/scope/bound for hot code loading (i.e., you must load or unload an entire module at a time).

I've worked in Erlang-land far longer than I've lived in any OOP-land, so I'm not sure what you mean by enterprise'y OOP. Coincidentally, Pony's rules for "Packages" are something I just smacked my ignorant head against a few hours ago. The subsections of https://tutorial.ponylang.org/packages/ in the tutorial can probably answer at least some of your question: specifically "Package System" and "Use Statement".

[pdimitar]

I'll take the liberty to speculate and assume your parent comment was asking if Pony classes have the same features as Java classes -- namely class-level attributes, instance-level attributes, different access levels to attributes and methods. Those things.

So, does it?

[spooneybarger]

Pony classes have methods. Pony classes have fields.

Fields and methods can be public or private. Private is akin to Java's package private.

There are no instance variables.

[pdimitar]

Thank you. And structs / records? I mean, if there are no instance fields, there has to be some kind of constructs that emulate them.

[spooneybarger]

Sorry, I mispoke. There are no class fields. Only instance fields.

[aturley]

I'm not sure which features of Erlang modules you're interested in comparing to Pony classes, but I'll take a stab at trying to answer.

Pony classes are defined using a "class" keyword. Classes have properties and functions, where functions are like methods that you would find in a language like Java. Pony supports structural subtyping via interfaces and nominal subtyping via traits, and it disallows multiple inheritance.

I'm not sure how much that helps, but if you have more specific questions I'd be happy to try to answer them. I'm a little rusty on my Erlang, but hopefully it will come back to me.