News for hackers. Stuff that matters.
Re:Linux Namespaces and Go Don't Mix by pcwalton on Friday June 02, 2017 @03:36PM (#14472722)
It's harder for us, but I think we can get to an ergonomic solution with async/await.

It's not as easy as threads (M:N vs 1:1 is a red herring as far as this is concerned), but there's no free lunch.

Re:Linux Namespaces and Go Don't Mix by jpgvm on Friday June 02, 2017 @10:49PM (#14474734)
I hope the Rust team takes a look at Kotlins coroutines (and all the stuff they managed to build on top of them). I think Kotlin is a good example because it is built ontop of a 1:1 runtime and uses very elegant primitives.

I was pretty disappointed Rust didn't ship with async/await and some form of lightweight thread but it's understandable.

Re:Linux Namespaces and Go Don't Mix by pencilhappen on Friday June 02, 2017 @07:52PM (#14474075)
async/await still has the fundamental problem of composability that all the other attempts at sugaring around an event loop have (aka the "functions have colors" problem [1]). It sucks for collaboration, which is one of the most important things for modern software development.

1. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Re:Linux Namespaces and Go Don't Mix by pcwalton on Saturday June 03, 2017 @07:14PM (#14479016)
I don't like that article, because (1) it claims Go is doing something new, while Go is really just threads with a particularly idiosyncratic implementation; (2) it ignores the fact that you can convert async to sync by just blocking and sync to async by proxying out to a thread pool. The "what color is your function" problem really isn't a big deal.
Re:Linux Namespaces and Go Don't Mix by pencilhappen on Wednesday June 07, 2017 @03:49PM (#14509358)
A thread pool is far from "ergonomic", it's accidental complexity with numerous gotchas.