The intended use case is rapid development of microservices. I’m excited about it because you can describe reliable and secure apps concisely:
https://github.com/Conder-Systems/tuna-lang/tree/main/demos/...
Tuna presents a single system image abstraction so developers don’t need to concern themselves with scalability.
It’s all open source and I welcome contributors/feedback!
Very interesting. In addition to micro-services, this could drastically ease the pain of developing workflow orchestration systems.
How do you plan to handle code updates in the context of global state?
With regards to orchestration, I hope to add primitives for events, batch processing, and things like that.
Make sure I understand your question correctly: You're asking how updates will work so: -old deployments don't see the next version's types coming out of global state -new deployments only see valid types.
I believe the compiler can do a lot of heavy lifting for updates while still remaining flexible. The compiler could take in two tuna files and type check across versions. For example, imagine two version of the same application. In v0 we store Foo. In v1 we store Bar.
A couple options open up: - We can deploy v1 but a transformation from Foo to Bar must be executed across all stored data. This would need to be performed while v0 is down. - We can deploy a type safe version of v0 and v1 that handle the union Foo or Bar. Then, we can teardown the type safe version of v0. v1 should be the only deployment that migrates foos to bars. The benefits of this approach is that you have non disruptive upgrades.