5 ms·

> Golang is basically just more concise Java. That is exactly how it was sold. A safe C, or a nicer simpler Java. Nobody cared about Erlang back then and nob

by fmbb 1y ago

> Golang is basically just more concise Java. That is exactly how it was sold. A safe C, or a nicer simpler Java. Nobody cared about Erlang back then and nobody does today. I write Erlang for a living.

gdbsjjdn 1y ago
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.
- tptacek 1y ago
  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.
nothrabannosir 1y ago
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.
nine_k 1y ago
Writing Elixir for a living is seemingly a growing trend.
hardwaresofton 1y ago
> 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.
- tacitusarc 1y ago
  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.
  - hardwaresofton 1y ago
    > 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.
pwdisswordfishz 1y ago
> nicer simpler Java Ironically, Java was sold as a "nicer simpler C++".
- testrun 1y ago
  Both can be true at the same time.

by fmbb 1y ago

gdbsjjdn 1y ago

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.

tptacek 1y ago
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.

nothrabannosir 1y ago

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.

nine_k 1y ago

Writing Elixir for a living is seemingly a growing trend.

hardwaresofton 1y ago

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

tacitusarc 1y ago
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.
- hardwaresofton 1y ago
  > 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.

pwdisswordfishz 1y ago

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

testrun 1y ago
Both can be true at the same time.