[smallstepforman]

I evaluated Pony 4 years ago, and walked away due to 2 technical issues:

- garbage collection - no mechanism for synchronous access to actors

We ended up building a C++ actor model, with it's associated headaches. Yes, we still have race conditions and some developers invoke the function directly instead of using messages, and yes, sometimes we will grab a locking mechanism to do synchronous access, but at the end of the day, the performance of real code (embedded gaming system) is all that matters, and we did meet our performance goals.

Having said that, I've given up looking for an actor programming language and started building my own. Essentially, C++ like with Actors and compiler validated tracking of resources across actors (so the compiler knows about locks and actors). Still working on the compiler (compiles to C++20) and maybe 18 months away from public reveal. But the initial batch of test apps look very nice (but without compiler validation of resource sharing at this point in time). Very terse code, and implementing a compiler that outputs C++ was much easier than I originally feared. And no, there are no forward declarations or header files, compilers are run on modern workstations that have the grunt to produce the necessary scaffolding (from the project dependency script).

[staticassertion]

> - no mechanism for synchronous access to actors

That is presumably intentional, since if you could access actor state synchronously it wouldn't really be much of an actor. This sounds a lot like a "doing it wrong" kinda problem.

> (but without compiler validation of resource sharing at this point in time)

Not sure how you'll do this without garbage collection (like reference counting, which is what Pony uses iirc).

Honestly I suspect if you continue forward you'll probably walk away with much more appreciation for Pony's design decisions.

[devit]

Why not use Rust? It can do what you want.

[Karrot_Kream]

+1 actix.rs is pretty well-known and gives you the benefit of a full programming language if you need to do other things. Rust should be really easy to onboard to if your devs already know C++ and while the compiler is a lot slower, there's enough posts online about Actix that you shouldn't have issues searching around.

[smallstepforman]

With 21st century developer workstations having >= 8 cores, >= 2Ghz, >= 16Gb memory, it is ridiculous to have the scaffolding that Rust, Zig and other modern languages have. Source files dont live on their own and shouldn't be compiled as isolated units, they live in projects and need to be compiled as a batch. I'm stunned to see that so many developers are used to needing scaffolding, they just accept it as being necessary, but when you step back and think about it, it no longer makes any sense to require it. C and C++ get a pass here since they were designed in the 70/80's, but languages that have been designed from 2010 onwards must be ridiculed for targetting a PDP-11 era development machine where each compiler unit has limited access to resources. The end language I'm designing has smaller source files, however the compiler is a lot more complex since it auto generates the scaffolding (header files, forward declarations, etc).

It's still a fair bit away, I just got the proof of concept compiler which outputs C++ working (and the compiler is written in the language itself, so I'm dog fooding the project).

[gpm]

> Source files dont live on their own and shouldn't be compiled as isolated units, they live in projects and need to be compiled as a batch

Rusts compilation model is projects (called crates) that compile source files in batches.

But also, this feels like a minor implementation detail...

Maybe I'm missing your point?

[devit]

Not sure what "scaffolding" you are talking about.

Rust has no headers or forward declarations, and compiles the whole project ("crate") as a single unit.

[cortesoft]

What is the cost of having that scaffolding?

[funny_falcon]

afaik FoundationDB has something similar to "C++ with Actors".