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

Go has added Valgrind support

go-review.googlesource.com

Post reply on HN
Print view View original

81–90 of 157 posts

Re: Go has added Valgrind support

#81

Post by cozzyd »

ben-schaaf wrote: post #72
stingraycharles wrote: post #53

Earlier quoted context omitted.

Somewhat yes, but as soon as you enter the world of multi-threading (which Go does a lot), the abstraction doesn’t work anymore: as I understand it (or rather, understood: last time I really spent a lot of time digging into it with C++ code was a while ago) it uses its own scheduler, and as such, a lot of subtle real world issues that would arise due to concurrency / race conditions / etc do not pop up in valgrind. A…

IME Helgrind does an great job finding concurrency issues.

Yes though last I tried to use it it sadly didn't support openmp. Maybe that's fixed now (that was a while ago)

(I think it was possible to use on openmp if you compiled your compiler with special options)

Re: Go has added Valgrind support

#82

Post by tasn »

bracewel wrote: post #77
tasn wrote: post #74

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

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 for a slightly out-of-date description of this technique).

Oh, interesting. Thanks for sharing!

I guess there's also callgrind that may be useful for Gophers.

Re: Go has added Valgrind support

#83

Post by JyB »

tasn wrote: post #74

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

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.

Re: Go has added Valgrind support

#84

Post by pjmlp »

tasn wrote: post #79
pjmlp wrote: post #75

Earlier quoted context omitted.

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.

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

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.

Re: Go has added Valgrind support

#85

Post by chrsig »

tasn wrote: post #82
bracewel wrote: post #77

Earlier quoted context omitted.

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 for a slightly out-of-date description of this technique).

Oh, interesting. Thanks for sharing! I guess there's also callgrind that may be useful for Gophers.

Useful for people -- believe it or not not all of us internalize the language we use as part of our identity (and species).

Re: Go has added Valgrind support

#86

Post by yxhuvud »

DishyDev wrote: post #70

Very cool. Should flush out a few bugs. I'd be interested to know why Valgrind vs the Clang AddressSanitizer and MemorySaniziter. These normally find more types of errors (like use-after-return) and I find it significantly faster than Valgrind.

Valgrind also does stuff like memory tracking and memory-profiling, so this is great also from a performance tracking point of view.

Re: Go has added Valgrind support

#87

Post by stusmall »

tasn wrote: post #74

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

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.

Re: Go has added Valgrind support

#88

Post by stitched2gethr »

JyB wrote: post #83
tasn wrote: post #74

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

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.

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.

Re: Go has added Valgrind support

#89

Post by c2xlZXB5Cg1 »

frollogaston wrote: post #69
giancarlostoro wrote: post #28

Earlier quoted context omitted.

Good enough to be used by every major cloud provider, every time you download Google Chrome, and Android SDKs you pull from a standard library Go based HTTP server.

How do you know the Chrome downloads server specifically is written in Go?

https://go.dev/talks/2013/oscon-dl.slide#1

Re: Go has added Valgrind support

#90

Post by flkenosad »

JyB wrote: post #83
tasn wrote: post #74

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

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.

Religious wars. C is Judaism. Go/Rust/Python/Ruby are all the different sects of Christianity. AI is Islam.
Post reply on HN