Orleans is pretty cool! The project has matured nicely over the years (been something like 10 years?) and they have some research papers attached to it if you like reading up on the details. The nuget stats indicate a healthy amount of downloads too, more than one might expect.
One of the single most important things I've done in my career was going down the Actor Model -framework rabbit hole about 8 or 9 years ago, read a bunch of books on the topic, that contained a ton of hidden philosophy, amazing reasoning, conversations about real-time vs eventual consistency, Two-Generals-Problem - just a ton of enriching stuff, ways to think about data flows, the direction of the flow, immutability, event-logged systems and on and on. At the time CQS/CQRS was making heavy waves and everyone tried to implement DDD & Event-based (and/or service busses - tons of nasty queues...) and Actor Model (and F# for that matter) was such clean fresh breath of air from all the Enterprise complexity.
Would highly recommend going this path for anyone with time on their hands, its time well spent. I still call on that knowledge frequently even when doing OOP.
Not books, but some inspiring resources. FModel [0] is a set of patterns for functional reactive DDD on the basis of event sourcing. In particular the Decider pattern is a great way to model aggregates, and test them using Scenario's that read like Gherkin in code (given.. when.. then). Combines well with actors to represent aggregates.
On the BEAM used by Erlang, Elixir, and Gleam actors are called processes, and this guide [1] delves into domain modeling with them.
Applied Akka Patterns by Michael Nash, Wade Waldron (Oreilly) was very digestible and relevant at the time, might be dated by now. Just read the intro to get the vibe.
These days I would recommend picking a framework and then ask claude & friends to do a deep dive with you and build an example project out. Ask it to explain concepts, architecture, trade-offs, scalability considerations, hosting considerations, compare it with other frameworks, hook it up to storage systems (sqlite, postgresql, blob storage) and so on. Try running them within a wireguard network and so on. Very interesting learning to be found.
I was disappointed when MS discontinued Axum, which I found pleasant to use and thought the language based approach was nicer than a library based solution like Orleans.
The Axum language had `domain` types, which could contain one or more `agent` and some state. Agents could have multiple functions and could share domain state, but not access state in other domains directly. The programming model was passing messages between agents over a typed `channel` using directional infix operators, which could also be used to build process pipelines. The channels could contain `schema` types and a state-machine like protocol spec for message ordering.
It didn't have "classes", but Axum files could live in the same projects as regular C# files and call into them. The C# compiler that came with it was modified to introduce an `isolated` keyword for classes, which prevented them from accessing `static` fields, which was key to ensuring state didn't escape the domain.
The software and most of the information was scrubbed from MS own website, but you can find an archived copy of the manual[1]. I still have a copy of the software installer somewhere but I doubt it would work on any recent Windows.
Sadly this project was axed before MS had embraced open source. It would've been nice if they had released the source when the decided to discontinue working on it.
Someone needs to build Qt’s successor, probably with more beginner-friendly declarative semantics (akin to HCL or Cue) and probably with syntax closest to YAML or Python (based on learning curve, beginner readability etc).
The backend will probably have to be something written in Zig (likely) or Nim (capable, less likely) and will probably have to leverage OpenGL/Metal, WebGL and WASM.
Obviously a massive undertaking, which is why I think the industry has not reached consensus that this is what needs to happen. The less ideal options we have now often gets the job done.
There is Slint (https://slint.dev/), which was a company founded by ex-Qt devs and seem to be trying to make a better alternative to Qt. The core engine is built wiht Rust, but they also provide C++ and JS bindings and also have a QML-like scripting language you can use to design UI quickly. So far I think they've solidified their revenue model by catering to embedded devices, but I haven't seen a solid usecase for desktop apps (yet...)
They're making the initial version with C#, but they have plans to make the library language-agnostic. Rather than creating bindings, they'll write it in a subset of C# and then transpile it to C++/Jai/Zig/etc, so you can get the best language integration without the hassle of also wrangling with your build system.
>Rather than creating bindings, they'll write it in a subset of C# and then transpile it to C++/Jai/Zig/etc, so you can get the best language integration without the hassle of also wrangling with your build system.
This should be the top comment. The thing about growth of businesses overall, is that they want outsourced capacity (that’s what employees or contractors are) and that dynamic doesn’t go away because of AI, because like the comment mentioned, it’s not reliable enough in the sense that it can accept high-context vague instructions and ‘figure it out’ like an enterprise developer can.
No, they want "outsourced capacity" from contractors with domain specific expertise. Too many freelance/indie contractors on here scratching their heads as to why to can't land clients or jobs — you need domain expertise and experience, not just the ability to write code.
It's a code generator that runs during compile time. It's a source generator that adds some generated code files to the project. So it runs way before AOT or JIT. Once AOT/JIT run, Comptime is already invisible to them, they only see the generated code from Comptime.
Seems similar ideas, although SlateDB seems a bit more lightweight and using Parquet as primitive (even using Arrow) might mean more compute-heavy on client-side?
>SlateDB is designed for key/value (KV) online transaction processing (OLTP) workloads. It is optimized for lowish-latency, high-throughput writes. It is not optimized for analytical queries that scan large amounts of columnar data. For online analytical processing (OLAP) workloads, we recommend checking out Tonbo.
