Polecat 4.0 shares many more internals with Marten and I’m hopeful that it’s also much better for F# developers as well.
Wolverine and more so Marten do already have F# users, but we just made the deployment story a lot better in both tools for F# developers. One of the key components of Wolverine especially has been our usage of runtime code generation and compilation using Roslyn, which is how Wolverine is able to adapt to your application code instead of forcing you to write adapters to our specific interfaces or abstractions like basically every other application framework in .NET.
That’s the special sauce in Wolverine that allows your application code to be far simpler than it would be with other application frameworks, but it comes at the cost of Roslyn being a beast for memory consumption (sometimes, but not always), the size of the binaries shipped, and cold start times (again, sometimes). We’ve long had the ability in both Marten and Wolverine to pre-generate the Wolverine or Marten adapter code ahead of time and let it be compiled into the application itself to side step the Roslyn runtime issues. But in a story I’m sure is aggravatingly familiar for F# folks, that was only useful for C# projects as we could only generate C# code (and Roslyn only compiles C# code at runtime as far as I know, but feel free to correct me on that one).
Marten 9.0 helped things for everybody by completely eliminating its usage of the Roslyn code compilation. Wolverine 6.0 improved F# usage (with follow ups including 6.3.0 today!) helped as well by supporting the pre-generation of all Wolverine adapter code in F# (message handlers, HTTP endpoint handlers, and gRPC endpoint handlers) with this:
dotnet run -- codegen write --language fsharp
Better yet, Wolverine 6.0 now let’s you use the Roslyn compiler business as strictly a development time only dependency and omit those binaries completely in production deployments. As long as you’re pre-generating the code as shown above (many people like to do that in Docker image initialization), you can deploy a lean, mean, even AOT compliant set of binaries while happily coding with F#!
Last Thoughts
I’m hopeful that these changes make Marten and Wolverine better for folks building and deploying systems with F#.
As we’ve been able to burn down so much of our backlog and other issues, I’ve had time to turn my attention to making our tools better for people who don’t code the exact same way I do. For example, we’ve invested a lot in the last year for the EF Core integration with Wolverine. Just this week we’ve made some progress toward making Wolverine better when folks insist on using more runtime IoC trickery that we would recommend. Along those lines, this post talks about how we hopefully got better for F# developers.
Just so I don’t have to have this conversation yet again, yes, we’re aware of Source Generators in .NET, and no, we don’t believe that it’s remotely possible to replace our usage of Roslyn in Wolverine with Source Generators without Wolverine becoming a much lesser tool because of how much runtime information we use to do the code generation. We have started using far more Source Generators in other elements of the Critter Stack though.
The Shade Tree Developer 