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

Go hits the concurrency nail on the head

eli.thegreenplace.net

Post reply on HN
Print view View original

251–260 of 318 posts

Re: Go hits the concurrency nail on the head

#251

Post by [deleted] »

fulafel wrote: post #84
weberc2 wrote: post #77

Earlier quoted context omitted.

> full force of Google pushing it This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!". There is a small team at Google that work on the language along with the open source community. I'm pretty sure none of Google's marketing team works to promote the language, and I'm sure that its success is much less important to Google than Erlang's success was to Ericcs…

Ericsson abandoned Erlang, or Erlang abandoned Ericsson, depending on how you look: Ericsson banned it internally, and shortly afterwards when the Erlang team managed to get it open sourced, they resigned from Ericsson and founded their own Erlang company. (source: http://webcem01.cem.itesm.mx:8005/erlang/cd/downloads/hopl_e... )

[deleted]

Re: Go hits the concurrency nail on the head

#252

Post by JeremyBanks »

lostmsu wrote: post #247
pdeuchler wrote: post #193

Earlier quoted context omitted.

This is correct, but they quickly pivoted to targeting the Python codebases. Rob Pike has a talk where he talks about how Google used C++ and C to rewrite hot Python paths and how they wanted Go to be able to completely replace that whole pattern. Russ also has a blog post (maybe? it also could have been a comment in a github issue, tbh I can't remember) where he mentions converting python programmers was orders of m…

Well, why did not they just use C#? It already had most, maybe even all of Go's current features. Hell, the main thing of Go, the go op is basically await.

C# would be a good option today, but at the time it was an expensive proprietary closed-source blob maintained by one of their primary competitors, and async/await was still years away. I don't like Go very much, but it was a reasonable choice for Google.

Re: Go hits the concurrency nail on the head

#253

Post by Const-me »

kasey_junk wrote: post #234
Const-me wrote: post #227

Earlier quoted context omitted.

> actors, futures/promises and async/await style co-routines which are all extremely available in all of the major languages Language features are indeed available. Runtime features backing them are only available in Go, erlang and .NET. If you only need concurrency for CPU bound calculations, even C++ has decent options, e.g. OpenMP works great for my tasks. However, OpenMP offers nothing for IO. The point of go’s c…

Green thread schedulers are available (and I’ve had direct experience with them) in the JVM & C++ as well.

Scheduling is not enough. For efficient IO you need a scheduler that’s tightly coupled with OS-specific kernel mode APIs for async IO.

Java has support for that in java.nio.channels but that’s limited and is not integrated with the rest of their standard library.

C++ can do that, too, but quite hard in practice.

Runtimes like Go, .NET and erlang already have that stuff included. There’re some limitations (e.g. erlang doesn’t support that on Windows, BTW they call the feature “kernel poll”), but still it works great and very easy to use.

Re: Go hits the concurrency nail on the head

#254

Post by kasey_junk »

Const-me wrote: post #253
kasey_junk wrote: post #234

Earlier quoted context omitted.

Green thread schedulers are available (and I’ve had direct experience with them) in the JVM & C++ as well.

Scheduling is not enough. For efficient IO you need a scheduler that’s tightly coupled with OS-specific kernel mode APIs for async IO. Java has support for that in java.nio.channels but that’s limited and is not integrated with the rest of their standard library. C++ can do that, too, but quite hard in practice. Runtimes like Go, .NET and erlang already have that stuff included. There’re some limitations (e.g. erlang…

Take a look at quasar for the JVM. In practice I’ve found it outperforms* golang in my workloads.

* there is a small fixed overhead increase in memory.

Re: Go hits the concurrency nail on the head

#255

Post by dnautics »

geodel wrote: post #218
dnautics wrote: post #148

Earlier quoted context omitted.

I recall hearing no, somewhere. I am under the understanding, (don't know where from) that Cisco DOES use Erlang in their stack, and there is a group of people at VMware that does.

Thanks. This is something where simple internet search yields nothing much. Possibly because these network switches are proprietary platforms and they do not publish how internals are implemented.

I found the Cisco reference https://twitter.com/guieevc/status/1002494428748140544?s=09

Re: Go hits the concurrency nail on the head

#256

Post by dnautics »

marcosdumay wrote: post #250
the_clarence wrote: post #33

Earlier quoted context omitted.

You’re mentioning functional languages. That’s not for everyone or every usecase. (I love Erlang.)

Neither is concurrency. But if you need concurrency, functional is very visibly the way to go.

Definitely agree. For work I built a highly concurrent job scheduler in 3 months from zero in elixir, and being confident about the internals due to its functional nature let me focus on smoothening the interface edges

Re: Go hits the concurrency nail on the head

#257

Post by Const-me »

kasey_junk wrote: post #254
Const-me wrote: post #253

Earlier quoted context omitted.

Scheduling is not enough. For efficient IO you need a scheduler that’s tightly coupled with OS-specific kernel mode APIs for async IO. Java has support for that in java.nio.channels but that’s limited and is not integrated with the rest of their standard library. C++ can do that, too, but quite hard in practice. Runtimes like Go, .NET and erlang already have that stuff included. There’re some limitations (e.g. erlang…

Take a look at quasar for the JVM. In practice I’ve found it outperforms* golang in my workloads. * there is a small fixed overhead increase in memory.

There’re indeed multiple third-party libraries for that in many languages. E.g. for C++ we have lubuv, boost.asio, etc. However, built-in solutions have upsides.

They work out of the box i.e. deployment is simpler.

They’re integrated into the language, e.g. most network IO in golang is asynchronous under the hood, compiler and runtime do that automatically.

They’re integrated into standard libraries, e.g. in .NET all streams be it files, sockets, or transforms like compressors and encryptors support asynchronous operations.

The support is usually better, too.

Re: Go hits the concurrency nail on the head

#258

Post by digitalzombie »

weberc2 wrote: post #77
nimish wrote: post #44

Earlier quoted context omitted.

Yeah, irritatingly. Erlang had this nailed years before. It's a bit too weird syntactically, and doesn't have the full force of Google pushing it, so it gets ignored :(

> full force of Google pushing it This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!". There is a small team at Google that work on the language along with the open source community. I'm pretty sure none of Google's marketing team works to promote the language, and I'm sure that its success is much less important to Google than Erlang's success was to Ericcs…

> This trope is getting old. Variations include "Go is only popular because Google spends millions marketing it!".

I chose Angular.js because of google actually. And then Google did me dirty with Angular 2.

Corporate sponsorship is actually a huge driving for my decision and many company too.

Having a big company is a good indicator of success and it says that that programming language will have a stable contributors. Google also are using Go so they also have a stable programmers within the ecosystem.

Getting developers to adopt a tech and be in it is hard. Google have bunch of their dev in it and which increase the chances of these dev will present and talk in meetup to evangelicalize others.

Re: Go hits the concurrency nail on the head

#259

Post by toast0 »

marcosdumay wrote: post #243
dboreham wrote: post #217

Earlier quoted context omitted.

I believe there are boxes in production with 1E6 live connections.

If they exist, they are running software written on either C or Rust, that can avoid memory efficiency traps and can schedule their workers on a more optimum way than a general purpose language. That said, I'm not sure such thing exists. Just the memory overhead some common libraries impose on connections is enough to fill some 32GB.

Erlang works just fine for that many connections (depending on how much CPU you spend doing real work per connection). Socket buffers are tunable. 32GB isn't that much ram for a server, Android phones are shipping with 6gb, you can get 6TB into a server without getting too exotic.

Re: Go hits the concurrency nail on the head

#260

Post by NightlyDev »

marcosdumay wrote: post #243
dboreham wrote: post #217

Earlier quoted context omitted.

I believe there are boxes in production with 1E6 live connections.

If they exist, they are running software written on either C or Rust, that can avoid memory efficiency traps and can schedule their workers on a more optimum way than a general purpose language. That said, I'm not sure such thing exists. Just the memory overhead some common libraries impose on connections is enough to fill some 32GB.

3 million connections: https://medium.freecodecamp.org/million-websockets-and-go-cc...

Heck, you can probably handle a million connections using PHP(with swoole).

Post reply on HN