I'll answer the last bit first (I have no other developers to talk to at work, so excuse me for the wall of text): It's not exactly a traditional actor framewo

I'll answer the last bit first (I have no other developers to talk to at work, so excuse me for the wall of text): It's not exactly a traditional actor framework, so you might be a bit underwhelmed. It's single process (working on extending that, as we use P/Invoke, and a mistake there can completely crash the process; that said, hiding the details of distributed calls seems like a bad decision, so I'm still thinking about how to best approach this). Message passing is done through individual typed queues. Actors don't run when a message is received, but instead decide how often they should be run, and then poll for available messages from their queues (or just perform some timed action). Actors don't fail-fast so much as ensure proper logging and try again later (though parents may manually monitor and dispose their children). The biggest flaw I see is that message passing involves locking, and while I've tried to abstract this away with 'MessageQueue' and 'Atom' primitives, a user could easily circumvent this or pass mutable data. While I could easily catch and correct this if we bring a new developer on board, if someone were to start using the framework with no guidance, I worry they would not 'fall into the pit of success'. Designing a language around the actor model allows you to solve these issues: https://www.ponylang.io/discover/#what-is-pony https://www.ponylang.io/discover/#what-is-pony I've actually made the framework available as an open source library: https://github.com/caseymarquis/KC.Actin https://github.com/caseymarquis/KC.Actin I wouldn't say I'm proud of the framework's code. It could be better organized and more understandable (unfortunately, you can't use dependency injection when making the framework which does your dependency injection). What I am proud of is how simple and organized our main codebase is because of our use of the framework. A new developer can simply create a file containing a class, mark it with an attribute, specify its dependencies as private fields (also marked with attributes), and then create new functionality independent of what everyone else is doing. Effectively, fences are drawn between independent portions of the codebase in the style of 'micro-services', except there's no need for separating into separate services until a bottleneck is introduced (so there are no pointless debugging nightmares). I still have a lot of plans for building tooling around the framework: profiling, visualizations, monitoring, reporting to a centralized parent, inspection of running systems using reflection (remote inspection?), etc. I probably wouldn't recommend using it unless you're a brave soul. Maybe check in after a year or two and there will be something a bit more fleshed out. Having said all that, the actor model is a natural fit in our problem space. Our software talks to dozens of types of mission critical systems and physical equipment, each of which has the potential to fail outside of our control. I think the actor model would have been a perfect match for our software regardless of language. That said, .NET's excellent reflection and the ability to dynamically compile lambdas made it possible for the actor paradigm to feel native. I think that there's a lot of untapped potential in .NET surrounding this (making frameworks for one's domain). Regarding switching jobs: You're not wrong. There are other factors I didn't mention though. 10xing my pay would put me at the pay level of a mid-range FAANG employee. The main issue is that I would either have to move to get this kind of pay, or do a large amount of traveling (depending on the role I took). I do not live in a software hub (I live in an aerospace manufacturing hub), and so there aren't a lot of options in the area. Additionally, I feel loyalty to our team, and my leaving would have a major negative impact on them (they'd need 3 people they couldn't afford to replace me). I'm happy to have a good job in the area that I (mostly) enjoy, and to be innovating in a B2B space which allows me to make a lot of people happy. Five years from now I may feel differently (or we'll have substantially increased my pay). I get a lot of job offers, and they'll probably still be there in 5 years. At least one of the current owners wants to give me an ownership percentage, but I've told them to just keep increasing my pay as revenue increases instead. Most companies fail, typically from structural/organizational issues. I think ownership may be overrated. I could be wrong though. I think owning a piece of the company would feel more like the company owned me, and that I was stuck with it. Right now I feel like I'm choosing the company, and have the ability to easily leave if needed. Not 100% rational, but feeling good is important. I'd be much more likely to start a contracting business than found a company.