Linux Namespaces and Go Don't Mix • Hacker News Board

Re: Linux Namespaces and Go Don't Mix

#171

Post by jankedeen » Wed, Jun 07, 2017, 5:37 PM UTC

SwellJoe wrote: post #93

jankedeen wrote: post #87

Earlier quoted context omitted.

Better C++ than Go or Rust. Antecedents and track record counts. Young people like the new thing. Go and Rust are capitalizing on that. Learn C. Take the time..it takes a couple years and some pain to learn it and then you will be amply rewarded. These languages (go|rust) are reactive and suffice for some purposes but they really kind of suck in every other possible way.

I'm old(ish), have worked professionally with C, and I think I have to disagree with you. Certainly, learn some C; it's the language on which all of our platforms are currently built. But, building new things in C? Nah. I don't see any reason for that. Since C was designed, we've ("we" as in our industry, not specifically me and you) learned a lot and our systems have grown massively in all dimensions. It would be op…

This is common nonsense. Those people who have stake in new language push and disparage and those that have stake in the old contrast. It's the old 'not broken' argument but your emphasis are particularly egregious in association and I don't believe you have done any real work other than posting.

Re: Linux Namespaces and Go Don't Mix

#172

Post by jankedeen » Wed, Jun 07, 2017, 5:39 PM UTC

je42 wrote: post #157

cyphar wrote: post #136

Earlier quoted context omitted.

> Rust is painful to write, painful to learn and makes you ask yourself: It's painful to write because writing software that is memory safe is not easy. Rust makes it insanely easy in comparison to the "old way" of doing it (hacking together a C program then having to patch security holes every release, never being certain that your code is actually memory safe). > Can I not write a well designed and correct program…

also, one key aspect is. There are may be individuals out there that can do this. however, usually code is written by multiple people. (and i would also count your future self as another person). that collaboration on the same code base requires automatic tests, otherwise the next person will break the code in non-obvious ways.

Don't propose a general replacement based on individual incapacity.

Re: Linux Namespaces and Go Don't Mix

#173

Post by pencilhappen » Wed, Jun 07, 2017, 7:49 PM UTC

pcwalton wrote: post #161

pencilhappen wrote: post #89

Earlier quoted context omitted.

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

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.

A thread pool is far from "ergonomic", it's accidental complexity with numerous gotchas.

Re: Linux Namespaces and Go Don't Mix

#174

Post by jankedeen » Fri, Jun 09, 2017, 3:38 PM UTC

eropple wrote: post #100

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

I'm downvoting you for being profoundly shitty and mean, not because I disagree with you. I do disagree with you, as it happens, but I'd downvote this sort of thing if I agreed too. There's a difference between bluntness being read as rudeness and what you're doing. Stop.

This is sadly amusing. Are you making the world in your googly feely image? It's just despotism of another stripe in case you haven't figured it out yet.

Re: Linux Namespaces and Go Don't Mix

#175

Post by jankedeen » Fri, Jun 09, 2017, 3:54 PM UTC

cyphar wrote: post #133

YZF wrote: post #124

Earlier quoted context omitted.

It's possible they didn't know different Linux threads can be in different namespaces, it's not exactly something everyone knows. Namespaces in Linux aren't that new (15 years or so). It's possible they knew but decided this wasn't an important enough use case to warrant language features. I've never needed to have half my process in one namespace and half in another. It's a niche application. Green threads/goroutine…

> Someone should file a Go bug and see what the response is... From memory, several people working on Docker have done so over the years. It's still a problem because the only "real" solutions are: 1. Do what glibc does and implement nptl(7) (effectively a way to make Linux threads look like POSIX threads by synchronising certain operations on all threads). This would require making first-class library APIs for Linux…

Why don't you just code in python and shut up?