Except when you scale to zero, you get a 23+ second cold start time on .net apps. Google cloud run pulls some black magic to get ~3 second cold starts on .net apps, and ~500ms for golang/python/native apps.
Long term c# dev, who's used golang on a few projects. I really want to love go with an htmx+templ, amazing speed and gc, but find it sort of weird/quirky and just plain tedious in use.
Linq in c# is so nice, and lots of little c# features(maybe too many) in recent years has made it quite nice for daily use. With aot definitely prefer c# the language over golang. I do sort of loathe aspnet/mvc and especially blazor stuff. We desperately need a better web framework than asp but nothing will ever gain enough traction because of the ms dominance. Microsoft the sprawling corp never fails to disappoint, but damn the .net framework team does do some awesome work.
That said, I'm instead putting future efforts into python because let's be honest, uv/fastapi/fasthtml are more than fast enough for nearly every single project I've ever worked on.
Good points on code assistants effecting language/framework usage. Myself I've found that copilot will happily suggest usages that were deprecated 10 years ago and waste a couple hours of time.
Doesn't surprise me. Copilot often suggests nonexistent functions in libraries I've written, which code it's seen many times. Though it's occasionally useful, it probably doesn't save me any time overall. If work didn't pay for it, I certainly wouldn't use it.
It continues to exist and is in use. Lots of work has been done on a successor, but that is stalled while we consider what we want to do on various things.
Lago doesn’t store card data. You still use a Payment Processor like Stripe to process one-off payments. But the Subscription management and data related to subscriptions moves into Lago, in short you save on the fee you pay Stripe to manage subscriptions (Called Stripe Payments), it’s aprx 2% of the charge.
Who has subscriptions and when they are charged is now handled in your Lago code.
You can also then mix in other payment processors and regain control of your data.
Hey please be sure to design and at least mock out a way to host/run a collection of local LLM models in a generic manner. You could give the models access to context/content/history and to bubble up functionality within the browser. I can see tons of potential for something trusted and local which I'm comfortable giving full access to browsing history and not owned by big tech.
This could be key differentiator over other browsers.
I agree, though this does not seem like something that should be built until the browser is at least usable, which currently they're projecting an alpha release in 2026. By then things might be totally different, so don't architect yourself into a corner with it, but I also wouldn't invest much or any time into it right now. Focus on building good APIs/extension points though, and those will be immensely useful whether for local LLMs, extensions, or anything.
Yeah, wasn't thinking about actually building it out, just mocking it out and taking into consideration to allow for it as you build out browser. So much easier to plan for rails, rather than foist into something later on.
edit:
> Focus on building good APIs/extension points though, and those will be immensely useful whether for local LLMs.
I think we're saying the same thing, focus on good extension points for the local LLM use case.
My favorite type of discussion! Language choice would seem super important long, long term and could provide long run advantage over other engines. Given the goals and philosophy of Ladybird zig seems like a complementary choice, and headed in the same direction in terms of community and freedom. And Perhaps just a sprinkle of something more verifiable than zig on the edges where correctness and safety are super critical. Have a look into tigerbeatle (https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...) and their philosophy.
