No change from when Go was released AFAIK: Go has no reliability/failover story (whether locally or in terms of distribution), uncaught panics will bring down the entire system, and the runtime has no support for routine hierarchies.

So I guess you'd choose Go if you want to build a local service — especially if it has some amount of concurrency (e.g. network daemons) — or CLI tools (fast startup). You'd use erlang if you want to build a system which really should not die, especially if it so should not die that you're willing to spread it over multiple physical machines.

Not an expert, nor to take anything from Erlang (was amazed at how robust RabbitMQ was first time I stress tested it) but fault tolerance seems to be a part of OTP. To me, k8s ~ OTP, GO ~ Erlang, and Erlang syntax is a bit easier than GoLang, but might just be the way I was brought up.

OTP is the standard distribution & library of Erlang, and most of the fault tolerance is either that or the core Erlang runtime e.g. supervisors are part of the standard library[0] and the underlying systems are basically built into the language[1].

Distribution is likewise built into the runtime and language, most of the distribution-related BIFs are not only part of the "erlang" module/namespace but also part of its "prelude" (auto-imported in all modules by default).

So no, it is absolutely nothing like kubernetes in relation to go.

[0] http://erlang.org/doc/man/supervisor.html

[1] http://erlang.org/doc/reference_manual/processes.html#id8861...

I think parent was referring to similarity of k8s to OTP from user's prospective..

People just want k8s to be that marvelous, to have strong supervision tree architecture. I want the same for systemd too. But sadly it's all mess.

> [...] but fault tolerance seems to be a part of OTP.

Yes, mostly, but the thing is that OTP was possible at all because of how the portions provided by the language and the runtime play together. You cannot replicate the OTP as it is in Go because Go's runtime is lacking and its communication model doesn't match.

Once you learn Erlang and OTP, you will start seeing everything as a poor re-implementation of the same concepts.

The syntax you're looking for is k8S:Go::Erlang:OTP

Not sure where I would choose Go, but Elixir + Rust is an extremely capable combo for BEAM (Erlang VM) projects.

Do you have some recommended reading on why and how to combine Elixir and Rust?

Try this: http://hansihe.com/2017/02/05/rustler-safe-erlang-elixir-nif...

Previous discussion https://news.ycombinator.com/item?id=13497505

Thanks. Did a search before asking but couldn't find anything. Sorry to rehash!

Easy enough to miss. That one is Elixir and Go but for most purposes Elixir/Erlang/BEAM are fairly interchangeable.

No. Thank You. Go vs Erlang/Elixir back n' forths are the reason I read HN comments!

I believe GoLang supports efficient sharing of large data-structures between cores of the same processor, whereas ErlangLang does not.

> I believe GoLang supports efficient sharing of large data-structures between cores of the same processor, whereas ErlangLang does not.

AKA Go does shared-memory multitasking, while Erlang does shared-nothing multitasking.

Yes, and when used in an immutable way, the GoLang approach is very powerful and efficient, because it allows one to pass large (parts of) immutable data-structures without copying.

How do I declare an immutable data structure in Go?

An unexported value type provided through an interface is immutable. The "context" object uses this. But it isn't really a solution for immutable value programming.

Its immutable everywhere, or just outside the package that declares it?

Outside the package that declares it, though if you have it as an interface value you'd have to do work to penetrate it.

Since it's not like I'm trying to sell this as a solution to all immutable data requirements, I didn't worry too much about that detail. In the end it's all about effort, anyhow; with the right invocations in Haskell I can mutate "immutable" data just fine. So even an interface in the package that declared it is still nontrivial protection against accidentally mutating it.

I don't think thats really true about Haskell, unless you are talking about C code you've invoked through FFI in which case all bets are off in every language.

Isn't it a lot simpler to just say that Go has no feature support for immutable data? The fact that you can hide accessors in a package is small comfort if I have to read all the source code in that package to know the actual semantics.

What about lists? Eg, an immutable list of packets.

AFAIAA, the only immutable core type in go is string.

"ErlangLang"?

While 'ErlangLang' is obviously wrong, I should point out that the '-lang' part of 'Erlang' is not related to the root word 'language'. Perhaps the name 'Erlang' was chosen because it already ended in '-lang', perhaps not, I don't know. But it was quite likely named after the Danish mathematician Agner Krarup Erlang.

IIRC "ERicsson LANGuage" because it was created for networking stuff at Ericsson.

EDIT: Yep, we're actually both right! From the Wikipedia page:

> The name "Erlang", attributed to Bjarne Däcker, has been presumed by those working on the telephony switches (for whom the language was designed) to be a reference to Danish mathematician and engineer Agner Krarup Erlang as well as a syllabic abbreviation of "Ericsson Language".

Erlang is slower, and beam is not relevant anymore with kubernetes and the like which are much more powerful and language neutral.

I keep hearing stuff like that but it’s not even close to accurate.

BEAM and Erlang give you tooling that you can’t get from any other language, regardless of how it’s deployed. Using Kubernetes doesn’t make up for any of that...it just gives you a way to deploy containers.

What tooling please give an example.

The machinery of the BEAM is in-process (and between nodes when you need it). Kubernetes and the BEAM VM address different levels of the architecture.

Apples to oranges.

For a detailed example, just see the previous posted. There’s a lot.

https://news.ycombinator.com/item?id=13497505

I dont know whether this is a good thing or not.... The best nuggets of information on HN are at the mercy of a good soul digging up the link and dropping it on a new thread.

You'd think that this knowledge retrieval/storage problem could have a more elegant solution built by the HN folks. Example solution: Topic X stored in category, ranked to the top, its next 'commit' or successor is chained on kind of like how unroll works with twitter.. but with long HN threads instead. Think a 'git tree' of knowledge descending down, with merges too maybe...

Engh.. maybe thats part of the charm of HN... the old school style message board.

strictly ordered message queues between processes