The guy behind the language - Sylvan Clebsch - seems to have a very solid background, and current professional situation. He works at "Microsoft Research Cambridge" in the Programming Language Principles group.

Read the "Early History of Pony":

https://www.ponylang.io/blog/2017/05/an-early-history-of-pon...

My point is - sure, it doesn't have a handful of massive companies stewarding it like Rust. But, on the other hand, it's made by a guy with really serious chops, who has a solid programming language related job. So while not being as industry-sanctified as Rust, or Java, it seems nonetheless like a language that could go places!

I loved playing with this a few years ago, but have lost track of it for a while.

The causality model was great, but is there a way to handle backpressure now?

I was randomly looking at examples and I think this is one showing that: https://github.com/ponylang/ponyc/blob/main/examples/under_p...

This is alas the chicken and egg scenario and the most common reason I hear for people not wanting to invest the time in pony.

The vast majority of people I discuss it with understand the value and the problems it is designed to solve, but they either don't have domain-problems that require pony's approach more than any other language - or the lack of supporting libraries makes them nervous over adoption.

As a pony developer for 5+ years, it can be frustrating - but I do understand.

Go is GC’d and that doesn’t stop it. What’s wrong with GC? Maybe for tiny tiny tiny embedded or constant time use cases that’s a deal breaker.

> constant time use cases that’s a deal breaker.

There are real-time safe GC algorithms. I don't know whether Pony offers that option. I would like to know.

I'm not sure I understand what you mean by "real-time safe GC algorithms", but pony is not a language that has being a "real time system" as a design goal.

This pony paper here describes the pony GC algorithms and compares their performance under various scenarios to other language GCs.

https://www.ponylang.io/media/papers/orca_gc_and_type_system...

The charts you want to look at are on pages 19-21.

It shows that ORCA (pony's GC) has extremely low jitter and is highly performant compared to the other industry leaders at the time of publication.

Real-time safe GC algorithms and data structures provide strong guarantees that any interruptions to the running program caused by GC activity will have a bounded duration, with strong guarantees on the upper bound of any pause. This is important in latency sensitive software and real-time software that needs to meet deadlines.

Examples include IBM's Metronome: https://www.researchgate.net/publication/220829995_The_Metro... and https://developer.ibm.com/articles/garbage-collection-tradeo...

Thanks for the ORCA link. I'll have to study it more closely but from Fig 17 it looks to have quite unpredictable jitter up to at least 20ms. Which is obviously fine for many things but not useful for other things (e.g. processing AVB streaming audio packets at line rate every 125 us).

EDIT: I originally also cited the following, however I am not sure these were the papers that I was thinking of: Baker's algorithm: https://dspace.mit.edu/bitstream/handle/1721.1/41976/AI_WP_1... also discussed here: "Baker's garbage collector performs garbage collection in real time-- the elementary object creation and access operations take time which is bounded by a constant, regardless of the size of the memory." https://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Real...

It's less than a third of the others which are compared.

As with all things, we should use the correct language / runtime for the domain problems it's designed to solve.

The pony runtime makes other decisions (such as non-preemptable schedulers) which would have more of an effect on your use-case methinks.

Thank you for the discussion and your interest!

Thank you for the pointers, much appreciated.

It's GC'd, because this is faster and secure.