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

No more DSLs: Implement and deploy a distributed system with a single program

catern.com

Post reply on HN
Print view View original

1–10 of 17 posts

Re: No more DSLs: Implement and deploy a distributed system with a single program

#3

Post by yudlejoza »

whoisterencelee wrote: post #2

I am curious is there similarities to BOINC[1] ? [1] boinc.berkeley.edu

No similarities. The focus is different.

- BOINC looks like an interface for end-users to volunteer compute resources for various (existing) distributed-computing projects.

- Post is about building your own distributed system starting from minimal-yet-effective principles.

Re: No more DSLs: Implement and deploy a distributed system with a single program

#4

Post by spencer-p »

This article could use a disambiguation. Distributed systems are systems "whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another"[0].

This article appears to be focused on running many components on a single computer under the same process tree. Perhaps a better title would be "No more DSLs: Implement and deploy microservices as a monolith".

[0] https://en.wikipedia.org/wiki/Distributed_computing

Re: No more DSLs: Implement and deploy a distributed system with a single program

#6

Post by catern »

spencer-p wrote: post #4

This article could use a disambiguation. Distributed systems are systems "whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another"[0]. This article appears to be focused on running many components on a single computer under the same process tree. Perhaps a better title would be "No more DSLs: Implement and deploy microservices as…

No, this is distributed; see this line in the introduction:

>Functionality for distributed execution and monitoring is shared through libraries rather than by delegating to external orchestration systems, making a single-program system completely self-contained.

and this section in the examples: http://catern.com/caternetes.html#thread

Re: No more DSLs: Implement and deploy a distributed system with a single program

#7

Post by spencer-p »

catern wrote: post #6
spencer-p wrote: post #4

This article could use a disambiguation. Distributed systems are systems "whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another"[0]. This article appears to be focused on running many components on a single computer under the same process tree. Perhaps a better title would be "No more DSLs: Implement and deploy microservices as…

No, this is distributed; see this line in the introduction: >Functionality for distributed execution and monitoring is shared through libraries rather than by delegating to external orchestration systems, making a single-program system completely self-contained. and this section in the examples: http://catern.com/caternetes.html#thread

The quote you pulled out mentions "distributed execution" being completely contained in a "single-program system" - isn't a single-program system, by definition, not a distributed system?

With the emphasis on distributed systems, I was waiting to see how the approach would help synchronization, replication, network dependencies, etc. But all the examples show calling other services as functions or spawning new processes. At the end orderd starts listening for requests, but I don't see any example in the article where the example program talks to another computer in the system. Perhaps I am missing something?

Re: No more DSLs: Implement and deploy a distributed system with a single program

#9

Post by macintux »

It’s a confusing article, especially given the emphasis on DSLs in the title, which I assume is a reference to k8s but I’ve never dived into it so ¯\_(ツ)_/¯

Building a distributed architecture is so much more than what’s presented here: error handling, consistency management, data plane, control plane, name services… this feels like it’s taking 2% of what Erlang offers out of the box and calling it done.

Post reply on HN