I think this is fun stuff. I always enjoyed building things like this.
That said, in 2025 if I was already willing to utilize C#/.NET, I would probably prefer an "internal" DSL approach [0] - i.e., one that leverages the host language directly and builds the abstractions on top.
Examples of this would be fluent interfaces and methods like ConfigureDomainServices(Action<DomainServiceBuilder>). I know some developers frown on this approach, but I've embraced it as the least terrible way to go about handling things like AspNetCore web server configuration and setting up complicated data transformation pipelines. If these techniques are good enough for configuring a modern, production grade web server, they are probably good enough for configuring your domain too.
I spent a solid 3 years building & supporting an IronPython stack on the old 4.x .NET Framework and I learned a lot of lessons about how bad things can get when you begin coloring outside the lines. Memory leaks were probably the most difficult thing to reason about. Object lifecycles are already pretty tricky without the hosted language on top.
> I spent a solid 3 years building & supporting an IronPython stack on the old 4.x .NET Framework and I learned a lot of lessons about how bad things can get when you begin coloring outside the lines. Memory leaks were probably the most difficult thing to reason about. Object lifecycles are already pretty tricky without the hosted language on top.
I'm a little jealous ;) As someone who codes in both Python and C# mainly, never had to touch IronPython for an employer yet.
It's sad that IronPython is effectively dead, but PythonNet is now very stable, complete, and friendly to recent Pythons.
pythonnet works, we use it in a pretty large (Python) codebase, but I’m much more excited about https://github.com/tonybaloney/CSnakes, which allows using Python in a proper statically typed language - C#.
Thanks! I really appreciate you taking the time to write this up — super insightful.
I definitely get the appeal of internal DSLs, especially with how powerful C#’s fluent APIs have become. W++ takes a bit of a different path: more like “what if .NET had a native scripting layer that felt expressive and lightweight,” even if that means giving up some safety or flexibility of the host language.
And wow — 3 years with IronPython is no joke. Totally agree on how tricky it can get once you step outside the intended boundaries. I’m keeping W++ focused more on smaller, experimental scripting for now, but your point about memory and lifecycle management is a great reminder for anything that gets more ambitious.
Cheers for the link to Fowler’s DSL article too — gold.
> Memory leaks were probably the most difficult thing to reason about. Object lifecycles are already pretty tricky without the hosted language on top.
I thought the whole point of these high level langs was that you don't have to worry about that?
Totally fair question — most high-level languages do take care of memory for you, especially with garbage collection.
But in hosted scenarios like IronPython or W++ (where the language is layered on top of .NET), things can get trickier:
You're managing your own object model inside a host runtime.
If you're not careful, it's easy to create long-lived references (like global caches or circular structures) that the GC won’t clean up.
In IronPython's case, hosting decisions (like how objects interop with .NET classes) can leak unintentionally if lifecycle logic isn't airtight.
So yeah — you usually don't think about memory... unless you're writing the language
Are you saying that IronPython in general has memory leak issues? or just because you were trying to add support for an old .NET framework