I was an early Golang dev and people were _crazy_ with channels for a couple years. I remember the most popular Golang Kafka client was absolute spaghetti of channels and routines.

It's never been "safe C" because it's garbage collected. Java is truly the comp because it's a great Grug language.

I also wrote some Erlang in the past, I really enjoy it and I was sad that Go didn't borrow more.

This is "share by communicating, don't communicate by sharing". Pretty much everyone agrees it's a good thought. ~Most programs get there just fine with channels, because ~most code isn't so performance sensitive that channel limitations matter. Go leaves plenty of room for the rest of programs to do something else. Seems good.

I remember very well one of the first public presentations about Go. It focused heavily on goroutines and channels and included a live demonstration of pushing an element through one million channels. It also included a demo of spinning up three racing queries to the Google search engine using the select statement, and picking whoever returned first. it was all about the new cool feature. They also had TCP-over-channels and eventually had to remove that because the model didn’t fit.

Nobody may have known they cared about Erlang, but those features sure made people pay attention.

Writing Elixir for a living is seemingly a growing trend.

> Nobody cared about Erlang back then and nobody does today. > > I write Erlang for a living.

I think this is incredibly correct and obviously personally true for you but I'd like to add one more thing from the peanut gallery.

No one really needs Erlang either. Turns out most problems are just fine not being modeled in the way that Erlang wants to model problems.

Just as a someone with a hammer could truthfully claim they don’t need a nail gun.

Not that I think Erlang manages to be a nail gun; it has enough idiosyncrasies that the comparison is not terribly accurate. Still, “need” is doing a lot of heavy lifting in that sentence.

> Not that I think Erlang manages to be a nail gun; it has enough idiosyncrasies that the comparison is not terribly accurate. Still, “need” is doing a lot of heavy lifting in that sentence.

Yeah it was a bit vague -- I should have said something more like "not many developers/teams/companies need telecom level uptime and resilience enforced at the single system level". In reality, most groups have solved this by redundancy and building multiple systems/distributing them. You could argue it's the wrong solution, but it's been good enough for so many people that... it's probably fine.

> nicer simpler Java

Ironically, Java was sold as a "nicer simpler C++".

Both can be true at the same time.