Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Encore – Go framework for building distributed systems

github.com

Post reply on HN
Print view View original

51–60 of 71 posts

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

#51

Post by marcus_holmes »

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…

> it seems like unnecessary complexity, something I strive to avoid.

This. Adding complexity to reduce boilerplate seems like the wrong direction to go in (pun intended).

I like boilerplate. I can overwrite it with special cases whenever I need to, and it takes up very little mental space (as opposed to the rules needed to generate it).

I hated working in Rails because of all the magic. I love working in Go because of the lack of magic.

But y'know. I'm sure it'll suit someone. Good luck with it OP.

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

#52

Post by rusht »

ceesharp wrote: post #32

Is this something like https://dapr.io/ ?

I’d be interested in OP’s answer here as well.

I know dapr injects a sidecar so you can code in any language and then use their SDK to call other microservices. Encore looks to be Go centric and uses code generation to create actual Go functions, which provides much better IDE support.

I did not see this in the docs but I’m not sure if Encore supports retries with or without exponential backoffs; dapr supports both.

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

#53

Post by ggregoire »

hnarn wrote: post #33

I'm sure this is awesome but do we really need phrases like "state of the art developer experience" giving you "unmatched productivity"? Is this the new normal? Do people feel the need to add this type of crazy hyperbole to stand out? I'm sure most people who read this are technical enough to appreciate this framework for what it can achieve technically, there's no need for an open source framework presentation to us…

"a blazing fast library [rocket emoji] [fire emoji]"

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

#54

Post by mrath »

ashtar wrote: post #50
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…

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.

How does @Transactional span services? With a JtaTransaction manager?

If you are saying about micro services here which talk grpc/http then @Transactional does not help.

If you are talking about inside one service then you have write all that boilerplates, and it will not look as simple as Java

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

#55

Post by nvarsj »

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

Hi André. Encore looks really cool! It must have taken a huge amount of work to put this together. I think streamlining from IDE to production is the future of tooling and frameworks, and it looks like you are going in that direction. I feel like that is the entire hype behind "serverless", but no one has really been able to pull it off yet imo.

I wonder what you think about K8s integration? Spotify is all K8s right? I'm guessing that is tougher to monetize. I tried at a prior startup to work on something like this, offering a PaaS like experience on K8s with development libraries (it's actually still in progress - check out https://cloudstate.io/). It is a large effort to build such a thing in a nice way.

Anyways, I'm looking forward to seeing how Encore develops. Good luck!

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

#56

Post by MuffinFlavored »

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

> We grew frustrated with the disproportionally large effort needed to build even simple backend applications, and created Encore to solve this problem.

I'm going to sound naive but where did running Docker daemon on a VPS and orchestrating deployment with `docker-compose.yml` or `Terraform` fall short?

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

#57

Post by jpgvm »

I think the either the term distributed systems has been watered down or perhaps my definition was too strict vs what most people think it means.

To me something is only a distributed system if it infact has stateful (even ephemerally) components that interact with each other through some sort of distributed consensus or eventual consistency algorithm.

This on the other hand seems more like an application framework for traditional top-down scale out web applications where requests flow in from the top, through stateless application tier and into a stateful, centralised database.

Arguably it's "distributed" because it's made of multiple processes on multiple machines but it does really feel like a watering down of the term.

Things I would consider distributed systems: Zookeeper, etcd, Kafka, Druid, Hadoop, Bookkeeper, Pulsar, RabbitMQ, crypto stuff, bittorrent, Hazelcast, etc. Things that distribute work and storage across components and are aware of their peers.

Not to diminish the work here, just that I think the wording is a bit rich.

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

#58

Post by asimpletune »

jpgvm wrote: post #57

I think the either the term distributed systems has been watered down or perhaps my definition was too strict vs what most people think it means. To me something is only a distributed system if it infact has stateful (even ephemerally) components that interact with each other through some sort of distributed consensus or eventual consistency algorithm. This on the other hand seems more like an application framework f…

A distributed system doesn’t require consensus at all. Consensus is just a famous category of problems within the field of distributed systems, and there are many different types of consensus requirements.

I like Leslie lamport’s definition of a distributed system. I’m paraphrasing but it’s something to the effect, “a distributed system is when your program crashes because of a computer you never even heard of”.

So yeah, I mean a multi-tier web app can definitely be a distributed system.

Typically people don’t think of it like that because those systems are very centralized around a database for example, but in the most technical sense a multi tier application is still a distributed system.

So is an app consisting of composition of docker containers. Message passing in general can kind of blur the lines but yeah this too.

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

#59

Post by asimpletune »

ashtar wrote: post #50
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…

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.

I think the answers requires more context, but for example one well known pattern is called “sagas” for implementing long lived distributed transactions.

The gist is you timeout but provide a way for transactions to resume.

Also obviously there’s 2PC but again it depends on what unite trying to solve.

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

#60

Post by uh_uh »

AtNightWeCode wrote: post #47

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…

What are the more modern technologies you are referring to?
Post reply on HN