Comment by dhagz | Hacker News Reader

Comment by dhagz | Hacker News Reader

This looks neat, but man. I'm not a fan of code generation magic. It's part of the reason I moved away from the Rails ecosystem - even though I knew what Rails was doing under the hood, the magic started to give me the heebie-jeebies. Maybe I'm weird, but I'd rather spend 10-15 minutes writing some boilerplate for a service and control the code than trust a third-party tool to do it for me.

I also feel like this is doing too much to be a framework, in a way. Like, if it just did the code generation, cool. But add in the secret management, cloud deployment and migration stuff, and it starts to feel like a platform - which, coincidentally, it is. With pricing and everything. I can't use this to build a service that runs on AWS/GCP/my own servers - at least it doesn't look like it from first glace.

So if this were actually just a framework that could be separated from the platform stuff, I'd be willing to try it out. But as is, I'd rather write boilerplate and be able to 'go run' my service and deploy it wherever I want.

EDIT: Just found that I could deploy to another cloud provider, which is nice. I wish I didn't have to manage that via a web interface, and that it supported just building a container I could deploy anywhere.

Thanks for the feedback. I think there are many different types of magic. In my (biased) opinion I think the code generation we do is much more on the side of "how to do this is obvious but annoying" rather than on the "I don't know what's happening" side.

As for platform vs framework, my realization is that the traditional separation of frameworks/libraries from infrastructure means that it's almost impossible to improve many parts of the developer experience.

The annoying parts of building backends and distributed systems come from the integration between the two. Setting up databases, secrets, and so on all require bridging that gap. Another big area that we're investing in is providing insights about how your application works at runtime, in production, directly at your fingertips when you're writing code. That's also not something you can do without integrating across that gap.

As you pointed out in the edit, you can absolutely use Encore with your own cloud. We're working on making the deployment options much more flexible, but it's very much not another "let's make an infrastructure tool and then charge a premium on top of your cloud bill to manage it for you".

Our business model is much more about aligning the incentives with the developers. We want to provide the best developer experience out there, and by charging for that as opposed to for infrastructure, we'll happily invest time to reduce our users' and customers' cloud bills, rather than just selling them more servers they don't really need.

I will say I do like the focus on telemetry and tracing - honestly that's the thing I have the hardest time setting up in applications, distributed or otherwise.

I agree regarding magic, but I've struggled to find the balance because if you have copy/pasted boilerplate, it's much harder to upgrade major versions because you have a lot of stuff to update/review. If you've modified the boilerplate, it may be impossible.

How do you balance that?

The language should have more features and less boiler plate. In Golang code, there is first class code generation support.

Compared to Ruby or Python, there is minimal code generation outside of the initial framework setups.

One thing I absolute hate about magic in code is that it's often done at runtime. Considering the idiomatic way for go is actually have code generated and checked into git makes a huge difference.

Reply on news.ycombinator.com