4 ms·

This feels more like a failure than a win. Don't get me wrong, I love Valgrind, and have been using it extensively in my past life as a C developer. Though the

by tasn 1y ago

This feels more like a failure than a win. Don't get me wrong, I love Valgrind, and have been using it extensively in my past life as a C developer. Though the fact that Go needs Valgrind feels like a failure of the language or the ecosystem. I've been doing Rust for ~6 years now, and haven't had to reach for Valgrind even once (I think a team member may have use it once). I realize that's probably because of cgo, and maybe it's in-fact a step forward, but I can help but feel like it is a step backwards.

pjmlp 1y ago
Depends on how much unsafe you actually happen to write, use unsafe crates, or link into C and C++ libraries. I also seldom need something like this in Java, .NET or node, until a dependency makes it otherwise.
- tasn 1y ago
  For sure, that's why I said it's possibly due to the ecosystem. We link against two C libraries other than libc: OpenSSL and librdkafka. Though they are both abstracted away with solid Rust bindings so for us, so as a consumer of these libs it hasn't been a problem (I guess it may be a problem for the people developing them). I guess maybe the failure is not the addition of it (as it's useful for people writing the bindings), but rather how happy everyone on the thread is (which means it's more useful than it should be due to a failure with the ecosystem).
  - pjmlp 1y ago
    Even though there is the whole CGO is not Go meme, it certainly makes it rather easy to write C and C++ code directly on a Go project, thus I imagine some folks reach rather easy to it. Which I can relate to, when doing stuff that is Windows only , I rather make use of C++/CLI than getting P/Invoke declarations correctly.
  - 9rx 1y ago
    > but rather how happy everyone on the thread is (which means it's more useful than it should be due to a failure with the ecosystem). More likely Go users are just happy in general. The Rust users always come across as being incredibly grumpy for some reason, which may be why that happiness — or what would be considered normalcy in any other venue — seems to stand out so much in comparison. > We link against [...] OpenSSL Which is kind of funny as Valgrind support was added specifically for the crypto package to help test tricky constant-time cases. You think that the failure of the ecosystem is that Go has built high-quality crypto support in rather than relying on the Heartbleed library instead...? That is certainly an interesting take.
    - tasn 1y ago
      Rust has rustls, we need to use OpenSSL for a very specific set of reasons unfortunately, but rustls is great and most people can just use that. Also, I had no idea it was added because of constant time crypto that was shared after I wrote my top level comment.
      - deleted 1y ago
        [deleted]
      - 9rx 1y ago
        I'm not entirely clear here. Are you saying that the failure of the Go ecosystem was in not building on rusttls (which didn't exist at the time), or are you saying that the failure of the ecosystem was in you not stopping to think before writing your comment?
bracewel 1y ago
This is mainly actually for testing constant-time code, rather than doing proper memory tracking (see https://www.imperialviolet.org/2010/04/01/ctgrind.html https://www.imperialviolet.org/2010/04/01/ctgrind.html for a slightly out-of-date description of this technique).
- tasn 1y ago
  Oh, interesting. Thanks for sharing! I guess there's also callgrind that may be useful for Gophers.
  - chrsig 1y ago
    Useful for people -- believe it or not not all of us internalize the language we use as part of our identity (and species).
JyB 1y ago
I never understand why there's always one of the top comment on every Go post being derogatory and mentioning Rust. It never fails. It starts to feel like a weird mix of defensiveness and superiority complex.
- stitched2gethr 1y ago
  There were developed around the same time so maybe that accounts for some of the comparisons, but at least in this case I think it matters that they are both relatively new languages with modern tooling.
  - 9rx 1y ago
    If they were being compared, shouldn't we also see the inverse? There is a discussion about Rust on the front page right now, with 230 comments at time of writing, and not a single mention of Go. In fairness, the next Rust discussion a few pages deep does mention Go, but in the context of: 1. Someone claiming that GC languages are inherently slow, where it was pointed out that it doesn't have to be that way, using Go as an example. It wasn't said in comparison with Rust. 2. A couple of instances of the same above behaviour; extolling the virtues of Rust and randomly deriding Go. As strange as the above behaviour is, at least Go was already introduced into the discussion. In these mentioned cases Go came from completely out in left field, having absolutely nothing to do with the original article or having any relation to the thread, only showing up seemingly because someone felt the need to put it down.
- flkenosad 1y ago
  Religious wars. C is Judaism. Go/Rust/Python/Ruby are all the different sects of Christianity. AI is Islam.
- TinkersW 1y ago
  You should see the C++ threads
- tasn 1y ago
  If I had to guess: because Rust engineers are like every other engineer that reads HN. They read stories, sometimes comment, and share from their own experience. Rust and Go were created roughly at the same time and are more directly comparable than e.g. Go and Ruby, so you don't see Ruby people writing about not having to use Valgrind. This means you'll see more comments from Rust devs than others in Go threads. At least that's why I wrote that original comment.
stusmall 1y ago
I've had to use valgrind a bit in Rust. Not much but the need is there. It really depends on the product you are working with. Rust is an extremely flexible language and can be used in many spaces. From high level abstract functional code to low level C-like code on a microcontroller. Some use cases would never image using unsafe, some can't live without it. For most FFI to C is just a fact of life, so it comes up somewhere. When I used it before I was working on a Rust modules that was loaded in by nginx. This was before there were official or even community bindings to nginx.... so there was a lot of opportunity for mistakes.

by tasn 1y ago

pjmlp 1y ago

Depends on how much unsafe you actually happen to write, use unsafe crates, or link into C and C++ libraries. I also seldom need something like this in Java, .NET or node, until a dependency makes it otherwise.

tasn 1y ago
For sure, that's why I said it's possibly due to the ecosystem. We link against two C libraries other than libc: OpenSSL and librdkafka. Though they are both abstracted away with solid Rust bindings so for us, so as a consumer of these libs it hasn't been a problem (I guess it may be a problem for the people developing them). I guess maybe the failure is not the addition of it (as it's useful for people writing the bindings), but rather how happy everyone on the thread is (which means it's more useful than it should be due to a failure with the ecosystem).
- pjmlp 1y ago
  Even though there is the whole CGO is not Go meme, it certainly makes it rather easy to write C and C++ code directly on a Go project, thus I imagine some folks reach rather easy to it. Which I can relate to, when doing stuff that is Windows only , I rather make use of C++/CLI than getting P/Invoke declarations correctly.
- 9rx 1y ago
  > but rather how happy everyone on the thread is (which means it's more useful than it should be due to a failure with the ecosystem). More likely Go users are just happy in general. The Rust users always come across as being incredibly grumpy for some reason, which may be why that happiness — or what would be considered normalcy in any other venue — seems to stand out so much in comparison. > We link against [...] OpenSSL Which is kind of funny as Valgrind support was added specifically for the crypto package to help test tricky constant-time cases. You think that the failure of the ecosystem is that Go has built high-quality crypto support in rather than relying on the Heartbleed library instead...? That is certainly an interesting take.
  - tasn 1y ago
    Rust has rustls, we need to use OpenSSL for a very specific set of reasons unfortunately, but rustls is great and most people can just use that. Also, I had no idea it was added because of constant time crypto that was shared after I wrote my top level comment.
    - deleted 1y ago
      [deleted]
    - 9rx 1y ago
      I'm not entirely clear here. Are you saying that the failure of the Go ecosystem was in not building on rusttls (which didn't exist at the time), or are you saying that the failure of the ecosystem was in you not stopping to think before writing your comment?

bracewel 1y ago

This is mainly actually for testing constant-time code, rather than doing proper memory tracking (see https://www.imperialviolet.org/2010/04/01/ctgrind.html https://www.imperialviolet.org/2010/04/01/ctgrind.html for a slightly out-of-date description of this technique).

tasn 1y ago
Oh, interesting. Thanks for sharing! I guess there's also callgrind that may be useful for Gophers.
- chrsig 1y ago
  Useful for people -- believe it or not not all of us internalize the language we use as part of our identity (and species).

JyB 1y ago

I never understand why there's always one of the top comment on every Go post being derogatory and mentioning Rust. It never fails. It starts to feel like a weird mix of defensiveness and superiority complex.

stitched2gethr 1y ago
There were developed around the same time so maybe that accounts for some of the comparisons, but at least in this case I think it matters that they are both relatively new languages with modern tooling.
- 9rx 1y ago
  If they were being compared, shouldn't we also see the inverse? There is a discussion about Rust on the front page right now, with 230 comments at time of writing, and not a single mention of Go. In fairness, the next Rust discussion a few pages deep does mention Go, but in the context of: 1. Someone claiming that GC languages are inherently slow, where it was pointed out that it doesn't have to be that way, using Go as an example. It wasn't said in comparison with Rust. 2. A couple of instances of the same above behaviour; extolling the virtues of Rust and randomly deriding Go. As strange as the above behaviour is, at least Go was already introduced into the discussion. In these mentioned cases Go came from completely out in left field, having absolutely nothing to do with the original article or having any relation to the thread, only showing up seemingly because someone felt the need to put it down.
flkenosad 1y ago
Religious wars. C is Judaism. Go/Rust/Python/Ruby are all the different sects of Christianity. AI is Islam.
TinkersW 1y ago
You should see the C++ threads
tasn 1y ago
If I had to guess: because Rust engineers are like every other engineer that reads HN. They read stories, sometimes comment, and share from their own experience. Rust and Go were created roughly at the same time and are more directly comparable than e.g. Go and Ruby, so you don't see Ruby people writing about not having to use Valgrind. This means you'll see more comments from Rust devs than others in Go threads. At least that's why I wrote that original comment.

stusmall 1y ago

I've had to use valgrind a bit in Rust. Not much but the need is there. It really depends on the product you are working with. Rust is an extremely flexible language and can be used in many spaces. From high level abstract functional code to low level C-like code on a microcontroller. Some use cases would never image using unsafe, some can't live without it. For most FFI to C is just a fact of life, so it comes up somewhere. When I used it before I was working on a Rust modules that was loaded in by nginx. This was before there were official or even community bindings to nginx.... so there was a lot of opportunity for mistakes.