[tasn]

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.

[JyB]

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.

[tasn]

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.

[9rx]

> and are more directly comparable than e.g. Go and Ruby

Why do you say that? The original Go announcement made it abundantly clear that it was intended to be like a dynamically-typed language, but faster. It is probably more like Python than Ruby, as it clearly took a lot of ideas from Python, but most seem to consider those languages to be in the same hemisphere anyway.

Beyond maybe producing complied binaries, which is really just an implementation detail, not a hard feature of the language, what is really comparable with Rust?

[cyphar]

Go was sold as a "systems language" for a long time, and a lot of people deciding on what language to use in the 2010s made decisions based on that bit of advertising. Rust filled the same niche at around the same time so it's not really surprising people would mentally connect the two.

FWIW, I suspect the entire container ecosystem would not have gone with Go if it wasn't for Docker picking Go mostly based on the "systems language" label. (If only they knew how painful it would be...)

To be clear, I use both and like them for different reasons. But in my experience I agree that Go and Rust are far closer brethren than Go and Python. A lot of the design nexus in Go was to take C and try to improve it with a handful of pared down ideas from Java -- this leads to a similar path as the C++-oriented design nexus for Rust. Early Rust even had green threads like Go. They are obviously very different languages in other respects but it's not particularly suprising that people would compare them given their history.

Your later comments about lots of Go users coming from Python is not particularly surprising and I don't think actually helps your point -- they wanted to improve performance so they switched to a compiled language that handles multithreading well. I would argue they moved to Go precisely because it isn't like Python. If Go didn't exist they would've picked a different language (probably Rust, C++, or any number of languages in the same niche). Maybe if there was a "Python-but-fast" language that they all switched to you would have a point, but Go is not that language.

[9rx]

> Go was sold as a "systems language" for a long time

Still is, but it was also made abundantly clear at the time that those systems were things like network servers specifically. It was even later noted that the team was somewhat surprised that people found uses elsewhere. I do recognize this confused the Rust crowd, who bizarrely think that sum types are known as enums, and think that systems are programs that run on raw hardware (think kernels, embedded software, etc.). But nobody else randomly redefines every word they come across.

In the standard nomenclature, systems are the "opposite" of scripts. Scripts being programs that carry out a single task and then exit upon completion, as opposed to a long-running program that continually carries out (possibly a variety of) tasks. If Go isn't a systems programming language then we can conclude that it is a scripting language. But I've never heard of anyone calling it a scripting language... As far as I can tell, the world generally agrees that Go is a systems language.

And yes, this is where I would agree that Rust and Go are more similar, both being geared towards building systems (although not necessary the same type of systems). Python and Ruby are decidedly geared more towards scripting tasks. But, of course, that doesn't mean you can't build scripts in Go and Rust and systems in Python and Ruby. People were definitely trying to write systems in Python in Ruby.

> I suspect the entire container ecosystem would not have gone with Go if it wasn't for Docker picking Go mostly based on the "systems language" label.

Makes sense. The container ecosystem (Docker, Kubernetes, etc.) was originally built as (and for) network servers — the exact niche Go was designed for. I think you make a good point that they've grown to be so much more, to the point that the network bits are hardly even relevant, but if we could erase these tools and the term "systems language" from memory and start over to solve primarily for the pain points associated with running network servers again, I'm not sure you've made a good case that they wouldn't still land on Go. I get why you say that in hindsight, but these projects didn't have hindsight when they were being first created.

> A lot of the design nexus in Go was to take C and try to improve it with a handful of pared down ideas from Java

That runs counter to the claims of the Go team, who explicitly stated that their goal was to make a fast 'dynamically-typed' language. Obviously they introduced a type system so that the compiler could optimize on known primitive types, so it is not truly dynamically-typed, but it is also obvious that the type system doesn't extend beyond what is necessary for the sake of performance and what was necessary to maintain a dynamically-typed 'feel' around that, much to the chagrin of type theorists.

You are quite right that it does share a lot of commonality with C — they were conceived by the same guy, after all! But, given the goal of being "faster" that makes sense. Modern CPUs are literally designed for C. I'm not sure where Java fits. Limbo I can see. Is that what you meant? Java and Limbo were both created at the same time. Perhaps you've somehow managed to conflate them because of that? A lot of people do suggest that Go and Rust are oft considered similar simply because they were created around the same time.

The Java team did warn the Go team to not to screw up implementing generics like they did. Maybe that's where you got Java in your mind? But the warning was heeded. The generics design Go got is quite different. Or maybe you are thinking of Kubernetes originally being written in Java and being criticized for carrying many of those Java-isms into the Go rewrite?

> they wanted to improve performance so they switched to a compiled language that handles multithreading well.

...while, most importantly, sticking to something that was familiar. Perhaps you have already forgotten, but they also evaluated Rust at the time. "It is too hard to learn", they concluded. A bit overdramatic, sure, but when you read between the lines there was a valid point in there — that Rust wasn't like the tools that were commonly used before it.

Go was. The only somewhat unique thing it brought to the table was goroutines, but even that was simply taking what people were already doing with libraries in Ruby and Python (Twisted, EventMachine, etc.) and formalizing it as part of the language. It wasn't a different way of thinking, just syntax sugar.

And this is why I ultimately conclude that Go is more like Python and Ruby than it is Rust. More so Python, granted. Ruby's message passing model leads to some different conventions. Put the code for a Python program and a Go program side by side, squint slightly, and you aren't apt to be able to even see a difference. Especially if that Python program actually sticks to the Zen of Python. Put a Python program beside a Rust program and they are going to be completely different animals.

So, the original comparison was Go and Ruby, not Go and Python. As mentioned, Go is less like Ruby than it is like Python. To establish Go is more like Ruby we are operating on the premise that Python is more like Ruby than it is Rust, which I posited was the prevailing view. But maybe you disagree and that is where the contention lies? If that’s the case, why do you see Python as being more like Rust than Ruby?

[cyphar]

> I do recognize this confused the Rust crowd, who bizarrely think that sum types are known as enums, and think that systems are programs that run on raw hardware (think kernels, embedded software, etc.). But nobody else randomly redefines every word they come across.

I was not a Rust developer in 2013 and I still had the same impression. I think that most C developers (which is what I was primarily at the time) would interpret "systems language" to mean "loosely equivalent to C or C++" in that you have a lot of low-level control over what your program does (which usually means you can write operating systems with it, though I don't think that's necessarily a requirement). Go does not fit that bill.

To be honest, I've always felt the Go folks redefined the word and not the other way around. Are web servers very important? Of course, but a programming language intended primarily for performant web servers is not a "systems language". Maybe this usage of the term is a Google-ism that escaped containment. You can probably find comments from me throughout the 2010s bemoaning this (mis)use of the word.

Funnily enough, Russ Cox himself said in 2014 that he "slightly regrets" calling Go a systems programming language because it leads to confusion[1]. There was another panel talk from a long time ago (sadly, I can't find a video of the talk at the moment) where another Go language developer said that a systems programming language is a language that has pointers and allows typecasting of pointers (more specifically, one where you can create a memory allocator) which always seemed like a very low bar to me.

[1]: https://youtu.be/ZQR32nTVF_4?t=408

> Makes sense. The container ecosystem (Docker, Kubernetes, etc.) was originally built as (and for) network servers — the exact niche Go was designed for.

I don't think that's at all accurate. Docker originally needed to do a heck of a lot of core system operations, which it turns out are very annoying to do in Go (I maintain runc, which inherited most of this code -- it's really not fun). Yes, Docker has a HTTP API, but I don't think of it is as being primarily a network server. And whether the process you run is a web server is not incredibly relevant -- most of the heavy lifting for containers is done by the kernel once you've set everything up.

(Of course the first versions of Docker just used LXC so it was slightly less painful but once they started developing libcontainer -- which is around the time I started working on Docker -- the real pain-points with Go started emerging.)

> The Java team did warn the Go team to not to screw up implementing generics like they did. Maybe that's where you got Java in your mind? But the warning was heeded. The generics design Go got is quite different. Or maybe you are thinking of Kubernetes originally being written in Java and being criticized for carrying many of those Java-isms into the Go rewrite?

This is from more than a decade ago now, but I remember that the Russ Cox in particular had a talk about Go's interfaces and my impression of the talk was that he made several references to Java and that they were trying to find a better model than Java's inheritance system while still solving the same problems. Maybe I'm overstating the impact it had (and maybe it was more a case of talk being tailored to a particular audience) but my impression was that interfaces were an attempt to solve something that Java folks wanted but without all of the issues the Java design has. Generics came much later and I think that everyone was unhappy with the result (though thankfully they have slowly become more erognomic, even if in my experience they are still only really useful for utility functions).

I never got the impression that Python was an explicit source of design ideas for Go. Yes, they were all Google people and so all of them were very familiar with Python use in production, but I just don't see it. Maybe you could argue the "batteries included" thing is Python-esque but that's about it.

Also Borg (Google's internal predecessor to Kubernetes) was written in C++[2], not Java. Kubernetes was also always written in Go (again, because Go had become the "container language" due to Docker).

[2]: https://dl.acm.org/doi/pdf/10.1145/2741948.2741964 "All components of Borg are written in C++."

>Perhaps you have already forgotten, but they also evaluated Rust at the time. "It is too hard to learn", they concluded.

Who is "they"? For the Docker example, my memory is that they later said they looked at Rust at the time but it wasn't 1.0 yet in 2012 and so it was a moot point. I think the only other language they seriously considered was C++ and they decided Go would be easier.

> And this is why I ultimately conclude that Go is more like Python and Ruby than it is Rust. More so Python, granted. Ruby's message passing model leads to some different conventions. Put the code for a Python program and a Go program side by side, squint slightly, and you aren't apt to be able to even see a difference. Especially if that Python program actually sticks to the Zen of Python. Put a Python program beside a Rust program and they are going to be completely different animals.

Well, I agree that Go is more like Python than Rust is like Python (though Rust has better support for some of the functional things in Python than Go and there are small things like format strings that are also very similar, but on the whole I would generally agree). But that is an entirely separate question as to why Go and Rust are often compared to one another. In my experience the comparison is not focused on surface-level syntax but is instead about what purpose it serves (this is like the difference between comparing bats, birds, and flying fish to comparing barnacles and shrimp).

That being said, the fact that it is basically impossible to stop the GC from closing the underlying file descriptor of an *os.File (necessitating dup(2) when you're working with libraries that don't like that) is very Python-esque (no, runtime.SetFinalizer doesn't work). You would be surprised with how many times I've run in this issue...

[wavemode]

I don't think this is correct. Go is a language with structs, arrays, value semantics and pointers, and an `unsafe` package for performing low-level operations on those pointers and deal directly with the layout of memory. And in practice Go and Rust have found use in a lot of the exact same systems programming and network programming domains, as replacement languages for C.

Go is certainly a higher-level language than C, but to say it's at all similar to Python or Ruby is nonsensical.

[9rx]

> Go is a language with structs, arrays

Just like Ruby. Just like pretty much every language people actually use.

> value semantics and pointers

Value semantics are one of the tricks it uses to satisfy the "but faster" part. It is decidedly its own language. But it only supports value semantics, so this is more like Ruby, which only supports reference semantics. Rust supports both value and reference semantics, so it is clearly a very different beast.

> and an `unsafe` package for performing low-level operations on those pointers

The Ruby standard library also includes a package for this.

> And in practice Go and Rust have found use in a lot of the exact same systems programming and network programming domains, as replacement languages for C.

Maybe in some cases, but the data is abundantly clear that Go was most adopted by those who were previously using Ruby and Python. The Go team did think at one point that it might attract C++ programmers, but they quickly found out that wasn't the case. It was never widely adopted in that arena. Whereas I think it is safe to say that many C++ programmers would consider Rust. Which makes sense as Rust is intended to play in the same ballpark as C++. Go was explicitly intended to be a 'faster Python'.

> but to say it's at all similar to Python or Ruby is nonsensical.

Go is most similar to Go, but on the spectrum is way closer to Python and Ruby than it is Rust. It bears almost no resemblance to Rust. Hell, even the "Rustacians'" complaint about Go is that it is nothing like Rust.

[pjmlp]

What?

Here is Rob Pike blog post about instead of getting C and C++ developers, they got the dynamic language folks.

https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

[9rx]

You hit the wrong reply button. It was the sibling comment that thought that Go attracted C developers.

[pjmlp]

Not at all.

[TinkersW]

You should see the C++ threads

[stitched2gethr]

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]

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.

[hu3]

Rust is, in my opinion, overrepresented by a vocal minority in HN. A vocal corpus that tend to be passive aggressive more often than other language communities, in my experience.

Which is sad because I like the language and find it useful. But a part of the community does a disservice with comments like your parent comment. It's often on the cusp of calling people who code in Go "stupid". But I digress.

[flkenosad]

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

[bracewel]

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

[tasn]

Oh, interesting. Thanks for sharing!

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

[chrsig]

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

[stusmall]

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.

[pjmlp]

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]

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

[9rx]

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

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.

[9rx]

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?

[pjmlp]

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.