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

Linux Namespaces and Go Don't Mix

weave.works

Post reply on HN
Print view View original

101–110 of 175 posts

Re: Linux Namespaces and Go Don't Mix

#101

Post by catern »

concede_pluto wrote: post #99
jankedeen wrote: post #81

Earlier quoted context omitted.

* Coercion: large down vote/propaganda community against any negative rust idea..evidenced here. * IP Holders, well this is speculative. I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it. Rust is painful to write, painful to learn and makes you ask yourself: Can I not write a well designed and correct program in C? Of course I can. Why Am I Learning Rust?…

> Can I not write a well designed and correct program in C? We have decades of coredumps and exploits to convince us that nobody can. How many well-known apps can you name that have never blown up randomly? I can't think of a single one. How much more failure until it's reasonable to think that C requires an inhuman level of perfection and almost any alternative would be an improvement? I hear good things about seL4…

GNU ls has never segfaulted or otherwise blown up for me. :)

Re: Linux Namespaces and Go Don't Mix

#102

Post by cat199 »

SwellJoe wrote: post #2

This 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…

> I mean, what's the better alternative to Go for this work?

Separate processes, like the post suggests?

I have no idea why someone would expect user-level pseudothreads to execute across system-level primitive boundaries.. seems fairly obvious to me.

I don't expect a chrooted daemon (e.g. apache, etc) to have access to parent thread contexts.. etc.

Fork & pipe IPC shouldn't be too difficult for anyone to understand, beyond that, if you don't understand these things, you probably shouldn't be writing code that complex..

Re: Linux Namespaces and Go Don't Mix

#103

Post by solidsnack9000 »

jankedeen wrote: post #81
steveklabnik wrote: post #77

Earlier quoted context omitted.

> Oh, btw: Fuck RUST. For once and for all fuck this tyranny of coercion by potential IP holders. It is a shit language. ... what? I am confused as to what you're saying here.

* Coercion: large down vote/propaganda community against any negative rust idea..evidenced here. * IP Holders, well this is speculative. I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it. Rust is painful to write, painful to learn and makes you ask yourself: Can I not write a well designed and correct program in C? Of course I can. Why Am I Learning Rust?…

> I can't understand anyone who would compare Rust against C in a positive way without possibly profiting from it.

A year or so ago I wrote a Postgres extension in Rust. It was a real delight to have a package manager and to only have to worry about allocations within Postgres.

But whenever I want to code a big hairball without libraries or namespaces and use autoconf and all that great stuff, I still stick with C.

Re: Linux Namespaces and Go Don't Mix

#104

Post by cat199 »

scriptkiddy wrote: post #4
SwellJoe wrote: post #2

This 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…

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

> 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. ... However, need to do something in a different way than Go decides is correct? Well, you can't. ...

Pardon me and no offense, but it sounds like you are hitting the 'statically typed language' boundary.. all of the others you mention are fairly loose and dynamic. Go & C, not so much. It sounds like your use of C has been library code, which presumably is more 'data processing' oriented and so doesn't require much structure or control of process/runtime/etc.. which is where you will run into this stuff on the c side..

This is why I moved from c/c++ into dynamic languages to start with.. that said, as I grow more sophisticated and can 'deal' with the typing/lower 'machine' level control, the more I can understand other tools.. even C++! ..

i mention this because each layer of abstraction is there for a reason.. best to view with a fresh pair of eyes imho

Re: Linux Namespaces and Go Don't Mix

#106

Post by solidsnack9000 »

holydude wrote: post #11
scriptkiddy wrote: post #4

Earlier 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…

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…

> Go is more versatile and at the same time more mature than anything out there.

This doesn't seem like a very credible statement on the face of it. Is Go more mature and more versatile than Python? Than Java? Than...Scala? Go does seem to share a lot of use cases (and limitations) with Java; and it would be hard to call it more mature.

Re: Linux Namespaces and Go Don't Mix

#108

Post by TheDong »

mappu wrote: post #84
SwellJoe wrote: post #2

This 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…

You can keep using Go. Its behaviour here is actually usually what you want. To avoid the authors' issue, you can write some functions in C. CGo has a very high level of integration (you can mix languages in the same source file) and would be quite simple for the case of a setns/execve wrapper.

> CGo has a very high level of integration

No, no it doesn't. CGo is slow as balls to call into and return from.

Types can't fully be shared.

It's interacted with via comments.

You can't use cgo to control the threading of the Go runtime itself, which is the real problem here.

The behavior you want is to be able to call linux syscalls that operate on threads and not be utterly fucked. That behavior cannot be accomplished with go nor go+cgo easily.

Threads in cgo are also kinda fucked.

Re: Linux Namespaces and Go Don't Mix

#109

Post by YZF »

Safety1stClyde wrote: post #94
jankedeen wrote: post #69

I read this crap in language design and despair. This is why C is my only recourse for systems programming in *nix environments.

This is what I cannot understand about Go: how did a newly-designed programming language end up as such a muddle?

Because this isn't really a language issue. It's an OS issue. Go assumes that all threads are equal and therefore any Goroutine can run on any thread and threads are all equal. Linux got late to the thread party and its threads are kind of like processes that haven't decided if they want to be processes or threads.

It's true the Go runtime could give users more control over goroutine and thread scheduling but that would kind of defeat the purpose of not needing to know about it and having Goroutines as the only flexible unit of concurrency.

I think the kludge here is on the Linux side. Having some magic properties bestowed upon threads doesn't make sense. The property should be accessible via a handle that can be shared amongst all threads.

Re: Linux Namespaces and Go Don't Mix

#110

Post by YZF »

jankedeen wrote: post #69

I read this crap in language design and despair. This is why C is my only recourse for systems programming in *nix environments.

It's a common practice in C to use thread pools for concurrency and queue tasks for those thread pools (e.g. libuv). I work on a C++ code base that mainly uses Goroutine like green threads. If you use a scheme like that you're kind of in the same position (at least with respect to anything running on that pool). It's true that it's easy to "escape" and manage your threads explicitly but unless you know exactly what you're doing you could run into similar issues.

I really don't think this is a language design issue but clearly if you want absolute control you can't get that with the Go run-time.

Post reply on HN