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

61–70 of 71 posts

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

#61

Post by jpgvm »

asimpletune wrote: post #58
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 y…

I didn't say it requires consensus but rather that it's often present. Absence of it doesn't disqualify it because eventually consistent systems are definitely "distributed systems". I guess my quandary is between what I would consider embarrassing parallel scale out problems vs distributed systems that often do some sort of coordination even if that is loose coordination in the case of things like p2p protocols ala BTC, bittorrent, etc.

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

#62

Post by plank_time »

jpgvm wrote: post #61
asimpletune wrote: post #58

Earlier quoted context omitted.

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

I didn't say it requires consensus but rather that it's often present. Absence of it doesn't disqualify it because eventually consistent systems are definitely "distributed systems". I guess my quandary is between what I would consider embarrassing parallel scale out problems vs distributed systems that often do some sort of coordination even if that is loose coordination in the case of things like p2p protocols ala…

You actually did say it requires consensus or eventually consistency algorithm.

Your definition is too strict. Distributed systems are systems where the components of a system are distributed across a network. There are more issues than just consistency of data. You could have a system that doesn’t store data at all but still is considered distributed due to the nature of it being spread across a network.

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

#63

Post by valzam »

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…

I think one typical "distributed systems problem" that comes in even with a SOA of stateless services is transactions and eventual consistency. That being said I sorta agree that a distributed system without state is at least a much simplified version of "true" distributed systems.

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

#64

Post by valzam »

cultofmetatron wrote: post #46

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.

I don't think this is competition to Elixir/OTP. To me the USP of OTP is in-memory state shared across a cluster and scheduled dynamically, persisted through code updates. This is more like automation of the traditional stateless service - database combo.

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

#65

Post by valzam »

itake wrote: post #30

Any ideas how this compares with [go-kit]( https://github.com/go-kit/kit )? I like how go-kit's transport not just JSON and HTTP (e.g. gRPC and protobufs are supported).

If you look at the docs you can see that encore does much more than go-kit, like provisioning infrastructure, autoscaling etc. It seems like go-kit + kubernetes environment.

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

#66

Post by m00x »

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…

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

Well you're going to learn something new! Here's the short definition from Wikipedia:

Distributed computing is a field of computer science that studies distributed systems. A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system.

https://en.wikipedia.org/wiki/Distributed_computing

Any system that is distributed between multiple machines over a network and communicate with each other is a distributed system. The term is purposefully generic and not required to be constrained.

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

#67

Post by m00x »

valzam wrote: post #63
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…

I think one typical "distributed systems problem" that comes in even with a SOA of stateless services is transactions and eventual consistency. That being said I sorta agree that a distributed system without state is at least a much simplified version of "true" distributed systems.

There is no "true" distributed system. Any system that is distributed across multiple machines over network qualifies to be labeled as a distributed system.

I'm unsure where this protection of a term for more "complex" systems come from. It's a rather simple term that doesn't require to be needlessly reserved.

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

#68

Post by itake »

valzam wrote: post #65
itake wrote: post #30

Any ideas how this compares with [go-kit]( https://github.com/go-kit/kit )? I like how go-kit's transport not just JSON and HTTP (e.g. gRPC and protobufs are supported).

If you look at the docs you can see that encore does much more than go-kit, like provisioning infrastructure, autoscaling etc. It seems like go-kit + kubernetes environment.

They definitely aren't 1:1 comparison.

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

#69

Post by AtNightWeCode »

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…

Apologies to the Encore team. A bad comment. /A bitter coder
Post reply on HN