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

51–60 of 175 posts

Re: Linux Namespaces and Go Don't Mix

#51

Post by graysonk »

SwellJoe wrote: post #16
ahoka wrote: post #5

Earlier quoted context omitted.

Better alternative to C with the same low level control? Why not C++?

I don't know, exactly, but I know with some confidence that C++ has never had significant uptake among ops and systems people. The folks who build systems, run systems, and dip into code on occasion to make the systems run, but not as their full-time job, have never (to my knowledge) fallen in love with C++. They probably all know some C, Perl, and Python...maybe not a lick of C++ (except the "C" part). I think C++ m…

I can only speak about my own experience as an ops person, but C++ always just felt off to me for some reason. I tried to learn and use it for about 6 months and I always felt like I was so bogged down in minutia and standards.

C let's me focus on the underlying system and it is what Linux is written in, Python is quick to write and has great libraries, and Go is amazingly easy to pick up/read.

C++ always felt like it was more so a language designed for programmers who love code than something that lets me focus on what I love (systems).

Re: Linux Namespaces and Go Don't Mix

#52

Post by steveklabnik »

m0th87 wrote: post #17
pcwalton wrote: post #3

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

This makes sense, and I know it's why Rust abandoned green threading. But I can't help but worry that the focus on async I/O in Rust as a way of avoiding this issue is going to bring the language down a path that isn't as ergonomically pleasant as Go or Erlang's M:N threading for things like highly concurrent web services. Do you share this concern, or do you think Rust can achieve the same level of ergonomics withou…

There's a prototype of async/await that can help a lot with that.

Re: Linux Namespaces and Go Don't Mix

#53

Post by weberc2 »

sqeaky wrote: post #38
lkurusa wrote: post #14

Earlier quoted context omitted.

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

I have experience with Rust and Go as well as a dozen or so other languages. Go usually has one or more easy ways to solve a problem, and in my experience, these easy paths are usually much easier than in other languages. There are certain problems for which this isn't true (like the one documented here), but it's generally true. These easy paths are often not elegant, and sometimes they trade a 1% risk of type error for a 60% easier solution. They may also trade a small amount of performance for a large boost to usability.

Whether or not I choose Go is almost always comes down to whether I want to solve a problem quickly and with decent performance/readability/etc or if I want to take a lot longer for a solution that is more aesthetically pleasing or with a smaller risk of error.

I'm sure lots of people will argue that their language is faster to develop in, but apart from toy programs or those requiring libraries unavailable in Go, this has never been my experience. In particular, even after two years with Rust, I still have trouble reasoning around memory management, lifetimes, how to pass around functions, how to do anything asynchronously, etc. Go isn't perfect for anything, but it strikes a good balance for the kind of work I tend to do.

YMMV.

Re: Linux Namespaces and Go Don't Mix

#54

Post by scriptkiddy »

zellyn wrote: post #49
scriptkiddy wrote: post #28

Earlier quoted context omitted.

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

It's more than fine to be enthusiastic about programming languages. However, some of your points about Go are dubious. The reasons Go doesn't (yet) have generics are practical rather than philosophical. And well-documented. I also don't believe Google's marketing budget contributed much if anything to supporting Go. The _reputation_ of Google and the Go authors was far more important. (Personally, when I saw people l…

No, I encourage you to shill in fact.

> The reasons Go doesn't (yet) have generics are practical rather than philosophical. And well-documented.

Can you give an example? I guess I fail to understand why a statically typed language would choose to forgo all of the advantages generics provide. Does it have something to do with Goroutines?

> I also don't believe Google's marketing budget contributed much if anything to supporting Go.

I didn't necessarily mean their marketing budget. I should probably edit that. I meant that anything they do is news.

Re: Linux Namespaces and Go Don't Mix

#55

Post by dap »

_ph_ wrote: post #40
pcwalton wrote: post #3

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

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…

> As far as I know, Solaris threads are actually M:N threads on the system level.

Not for a long time, for all the reasons the parent mentioned (and then some).

Re: Linux Namespaces and Go Don't Mix

#56

Post by scriptkiddy »

geodel wrote: post #32
scriptkiddy wrote: post #28

Earlier quoted context omitted.

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

Well, Go is obviously not a bad language. That said, I do think that it's adoption was primarily fueled by Google's popularity. Imagine go being released by a single person or small group of people. How would people have heard about it?

Re: Linux Namespaces and Go Don't Mix

#57

Post by scriptkiddy »

holydude wrote: post #42
scriptkiddy wrote: post #28

Earlier quoted context omitted.

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

No it is absolutely fine to be enthusiastic about PLs. I enjoy reading about production ready Nim or Crystal apps :-)

Glad to hear it. Crystal is another language I've been getting more and more curious about lately.

Re: Linux Namespaces and Go Don't Mix

#58

Post by __jal »

sqeaky wrote: post #38
lkurusa wrote: post #14

Earlier quoted context omitted.

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

> I don't know Go well, but it seems really limited.

That was my experience, too. Vaguely interesting in a couple of ways, but definitely a bondage and discipline language and nowhere near compelling enough to make me want to put up with that.

Re: Linux Namespaces and Go Don't Mix

#59

Post by scriptkiddy »

_ph_ wrote: post #33
scriptkiddy wrote: post #25

Earlier quoted context omitted.

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?

So, keep in mind that my experience with Go is not at a professional level. Take this example:

https://gobyexample.com/channel-buffering

As far as my understanding is concerned, channels are a way for goroutines to pass data between one another, correct? Yet in this particular case, the channel `messages` is operating in the same manner as a generator or array. So, am I creating goroutines by passing messages to the channel or am I just using the channel as a simple buffer?

This example helps as well: https://gobyexample.com/channel-directions

Am I implicitly creating goroutines by using channels or am I simply creating a buffer?

Sorry I don't have any of my own code to share as I deleted all of my Go practice stuff.

Re: Linux Namespaces and Go Don't Mix

#60

Post by scriptkiddy »

helper wrote: post #34
scriptkiddy wrote: post #25

Earlier quoted context omitted.

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?

Please see my reply to __ph__.
Post reply on HN