Go's Sweet 16 • Hacker News Board

Re: Go's Sweet 16

#61

Post by Denzel » Sat, Nov 15, 2025, 3:52 AM UTC

synthetic-echo wrote: post #56

asa400 wrote: post #39

Earlier quoted context omitted.

> The nice thing about Go is that you can learn "all of it" in a reasonable amount of time This always feels like one of those “taste” things that some programmers tend to like on a personal level but has almost no evidence that it leads to more real-world success vs any other language. Like, people get real work done every day at scale with C# and C++. And Java, and Ruby, and Rust, and JavaScript. And every other la…

Just an anecdote and not necessarily generalizable, but I can at least give one example: I'm in academia doing ML research where, for all intents and purposes, we work exclusively in Python. We had a massive CSV dataset which required sorting, filtering, and other data transformations. Without getting into details, we had to rerun the entire process when new data came in roughly every week. Even using every trick to…

Did you try scipy/numpy or any python library with a compiled implementation before picking up Go?

Re: Go's Sweet 16

#62

Post by MagicMoonlight » Sat, Nov 15, 2025, 3:55 AM UTC

I just can’t get over the idiotic syntax.

Instead of “int x”

You have “var x int”

Which obscures the type, making it harder to read the code. The only justification is that 16 years ago, some guy thought he was being clever. For 99.99% of code, it’s a worse syntax. Nobody does eight levels of pointer redirection in typical everyday code.

Re: Go's Sweet 16

#63

Post by vips7L » Sat, Nov 15, 2025, 3:57 AM UTC

Xeoncross wrote: post #15

klodolph wrote: post #12

Earlier quoted context omitted.

> I don't see it. Can you say what 80% you feel like you're getting? I read it as “80% of the way to Rust levels of reliability and performance.” That doesn’t mean that the type system or syntax is at all similar, but that you get some of the same benefits. I might say that, “C gets you 80% of the way to assembly with 20% of the effort.” From context, you could make a reasonable guess that I’m talking about performan…

Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contain…

Go is in the same performance profile as Java and C#. There are tons of benchmarks that support this.

Re: Go's Sweet 16

#64

Post by MagicMoonlight » Sat, Nov 15, 2025, 3:59 AM UTC

ModernMech wrote: post #51

Oh wow, so it's already been 16 years since Google steamrolled the Go! language, which had existed a decade before Go and had every right to the name. This was when they were still pretending "do no evil" was their brand. There may be no honor amongst thieves but there is honor amongst langdevs, and when they did Go! dirty, Google made clear which one they are. Status changed to Unfortunate https://github.com/golang/…

Does anyone use that other language? No!

Re: Go's Sweet 16

#65

Post by dpe82 » Sat, Nov 15, 2025, 4:01 AM UTC

pkaye wrote: post #52

throw1111221 wrote: post #50

Earlier quoted context omitted.

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduc…

Doesn't Google use mostly C++?

It really depends on product area.

Re: Go's Sweet 16

#66

Post by zer00eyz » Sat, Nov 15, 2025, 4:02 AM UTC

cwbriscoe wrote: post #55

zer00eyz wrote: post #42

Earlier quoted context omitted.

I write a lot of Go, a bit of Rust, and Zig is slowly creeping in. To add to the above comment, a lot of what Go does encourages readability... Yes it feels pedantic at moments (error handling), but those cultural, and stylistic elements that seem painful to write make reading better. Portable binaries are a blessing, fast compile times, and the choices made around 3rd party libraries and vendoring are all just icing…

Error handling isn't even a pain to write any more with AI autocomplete which gets it right 95%+ of the time in my experience.

You're not wrong but... there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level.

I keep using the analogy, that the tools are just nail guns for office workers but some people remain sticks in the mud.

Re: Go's Sweet 16

#67

Post by captainkrtek » Sat, Nov 15, 2025, 4:03 AM UTC

Been happily working in Go since 2014. My career has spanned C, Python, C#, Ruby, and a smattering of other languages, but am always quite fond and preferential towards Go.

Re: Go's Sweet 16

#68

Post by piekvorst » Sat, Nov 15, 2025, 4:29 AM UTC

asa400 wrote: post #39

roncesvalles wrote: post #23

Earlier quoted context omitted.

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "part…

> The nice thing about Go is that you can learn "all of it" in a reasonable amount of time This always feels like one of those “taste” things that some programmers tend to like on a personal level but has almost no evidence that it leads to more real-world success vs any other language. Like, people get real work done every day at scale with C# and C++. And Java, and Ruby, and Rust, and JavaScript. And every other la…

> I’m not saying it’s wrong to have a preference for smaller languages, I just haven’t seen anything in my career to indicate that smaller languages outperform when it comes to faster delivery or less bugs.

I can imagine myself grappling with a language feature unobvious to me and eventually getting distracted. Sure, there is a lot of things unobvious to me but Go is not one of them and it influenced the whole environment.

Or, when choosing the right language feature, I could end up with weighing up excessively many choices and still failing to get it right, from the language correctness perspective (to make code scalable, look nice, uniform, play well with other features, etc).

An example not related to Go: bash and rc [1]. Understanding 16 pages of Duff’s rc manual was enough for me to start writing scripts faster than I did in bash. It did push me to ease my concerns about program correctness, though, which I welcomed. The whole process became more enjoyable without bashisms getting in the way.

Maybe it’s hard to measure the exact benefit but it should exist.

1: https://9p.io/sys/doc/rc.html

Re: Go's Sweet 16

#69

Post by ModernMech » Sat, Nov 15, 2025, 4:39 AM UTC

MagicMoonlight wrote: post #64

ModernMech wrote: post #51

Oh wow, so it's already been 16 years since Google steamrolled the Go! language, which had existed a decade before Go and had every right to the name. This was when they were still pretending "do no evil" was their brand. There may be no honor amongst thieves but there is honor amongst langdevs, and when they did Go! dirty, Google made clear which one they are. Status changed to Unfortunate https://github.com/golang/…

Does anyone use that other language? No!

That's not the point, no one uses 99% of languages, so if that's the standard then it's a free-for-all. The PL community is small, so norms are important.

PL naming code is:

1. Whoever uses the name first, has claim to the name. Using the name first is measured by: when was the spec published, or when is the first repo commit.

2. A name can be reused IFF the author has abandoned the original project. Usually there's a grace period depending on how long the project was under development. But if a project is abandoned then there's nothing to stop someone from picking up the name.

3. Under no circumstances should a PL dev step on the name of a currently active PL project. If that happens, it's up to the most recently named project to change their name, not the older project even if the newer project has money behind it.

4. Language names with historical notoriety are essentially "retired" despite not being actively developed anymore.

All of this is reasonable, because the PL namespace is still largely unsaturated*. There are plenty of one syllable English words that are out there for grabs. All sorts of animals, verbs, nouns, and human names that are common for PLs are there for the taking. There's no reason to step on someone else's work just because there's some tie in with your company's branding.

So it's pretty bottom basement behavior for luminaries like Ken Thompson and Rob Pike to cosign Google throwing around their weight to step on another dev's work, and then say essentially "make me" when asked to stop.

* This of course does not apply to the single-letter langs, but even still, that namespace doesn't really have 25 langs under active development.

Re: Go's Sweet 16

#70

Post by LexiMax » Sat, Nov 15, 2025, 4:41 AM UTC

MagicMoonlight wrote: post #62

I just can’t get over the idiotic syntax. Instead of “int x” You have “var x int” Which obscures the type, making it harder to read the code. The only justification is that 16 years ago, some guy thought he was being clever. For 99.99% of code, it’s a worse syntax. Nobody does eight levels of pointer redirection in typical everyday code.

16 years is a bit of an under-estimate. I think the first popular language with this form of declaration was Pascal.

    var
        foo: char;

Go was developed by many of the minds behind C, and inertia would have led them to C-style declaration. I don't know if they've ever told anybody why they went with the Pascal style, but I would bet money on the fact that Pascal-style declarations are simply easier and faster for computers to parse. And it doesn't just help with compile speed, it also makes syntax highlighting far more reliable and speeds up tooling.

Sure, it's initially kind of annoying if you're used to the C style of type before identifier, but it's something you can quickly get to grips with. And as time has gone on, it seems like a style that a lot of modern languages have adopted. Off the top of my head, I think this style is in TypeScript, Python type hints, Go, Rust, Nim, Zig, and Odin. I asked Claude for a few more examples and apparently it's also used by Kotlin, Swift, and various flavors of ML and Haskell.

But hey, if you're still a fan of type before variable, PHP has your back.

    class User {
        public int $id;
        public ?string $name;

        public function __construct(int $id, ?string $name) {
            $this->id = $id;
            $this->name = $name;
        }
    }