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

Distributed Systems Classics (2017)

nvartolomei.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Distributed Systems Classics (2017)

#31

Post by throwaway894345 »

toast0 wrote: post #22
bigcat12345678 wrote: post #16

I am a Lamport admirer. I gradually realized that Lamport is more of the godfather of distributed system than Hinton is to deep learning. Lamport is less prominent than Shannon is to information theory. Shannon is the closest to any title of "gold-like" figure to a scientific discipline of universal relevance in modern society. Lamport specifically revealed a philosophical connections between computer systems and phy…

> the relations between events happening in a distributed system, is more fundamental than their absolute ordering The important thing in most distributed systems is having an order. Having a single observer serialize events as it receives them is so much more tractable than trying to use absolute order. Using absolute order requires very precise time synchronization which is hard; using absolute order requires knowi…

> absolute order requires very precise time synchronization which is hard

Presumably relativity is the reason precise time synchronization (and thus absolute ordering) is hard.

Re: Distributed Systems Classics (2017)

#32

Post by Joel_Mckay »

nesarkvechnep wrote: post #2

As always, lists like these don’t include Joe Armstrong's PhD thesis “Making reliable distributed systems in the presence of software errors” - http://erlang.org/download/armstrong_thesis_2003.pdf

reliable? we all wish...

In distributed systems the fist lesson is resilience is more important.

Spend enough time in a computer lab, and you will see things halt and catch fire on occasion. Especially if it has a bunch of GPUs pinning the utilization 24/7, or a cheap power supply in the cluster. =3

Re: Distributed Systems Classics (2017)

#33

Post by Joel_Mckay »

brcmthrowaway wrote: post #10
nesarkvechnep wrote: post #2

As always, lists like these don’t include Joe Armstrong's PhD thesis “Making reliable distributed systems in the presence of software errors” - http://erlang.org/download/armstrong_thesis_2003.pdf

Does anyone use Elixir/Erlang anymore?

Yes, but it is boring telecom projects... so most people aren't interested.

Scala is kind of a more modern alternative.

If doing a twitter like platform, elixir with Phoenix channels could handle around >20k users per host. Very few other options work for that use case. =3

Re: Distributed Systems Classics (2017)

#34

Post by Joel_Mckay »

brcmthrowaway wrote: post #15
appstorelottery wrote: post #12

Earlier quoted context omitted.

WhatsApp backend in Erlang + used in telecoms

The "WhatsApp used Erlang" story was a decade ago, doubt it is true now.

I doubt they changed out Erlang/Elixir, as it is mature backbone infrastructure. It has run many telecoms for over 30 years without issue.

The problem is finding talent that knows both distributed systems, and Erlang/Elixir. But Erlang/OTP can replace a lot of expensive kludges. =3

Re: Distributed Systems Classics (2017)

#35

Post by convolvatron »

toast0 wrote: post #22
bigcat12345678 wrote: post #16

I am a Lamport admirer. I gradually realized that Lamport is more of the godfather of distributed system than Hinton is to deep learning. Lamport is less prominent than Shannon is to information theory. Shannon is the closest to any title of "gold-like" figure to a scientific discipline of universal relevance in modern society. Lamport specifically revealed a philosophical connections between computer systems and phy…

> the relations between events happening in a distributed system, is more fundamental than their absolute ordering The important thing in most distributed systems is having an order. Having a single observer serialize events as it receives them is so much more tractable than trying to use absolute order. Using absolute order requires very precise time synchronization which is hard; using absolute order requires knowi…

yes, it can be easier to have a central serializer for events, but that certainly makes things problematic for fault tolerance and basically excludes large-scale solutions. using an agreed-upon post-hoc ordering based on timestamps is certainly another way, but really only if you're working in a paradigm that lets you impose it (like mvcc) or doesn't care (like crdt).

personally I find when you view events in a distributed system as a partial order, its more liberating than confusing. its not unusual to assume that there is some kind of canonical event ordering that we have to preserve, when its often just not semantically important. so its a useless constraint that can impose complexity and limit the solution space. the partial ordering exposes the real causal constraints.

Re: Distributed Systems Classics (2017)

#36

Post by throwaway-17732 »

moritz wrote: post #30
olooney wrote: post #24

Earlier quoted context omitted.

Hot take of the day: Computer scientists are in denial about it, but CS is a branch of theoretical physics, not mathematics. You can point to this or that model of computation, such as lambda calculus or mu-recursive functions and try to claim its abstracted well beyond the particular laws of physics for some specific universe, but they all have some kind of rate limit built into them... and where does the motivation…

Related hot take Maybe thats why one of the not-so-bad ideas how to go about distributed systems came from a guy who was trained as a physicist and used to complain to his fellow programmers that “a lot of systems actually break the laws of physics”[1]? > In distributed systems there is no real shared state (imagine one machine in the USA another in Sweden) where is the shared state? In the middle of the Atlantic? -…

And yet we have CRDTs.

Re: Distributed Systems Classics (2017)

#37

Post by Jtsummers »

Joel_Mckay wrote: post #34
brcmthrowaway wrote: post #15

Earlier quoted context omitted.

The "WhatsApp used Erlang" story was a decade ago, doubt it is true now.

I doubt they changed out Erlang/Elixir, as it is mature backbone infrastructure. It has run many telecoms for over 30 years without issue. The problem is finding talent that knows both distributed systems, and Erlang/Elixir. But Erlang/OTP can replace a lot of expensive kludges. =3

> But Erlang/OTP can replace a lot of expensive kludges.

If you can convince your employer of that. I'm working on a system today (and not for the first time) that could have significantly reduced complexity by switching to Erlang (or Elixir) and OTP. Amusingly, it's a glorified, in-house telecom system that was developed because they chose not to buy an existing solution.

Re: Distributed Systems Classics (2017)

#38

Post by Joel_Mckay »

Jtsummers wrote: post #37
Joel_Mckay wrote: post #34

Earlier quoted context omitted.

I doubt they changed out Erlang/Elixir, as it is mature backbone infrastructure. It has run many telecoms for over 30 years without issue. The problem is finding talent that knows both distributed systems, and Erlang/Elixir. But Erlang/OTP can replace a lot of expensive kludges. =3

> But Erlang/OTP can replace a lot of expensive kludges. If you can convince your employer of that. I'm working on a system today (and not for the first time) that could have significantly reduced complexity by switching to Erlang (or Elixir) and OTP. Amusingly, it's a glorified, in-house telecom system that was developed because they chose not to buy an existing solution.

Ah, I just recommended simple AMQP (packed BSON Notably, it is possible to rebuild or move the entire infrastructure by issuing a signed resend-logs-to-new-consumer request to clients or servers.

If you start with a dumpster fire at a dried fish factory, than 3 week solutions that last 6+ years under load look pretty nice in retrospect. Your boss is probably contemplating why most Erlang/Elixir people don't work for clown wages. =3

Re: Distributed Systems Classics (2017)

#39

Post by toast0 »

Jtsummers wrote: post #37
Joel_Mckay wrote: post #34

Earlier quoted context omitted.

I doubt they changed out Erlang/Elixir, as it is mature backbone infrastructure. It has run many telecoms for over 30 years without issue. The problem is finding talent that knows both distributed systems, and Erlang/Elixir. But Erlang/OTP can replace a lot of expensive kludges. =3

> But Erlang/OTP can replace a lot of expensive kludges. If you can convince your employer of that. I'm working on a system today (and not for the first time) that could have significantly reduced complexity by switching to Erlang (or Elixir) and OTP. Amusingly, it's a glorified, in-house telecom system that was developed because they chose not to buy an existing solution.

>> But Erlang/OTP can replace a lot of expensive kludges.

> If you can convince your employer of that.

It's probably easier to find an employer that's already convinced. But that's not easy either. :P I'm working in Rust now, because that's what the employer wants to do and it works enough. Half of my work problems would evaporate if we switched to BEAM, but I'd still have the other half and new ones and I'm not sure the rest of the team would be as excited as I am. And they almost certainly wouldn't let me hot load code, which means less fun and less fast iteration :(

Convincing an employer to switch languages is generally hard, regardless of which language, but switching to a system built on BEAM is probably a bigger change than most.

Re: Distributed Systems Classics (2017)

#40

Post by ksambhi »

mjb wrote: post #13

This is not a bad list for sure. Here are some deeper cuts for those looking for something a bit less mainstream: "The Maintenance of Duplicate Databases" https://datatracker.ietf.org/doc/html/rfc677 (AFAIK the genesis of the use of logical clocks in distributed systems). "Chain Replication for Supporting High Throughput and Availability" https://www.usenix.org/legacy/event/osdi04/tech/full_papers/... (Chain replicat…

Question from a recent CS grad here, who just learnt about CAP: what do you mean by “very poor trade-off thinking in the decade that followed”?
Post reply on HN