Show HN: Encore – Go framework for building distributed systems • Hacker News Board

Re: Show HN: Encore – Go framework for building distributed systems

#41

Post by itake » Wed, Apr 14, 2021, 6:25 PM UTC

freedomben wrote: post #12

dhagz wrote: post #9

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 d…

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.

Re: Show HN: Encore – Go framework for building distributed systems

#42

Post by Philip-J-Fry » Wed, Apr 14, 2021, 6:38 PM UTC

kbar13 wrote: post #38

Philip-J-Fry wrote: post #25

Earlier quoted context omitted.

I've built my fair share of Go microservices and have never felt the need to develop an entire framework like this. We have everything like CI/CD, distributed tracing and one line project generation. It's just based on some foundation code and some simple bash scripts to find and replace some service specific things. And then it's just the basic routing and HTTP handlers to unmarshal and marshal responses. When all y…

isnt code generation just smarter copypasta? since there will be no difference in complexity during runtime i feel like it's equivalent, just maybe more powerful what i mean is that you have complexity in your existing setup too... its just that you understand the ins and outs. and so the same applies to encore.

I don't think it is. It's fundamentally taking the code out of your control. With my services all the code is there, we can tweak it if necessary, we're not tied to a framework, it's just a barebones foundation of a Go application.

Nothing is hidden away from you with code generation. There's no in-between steps from what you write to what you execute other than Go compilation.

I think it's the wrong mentality to require a whole new set of third-party tools to maintain a Go application. It then starts feeling like you're writing Javascript, and does anyone really want that?

Re: Show HN: Encore – Go framework for building distributed systems

#43

Post by nautilus12 » Wed, Apr 14, 2021, 6:54 PM UTC

It's just rails built in go. Why do we keep doing the same thing over and over again but with our favorite language? It's as though we are just doing these things to be the first one there and build a new empire around ourselves. It's like digital colonialism...did we learn anything from the old world before forging ahead into a new one?

Re: Show HN: Encore – Go framework for building distributed systems

#44

Post by outworlder » Wed, Apr 14, 2021, 6:56 PM UTC

kbar13 wrote: post #38

Philip-J-Fry wrote: post #25

Earlier quoted context omitted.

I've built my fair share of Go microservices and have never felt the need to develop an entire framework like this. We have everything like CI/CD, distributed tracing and one line project generation. It's just based on some foundation code and some simple bash scripts to find and replace some service specific things. And then it's just the basic routing and HTTP handlers to unmarshal and marshal responses. When all y…

isnt code generation just smarter copypasta? since there will be no difference in complexity during runtime i feel like it's equivalent, just maybe more powerful what i mean is that you have complexity in your existing setup too... its just that you understand the ins and outs. and so the same applies to encore.

No it isn't.

If you did down enough, you'll find some form of code generation in your environment of choice. If nothing else, compilers, but it's not limited to them.

The largest difference between that and copypasta is - generated code can be easily updated, by regenerating it.

It's also an implementation detail. I've read elsewhere in this thread that code generation is bad and language supported features are good. I'm not sure it's so clear cut. It shouldn't matter if the generated code is mostly invisible (when it's baked inside your binary by the compiler, due to language support), versus code that is generated in the source language and then compiled.

One thing that's always bad is mixing generated and non-generated code. You have all the disadvantages and little benefit.

Re: Show HN: Encore – Go framework for building distributed systems

#45

Post by eandre » Wed, Apr 14, 2021, 7:01 PM UTC

nautilus12 wrote: post #43

It's just rails built in go. Why do we keep doing the same thing over and over again but with our favorite language? It's as though we are just doing these things to be the first one there and build a new empire around ourselves. It's like digital colonialism...did we learn anything from the old world before forging ahead into a new one?

It might be like rails in the sense of prioritizing the developer experience, but the goals are quite different. Rails is a web framework designed to build websites. Encore is a backend framework designed to build distributed systems. In practice that means the feature sets are extremely different, with very little overlap.

Re: Show HN: Encore – Go framework for building distributed systems

#46

Post by cultofmetatron » Wed, Apr 14, 2021, 7:03 PM UTC

Nice to see elixir get a but of competition in this space.

They are fighting an uphill battle to beat the OTP + lib-cluster + horde combo that elixir developers have but that autogenerated api stuff looks neat.

Re: Show HN: Encore – Go framework for building distributed systems

#47

Post by AtNightWeCode » Wed, Apr 14, 2021, 7:14 PM UTC

Platforms are typically garbage. This is garbage.

Love this quote by the way.

"With Encore you write your apps using Go, a modern programming language developed by Google to make backend development simpler. Rapidly growing and designed to be easy to learn, Go is the language of the cloud."

I think the irony of Go is that it is easier to "script" things in Go than in NodeJS for instance. This makes it the right tool for infrastructure programming. I always use Go for these kind of things.

Writing enterprise apps in Go is a bad idea with or without Encore. One lib can't simply make up for the large ecosystem in the more modern technologies.

Re: Show HN: Encore – Go framework for building distributed systems

#48

Post by wdb » Wed, Apr 14, 2021, 7:15 PM UTC

Philip-J-Fry wrote: post #35

skrtskrt wrote: post #31

Earlier quoted context omitted.

What is your setup for distributed tracing?

Elastic APM. As far as I am aware it's an implementation of the OpenTracing specification. We just use the Elastic client libraries. Tell it where our APM server is, do the little bit of application set up and then view all our application traces in Kibana. All applications follow the same basic setup. Probably less than 20 lines of code and then wrapping some HTTP handlers and HTTP clients. Then we have some applica…

Any plans to switch to Opentelemetry?

Re: Show HN: Encore – Go framework for building distributed systems

#49

Post by Philip-J-Fry » Wed, Apr 14, 2021, 7:34 PM UTC

wdb wrote: post #48

Philip-J-Fry wrote: post #35

Earlier quoted context omitted.

Elastic APM. As far as I am aware it's an implementation of the OpenTracing specification. We just use the Elastic client libraries. Tell it where our APM server is, do the little bit of application set up and then view all our application traces in Kibana. All applications follow the same basic setup. Probably less than 20 lines of code and then wrapping some HTTP handlers and HTTP clients. Then we have some applica…

Any plans to switch to Opentelemetry?

Not that I know of

Re: Show HN: Encore – Go framework for building distributed systems

#50

Post by ashtar » Wed, Apr 14, 2021, 7:37 PM UTC

Philip-J-Fry wrote: post #25

eandre wrote: post #2

I've been working on Encore for the past 3 years. I was at Spotify for the past 8 years as a Staff Software Engineer. We grew frustrated with the disproportionally large effort needed to build even simple backend applications, and created Encore to solve this problem. Encore uses static analysis and code generation to reduce the boilerplate you have to write, resulting in an extremely productive developer experience.…

I've built my fair share of Go microservices and have never felt the need to develop an entire framework like this. We have everything like CI/CD, distributed tracing and one line project generation. It's just based on some foundation code and some simple bash scripts to find and replace some service specific things. And then it's just the basic routing and HTTP handlers to unmarshal and marshal responses. When all y…

Curious - how do you end up handling transactions that span services?

I'm getting into go, but there doesn't seem to be a great pattern for this. Used to @Transactional on the service, so feels annoying in having to build that.