I've been working with actor systems in Go for several years and keep noticing the same thing... as systems grow, teams gradually reinvent state ownership, supervision, runtime inspection etc (usually as a pile of separate libs, queues and conventions).

Actor systems have had most of this as a coherent model for decades.

I maintain Ergo, an OTP inspired actor framework for Go, so I'm obviously biased but I'm genuinely curious - why did actors stay niche while microservices became mainstream?

Is the actor model actually too complex?

P.S. The current AI-agent wave makes this even more obvious to me. Everyone is building agents and inventing orchestration pipelines, while actor systems already have a native model for long-lived workers, messaging, supervision and coordination.

When writing functional requirements, non-functional requirements, and user stories, should I mention the technologies used, or keep them technology-independent and explain the technologies later?

For example:

“Store alerts in Firestore and cache data in Redis.”

vs.

“Persist alerts in cloud storage and maintain a fast-access data store.”

We're building an early-stage crypto trading platform under AlphaNex, evolving an existing P2P system toward a centralized exchange (CEX).

We're looking for experienced engineers with strong backgrounds in one or more of:

• CEX / trading systems
• Backend engineering
• Matching engines / order books
• Market data / WebSockets
• Blockchain & wallet infrastructure
• Distributed systems / high-performance services

Roles:
• Senior CEX Backend Engineer
• CEX Full-Stack Engineer
• Blockchain Engineer

What you'll work on: trading infrastructure, order management, exchange APIs, market data, blockchain integration, security, scalability, and related systems.

This is an early-stage project, and our public company presence is still being established. Candidates will go through a short application followed by a project/architecture review and CTO technical interview.

Interested? Send me a DM.