Lamar asks: Do I stay or do I go?

I happened to look into the Lamar issue list on GitHub late this afternoon at the end of a very long work day. What I saw was nothing to feel good about. A huge memory usage problem (probably related to Roslyn but I don’t know that for sure), a user who’s been very difficult in the past telling me he switched to another tool because it was easier to use and faster, bugs that unfortunately point to a huge flaw in Lamar’s basic premise, and folks really wanting a feature I’ve put off because it’s going to be a lot of work.

Lamar started its life as a subsystem of Jasper, the project that’s been my main side-project for the past couple years and my biggest ambition for several years before that. Jasper’s special sauce is the way that it uses Lamar to generate and compile code at runtime to glue together the runtime pipeline in the most efficient way possible. At the same time, it was killing me to support StructureMap and I wanted out of it, but didn’t want to leave a huge mess of folks with an abandoned project, so I turned Lamar into an IoC tool that was purposely meant to be a smooth transition for StructureMap users to an improved and more efficient IoC tool.

Right now, it’s becoming clear that the basic model of Lamar to use the runtime code generation isn’t working out. First because of what looks like some severe memory issues related to the runtime compilation, and second because it turns out that it’s very, very common for folks to use internal .Net types in IoC containers which pretty well defeats the entire code generation model. Lamar has workarounds for this to fall back to dynamic expressions for internal types, but it’s not optimized for that and Lamar’s performance degrades badly when folks use internal types.

As I see it, my choices with Lamar are to:

  • Retool it to use dynamic Expression compilation all the way down in the IoC engine usage like basically every other IoC tool including the older StructureMap library. That takes care of the performance issues most likely and knocks out the bugs due to internal types, but just sounds miserable.
  • Deal with the memory problems by trying to engage with the actual Roslyn team to figure out what’s going on and work around it. Which doesn’t solve the internal type issue.
  • Use pre-generated code build by Lamar during testing time baked into the real application for production deployments. There’s a bit more than a proof of concept already baked in, but this still doesn’t fix the internal problem

On the Jasper side I could:

  • Try to make it work with the built in IoC container but still try to do its “no IoC at runtime because it’s all codegen’d” model with a cutdown version of Lamar

Or, just call the whole thing off because while I would argue that Jasper shows a lot of promise technically and I still believe in its potential, it has zero adoption and I most likely won’t get to use it myself in any projects in the next year. If I give up on Jasper, I’m likely to do the same to Lamar. In that case, I’ll write off Lamar as a failed project concept, apologize profusely to all the folks that started to use it to replace StructureMap, and walk away.

Nobody needs to feel sorry for me here, so no need to try to cheer me up about any of this, but, I wouldn’t mind some feedback on whether it’s worth keeping Lamar around and what you think about the proposed improvements.


9 thoughts on “Lamar asks: Do I stay or do I go?

  1. After having had a day or two to think about this it’s still “I don’t know”. The right answer if Lamar is going to continue is to probably eliminate the runtime codegen and go back to Expressions compiled to Lambdas. At that point it’s mostly a matter of how ambitious I feel about all this and what works best for Jasper.

  2. Man, I hate to hear about the memory leak stuff, I was planning on using similar Roslyn techniques on some new projects I’m working on 😦

    1. We still don’t know what causes the problems. There are plenty of people using Lamar + MVC with no issues whatsoever. I’m really not sure what’s different about the applications where the memory usage goes haywire.

  3. Jeremy, thank you for all your hard word. You gave me both the aspire to do open source, and at the same time the downside of it. I’m surprised that you made it this far. As a heavy user of StructureMap, and still trying out Lamar, I’d be really sad to see them drop, but I guess you need sometime off these projects for a while.

    As software developers, we all like to do brand new things, and drop them half way to the goal, so you’ve already made great progress with all these projects. Hopefully we will see you with a new project some time, or maybe you’ll be happy with not being a public servant. You have that choice, and I believe others understand so.

  4. While I have moved away from C# and .NET I still read your blog and find your posts incredibly valuable.

    Kudos for your work on all the open source projects!

  5. I don’t use Lamar, so take this for what it’s worth.

    I love the fluent syntax, and I can’t wait for a project to try it out. It would be a shame if it went away.

    1. I don’t know that there’s anything special or unique about it per se, but many folks actually do like StructureMap’s API and Lamar was really just meant to be a clean path off of SM to something more modern and ASP.Net Core friendly

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s