5 ms·

Why shouldn’t Go have a place i new code? You talk about Rust, but why does that make Go a bad choice? Is it technical reasons or politics?

neel_k 7y ago
It's taking on a fair amount of risk to use a language that (a) encourages the use of concurrency but (b) is not memory-safe when you do so, especially when writing network-facing code. Go uses multi-word primitive values, which means assignments are not atomic. Consequently, racing assignment statements can leave objects in weird states that violate type and gc invariants. For example, racing assignments to a value of interface type can give you an object with the wrong dictionary for its data. The argument for not worrying about this is that this is an unlikely scenario. It's reasonable to think in probabilistic terms when clients are not trying to break the software (eg, in games or office software). However, attackers are not probabilistic: they actively search out vulnerabilities and push on them, so potential vulnerabilities turn into actual vulnerabilities in predictable fashion.
- sagichmal 7y ago
  “Memory safe” has a specific technical definition, and “atomic assignment” isn’t it.
  - burntsushi 7y ago
    No, the GP is correct. Data races are undefined behavior, and break memory safety: https://research.swtch.com/gorace https://research.swtch.com/gorace
    - pwodhouse 7y ago
      Is there a sense in which Russ's claim that "data races are not security problems" is true? It seems to be assuming that data races are impossible to exploit by users (data input), only by programmers.
      - kibwen 7y ago
        Presumably because data races are so inconsistently triggered that creating a reliable exploit would be generally infeasible, even with control over user input. However, this unpredictability is also why data races (among other concurrency issues) are some of the most maddening types of bugs to observe, hunt down, and diagnose, which is why eliminating data races is actually a big deal for anyone who's ever wrestled with threads before.
  - 0815test 7y ago
    Go is indeed memory-safe for sequential code, but non-atomic assignment can definitely break memory safety in multi-threaded settings - it's effectively a data race.
- deleted 7y ago
  [deleted]
- brodsky 7y ago
  Admittedly, my understanding of the problems you describe is superficial at best. But it sounds like you are citing a rather narrow set of requirements (memory safety in network code where protection against exploitation is paramount) as a means to generalize that Go is overall not a good language and should be avoided in new code. I don't think that's fair. As with everything, it may be not suitable for the scope you outlined, but it evidently has its place in a multitude of other uses.
- foldr 7y ago
  Go definitely doesn't encourage code where multiple goroutines directly modify the same values. You're supposed to use channels for communication between goroutines by default. Rust also lets you write memory unsafe multithreaded code, if you want to.
  - burntsushi 7y ago
    > Rust also lets you write memory unsafe multithreaded code, if you want to. That's a false equivalence. Nobody is criticizing Go for having an `unsafe` package. The criticism is that your Go code can be undefined without using the `unsafe` package. In Rust, you need to use `unsafe` in order to write code that has data races. Otherwise, data races are statically prevented in safe code, unlike in Go.
    - foldr 7y ago
      You don’t need to use 'unsafe' yourself in Rust. Any package that you’re using might contain unsafe code that its author believes (rightly or wrongly) to be thread-safe. The situation with Go is pretty clear. Channels are safe. If you start mutating shared state across different goroutines, then you’re in the same situation you’d be in if you were doing the same thing in C++. Anyone who doesn't understand why that's potentially unsafe wouldn't be ready for Rust in any case.
      - burntsushi 7y ago
        > You don’t need to use ‘unsafe’ yourself in Rust. Any package that you’re using might contain unsafe code that its author believes (rightly or wrongly) to be thread-safe. Sigh. That's true of Go too. Both Rust and Go have `unsafe` labels that give access to dangerous things that can cause UB. Both Rust and Go are susceptible to UB-at-a-distance if library code internally uses `unsafe` incorrectly. The difference is that, in Go, you can write code with data races without using any `unsafe` at all. Nothing will yell at you (unless you exercise the race in a test and run the race detector). Rust does not suffer from this flaw. I've been writing both Rust and Go since before each had their 1.0 release, and I like both languages. This isn't some back-handed comment about how I think Go is bad because of this. I rarely trip over data race related bugs in Go, but they do happen, so they aren't a huge issue in practice. (And your continued mention of channels is a red herring. Go has mutexes and idiomatic code uses mutexes quite frequently. Channels are not always the right thing to use.) Nevertheless, the comments here comparing Rust and Go are a fairly important mischaracterization of how each language treats memory safety, and it's important therefore to correct that.
laumars 7y ago
In my 30+ years of experience writing software in a wide variety of paradigms (never mind imperative languages) I've found most of the arguments for and against Go to amount to little more than tribalism and snobbery[1] There is no such thing as perfect language and clearly some languages are designed to be better at some scenarios than some other languages...and visa versa. The problem with Go is that it's designed to be a boring language where it's aims are more around language simplicity and API stability. This makes it very easy to play the "death by a thousand paper cuts" game with Go. If you'd believe what you read on HN, nobody would be using it when actually it is a very popular language. [1] I'm sure that comment will annoy a great many on here but that's my honest observation.
- gypsyharlot 7y ago
  This is exactly my experience. I've used C (closer to Go than Rust) and I've used C++ (closer to Rust than Go) in previous jobs. My experience is that the C programmers tend to focus on the problem at hand. On C++ teams, people spend a lot of time going to C++ conferences and discussing the idiomatic approach to mundane tasks in their superior language. I imagine we'll see the same thing happen in Go and Rust... different personalities are drawn to the different languages. I'd rather be going to security, networking and crypto conferences instead of wasting a lot of time on a particular language.
  - majewsky 7y ago
    Language-specific conferences are not just a C++ thing, though. There are Java conferences, Ruby conferences, Python conferences, Rust conferences, etc. The only thing that doesn't exist is a C conference, but that's because C is the least common denominator. Pretty sure that there are Go conferences.
    - chewxy 7y ago
      There are. GopherCons are a thing. Also, here's an ad for the upcoming GopherConAU : https://gophercon.com.au https://gophercon.com.au. CFPs are open until end of June. https://papercall.io/gophercon-au-2019 https://papercall.io/gophercon-au-2019

neel_k 7y ago

It's taking on a fair amount of risk to use a language that (a) encourages the use of concurrency but (b) is not memory-safe when you do so, especially when writing network-facing code. Go uses multi-word primitive values, which means assignments are not atomic. Consequently, racing assignment statements can leave objects in weird states that violate type and gc invariants. For example, racing assignments to a value of interface type can give you an object with the wrong dictionary for its data. The argument for not worrying about this is that this is an unlikely scenario. It's reasonable to think in probabilistic terms when clients are not trying to break the software (eg, in games or office software). However, attackers are not probabilistic: they actively search out vulnerabilities and push on them, so potential vulnerabilities turn into actual vulnerabilities in predictable fashion.

sagichmal 7y ago
“Memory safe” has a specific technical definition, and “atomic assignment” isn’t it.
- burntsushi 7y ago
  No, the GP is correct. Data races are undefined behavior, and break memory safety: https://research.swtch.com/gorace https://research.swtch.com/gorace
  - pwodhouse 7y ago
    Is there a sense in which Russ's claim that "data races are not security problems" is true? It seems to be assuming that data races are impossible to exploit by users (data input), only by programmers.
    - kibwen 7y ago
      Presumably because data races are so inconsistently triggered that creating a reliable exploit would be generally infeasible, even with control over user input. However, this unpredictability is also why data races (among other concurrency issues) are some of the most maddening types of bugs to observe, hunt down, and diagnose, which is why eliminating data races is actually a big deal for anyone who's ever wrestled with threads before.
- 0815test 7y ago
  Go is indeed memory-safe for sequential code, but non-atomic assignment can definitely break memory safety in multi-threaded settings - it's effectively a data race.
deleted 7y ago
[deleted]
brodsky 7y ago
Admittedly, my understanding of the problems you describe is superficial at best. But it sounds like you are citing a rather narrow set of requirements (memory safety in network code where protection against exploitation is paramount) as a means to generalize that Go is overall not a good language and should be avoided in new code. I don't think that's fair. As with everything, it may be not suitable for the scope you outlined, but it evidently has its place in a multitude of other uses.
foldr 7y ago
Go definitely doesn't encourage code where multiple goroutines directly modify the same values. You're supposed to use channels for communication between goroutines by default. Rust also lets you write memory unsafe multithreaded code, if you want to.
- burntsushi 7y ago
  > Rust also lets you write memory unsafe multithreaded code, if you want to. That's a false equivalence. Nobody is criticizing Go for having an `unsafe` package. The criticism is that your Go code can be undefined without using the `unsafe` package. In Rust, you need to use `unsafe` in order to write code that has data races. Otherwise, data races are statically prevented in safe code, unlike in Go.
  - foldr 7y ago
    You don’t need to use 'unsafe' yourself in Rust. Any package that you’re using might contain unsafe code that its author believes (rightly or wrongly) to be thread-safe. The situation with Go is pretty clear. Channels are safe. If you start mutating shared state across different goroutines, then you’re in the same situation you’d be in if you were doing the same thing in C++. Anyone who doesn't understand why that's potentially unsafe wouldn't be ready for Rust in any case.
    - burntsushi 7y ago
      > You don’t need to use ‘unsafe’ yourself in Rust. Any package that you’re using might contain unsafe code that its author believes (rightly or wrongly) to be thread-safe. Sigh. That's true of Go too. Both Rust and Go have `unsafe` labels that give access to dangerous things that can cause UB. Both Rust and Go are susceptible to UB-at-a-distance if library code internally uses `unsafe` incorrectly. The difference is that, in Go, you can write code with data races without using any `unsafe` at all. Nothing will yell at you (unless you exercise the race in a test and run the race detector). Rust does not suffer from this flaw. I've been writing both Rust and Go since before each had their 1.0 release, and I like both languages. This isn't some back-handed comment about how I think Go is bad because of this. I rarely trip over data race related bugs in Go, but they do happen, so they aren't a huge issue in practice. (And your continued mention of channels is a red herring. Go has mutexes and idiomatic code uses mutexes quite frequently. Channels are not always the right thing to use.) Nevertheless, the comments here comparing Rust and Go are a fairly important mischaracterization of how each language treats memory safety, and it's important therefore to correct that.

laumars 7y ago

In my 30+ years of experience writing software in a wide variety of paradigms (never mind imperative languages) I've found most of the arguments for and against Go to amount to little more than tribalism and snobbery[1] There is no such thing as perfect language and clearly some languages are designed to be better at some scenarios than some other languages...and visa versa. The problem with Go is that it's designed to be a boring language where it's aims are more around language simplicity and API stability. This makes it very easy to play the "death by a thousand paper cuts" game with Go. If you'd believe what you read on HN, nobody would be using it when actually it is a very popular language. [1] I'm sure that comment will annoy a great many on here but that's my honest observation.

gypsyharlot 7y ago
This is exactly my experience. I've used C (closer to Go than Rust) and I've used C++ (closer to Rust than Go) in previous jobs. My experience is that the C programmers tend to focus on the problem at hand. On C++ teams, people spend a lot of time going to C++ conferences and discussing the idiomatic approach to mundane tasks in their superior language. I imagine we'll see the same thing happen in Go and Rust... different personalities are drawn to the different languages. I'd rather be going to security, networking and crypto conferences instead of wasting a lot of time on a particular language.
- majewsky 7y ago
  Language-specific conferences are not just a C++ thing, though. There are Java conferences, Ruby conferences, Python conferences, Rust conferences, etc. The only thing that doesn't exist is a C conference, but that's because C is the least common denominator. Pretty sure that there are Go conferences.
  - chewxy 7y ago
    There are. GopherCons are a thing. Also, here's an ad for the upcoming GopherConAU : https://gophercon.com.au https://gophercon.com.au. CFPs are open until end of June. https://papercall.io/gophercon-au-2019 https://papercall.io/gophercon-au-2019