[deleted]
Linux Namespaces and Go Don't Mix
31–40 of 175 posts
Re: Linux Namespaces and Go Don't Mix
#32Earlier quoted context omitted.
Yes but the problem with languages like Nim is lack of support and maturity. Go is more versatile and at the same time more mature than anything out there. It is a different design and it excels in what it does (considering all tradeoffs now). Will Nim be as versatile and solid as Go in the future? Hard to predict but i would say no. You need a solid financial backing and certain amount of adoption where people actua…
> Yes but the problem with languages like Nim is lack of support and maturity. Agreed, that's why I don't use it for anything super important yet. Nim is approaching a 1.0 release soon. Go has a similar problem in that it is maintained almost entirely by Google who has a history of dropping projects without warning. > Go is more versatile and at the same time more mature than anything out there. This is objectively i…
> The only reason Go is as popular as it is is because of Google's marketing budget. Every programmer on Earth heard of Go within a few days of it's official release.
I think Google put lot of marketing budget for Dart. But I don't see it ever comes in discussion regarding popularity or lack of it.
It is fine a lot of people do not like Go but claiming its popular just because of Google seems baseless.
Re: Linux Namespaces and Go Don't Mix
#33Earlier quoted context omitted.
> You don't really know if your code will work until you compile. This is true in every text-based programming language. s/compile/execute/ for interpreted or repl-based languages.
I disagree. For instance, if I'm writing something in C and I know that it is syntactically and semantically correct, I know that it will definitely compile. Go hijacks control flow and makes it more difficult to reason about how your code will be compiled and executed. At least that is true in my personal experience.
Sorry, I don't understand what you mean by "Go hijacks control flow". Could you elaborate cases, where Go did not behave as you expected? And where syntactic and semantic correct Go code did not compile?
Re: Linux Namespaces and Go Don't Mix
#34Earlier quoted context omitted.
> You don't really know if your code will work until you compile. This is true in every text-based programming language. s/compile/execute/ for interpreted or repl-based languages.
I disagree. For instance, if I'm writing something in C and I know that it is syntactically and semantically correct, I know that it will definitely compile. Go hijacks control flow and makes it more difficult to reason about how your code will be compiled and executed. At least that is true in my personal experience.
If you write a syntactically and semantically correct go program it will compile. Can you give an example?
Re: Linux Namespaces and Go Don't Mix
#35Earlier quoted context omitted.
No, it's a lot messier than C. In a regular C program (not using any special libraries for M:N threading) you wouldn't have to spawn an entirely separate process. This issue is one of the downsides of Go's M:N scheduling. The OS is simply not aware of what the Go runtime is doing, and as a result you get impedance mismatches like this. It "raises a few eyebrows" because M:N scheduling is unpopular outside of Go and E…
Historically, much (I would probably argue most) C concurrency has been implemented with fork. Certainly not all, and there are many ways to handle it in C...but fork is really common, and I don't think it's considered all that big of a deal to do so. It is idiomatic (at least historically and across maybe billions of lines of C code), and not much harder to reason about than many kinds of thread implementation in C;…
Separate threads for IO was really common in C and C++ in the 90s.
In addition fork() style concurrency was essentially nonexistent outside of Unix.
Re: Linux Namespaces and Go Don't Mix
#36Earlier quoted context omitted.
>" I've personally built two container runtimes in other languages do to the namespace clumsiness." Can you share any details on those other container runtimes?
One was a simplified runtime in c, similar to a stripped down version of systemd-nspawn. I can hopefully share the other one in a few weeks. I'm going through an open source approval process for it.
Thanks. It's an interesting topic. I hope you post it on HN then.
Re: Linux Namespaces and Go Don't Mix
#37this is just a more complex version of the issue where go can't safely do the daemonize dance for a privileged port
Re: Linux Namespaces and Go Don't Mix
#38Earlier quoted context omitted.
> I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Perl/Ruby systems and ops background. You know, it's interesting. I've been programming with Python for about 6 years now. I've also picked up Javascript, SQL, bash, and PHP along the way. I'm always gaining a little bit of C knowle…
> The difficulty in Go is in learning about what the compiler thinks is OK. I think this is similar to what people think about the type system in Haskell or the borrow checker in Rust. With every higher level language comes new things to learn and obey.
But with Rust once you learn to work with the borrow checker you can work at any level of abstraction. With go you get what the Go implementors decided was best for you. (I omit Haskell because I don't know it)
I want to mix C++11/14 into that also. Now that the typesystem is used by the standard library to describe resource ownership in code whole categories of errors can be found at compile time. If you are new this it can seem like you are fighting the compiler, but once you learn that the compiler just won't let you make certain kinds of mistakes you get access to every level of abstraction with C++11/14 and Rust. You can code in terms of passing database bindings betweens threads in threadpools or you can twiddle individual bits in specific registers and everything in between.
I don't know Go well, but it seems really limited. You can't write certain classes of bugs, but you also can't write many design patterns.
Re: Linux Namespaces and Go Don't Mix
#39Earlier quoted context omitted.
No, it's a lot messier than C. In a regular C program (not using any special libraries for M:N threading) you wouldn't have to spawn an entirely separate process. This issue is one of the downsides of Go's M:N scheduling. The OS is simply not aware of what the Go runtime is doing, and as a result you get impedance mismatches like this. It "raises a few eyebrows" because M:N scheduling is unpopular outside of Go and E…
Historically, much (I would probably argue most) C concurrency has been implemented with fork. Certainly not all, and there are many ways to handle it in C...but fork is really common, and I don't think it's considered all that big of a deal to do so. It is idiomatic (at least historically and across maybe billions of lines of C code), and not much harder to reason about than many kinds of thread implementation in C;…
> But, are you saying that to switch to a namespace in Go one must fork
The article is stating that to control the namespace that the threads execute in, that a separate process must be spawned so that the entire process can be forced into the correct namespace. Otherwise, the runtime can spawn new threads as it sees fit and you don't have control over which namespace they are in.
It might be possible to work around this from within the same process if it were possible to force the runtime to not spawn new threads in particular cases. If you could control when the runtime was allowed to spawn new threads, then you could organize the program / threads in a way that would keep the correct code operating in the correct namespace. Unfortunately, you can't.
Disclaimer: I don't know Go, but this is my understanding from reading the article.
Re: Linux Namespaces and Go Don't Mix
#40This leads to go code being roughly as messy/clumsy as C (or whatever else) code in the sections that need concurrency and also need to change namespace. That's unfortunate, but I don't know that it really "raises a few eyebrows". I mean, what's the better alternative to Go for this work? Maybe Rust? It is, at least more controllable at a lower level...but, not as easy to pick up for people coming from a C/Python/Per…
No, it's a lot messier than C. In a regular C program (not using any special libraries for M:N threading) you wouldn't have to spawn an entirely separate process. This issue is one of the downsides of Go's M:N scheduling. The OS is simply not aware of what the Go runtime is doing, and as a result you get impedance mismatches like this. It "raises a few eyebrows" because M:N scheduling is unpopular outside of Go and E…
As far as I know, Solaris threads are actually M:N threads on the system level. M:N threads are extremely efficient. A "native" thread is a heavyweight construct - e.g. by the stack space allocation. So this puts a limit on how many threads you can spawn in a program. For many tasks, this would force you to roll out your own M:N mapping system yourself. Doing it on the language level usually yields the better results.
Due to the implicit M:N mapping, Go goroutines are extremely cheap. This allows you to spawn as many, as your algorithm naturally requires. The Go runtime will automatically map them to native threads - typically one per avaliable CPU. As a consequence, a Go program that heavily uses goroutines has a pretty clean code and scales without much overhead across a large variation of number of CPU cores.