[Xeoncross]

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go.

It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them)

I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort.

[roncesvalles]

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 "partial method" or "generic delegate" means, and then keep reading that codebase if you still have momentum left.

[asa400]

> 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 language that programmers castigate as being huge and bloated.

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.

As an aside, I’d even go so far as to say that the main problem with C++ is not that it has so many features in number, but that its features interact with each other in unpredictable ways. Said another way, it’s not the number of nodes in the graph, but the number of edges and the manner of those edges.

[egl2020]

I've been writing go professionally for about ten years, and with go I regularly find myself saying "this is pretty boring", followed by "but that's a good thing" because I'm pretty sure that I won't do anything in a go program that would cause the other team members much trouble if I were to get run over by a bus or die of boredom.

In contrast writing C++ feels like solving an endless series of puzzles, and there is a constant temptation to do Something Really Clever.

[treis]

The tradeoff with that language simplicity is that there's a whole lot of gotchas that come with Go. It makes things look simpler than they actually are.

[kermatt]

> I'm convinced no more than a handful of humans understand all of C# or C++

How would the proportion of humans that understand all of Rust compare?

[morshu9001]

This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.

[jbreckmckye]

I learned Go this year, and this assertion just... isn't true? There are a bunch of subtleties and footguns, especially with concurrency.

C++ is a basket case, it's not really a fair comparison.

[throwaway894345]

I’ve been using Python since 2008, and I don’t feel like I understand very much of it at all, but after just a couple of years of using Go in a hobby capacity I felt I knew it very well.

[throw1111221]

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 reduce build times at Google. This is why unused dependencies are a compile time error.

https://go.dev/talks/2012/splash.article#TOC_6.

[the_gipsy]

> This is why unused dependencies are a compile time error.

https://go.dev/doc/faq?utm_source=chatgpt.com#unused_variabl...

> There are two reasons for having no warnings. First, if it’s worth complaining about, it’s worth fixing in the code. (Conversely, if it’s not worth fixing, it’s not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.

I believe this was a mistake (one that sadly Zig also follows). In practice there are too many things that wouldn't make sense being compiler errors, so you need to run a linter. When you need to comment out or remove some code temporarily, it won't even build, and then you have to remove a chain of unused vars/imports until it let's you, it's just annoying.

Meanwhile, unlinted go programs are full of little bugs, e.g. unchecked errors or bugs in err-var misuse. If there only were warnings...

[pa7ch]

I feel like people always take the designed for juniors thing the wrong way by implying that beneficial (to general software engineering) features or ideas were left out as a trade off to make the language easier to learn at the cost of what the language could be to a senior. I don't think the go designers see these as opposing trade offs.

Whats good for the junior can be good for the senior. I think PL values have leaned a little too hard towards valuing complexity and abstract 'purity' while go was a break away from that that has proved successful but controversial.

[ErroneousBosh]

> This is why unused dependencies are a compile time error.

I think my favourite bit of Go opinionatedness is the code formatting.

K&R or GTFO.

Oh you don't like your opening bracket on the same line? Tough shit, syntax error.

[pkaye]

Doesn't Google use mostly C++?

[zer00eyz]

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 on the cake.

That 80 percent feeling is more than just the language, as written, its all the things that come along with it...

[gf000]

Error handling is objectively terrible in Go and the explicitness of the always repeating pattern just makes humans pay less attention to potentially problematic lines and otherwise increases the noise to signal ratio.

[cwbriscoe]

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.

[Someone]

> Which makes sense, it's got the smallest language spec of any of them

I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-pr...: “The grammar described here is intended to help you understand the language in more detail, rather than to allow you to directly implement a parser or compiler.”)

(Also, browsing golang’s spec, I think I spotted an error in https://go.dev/ref/spec#Integer_literals. The grammar says:

  decimal_lit    = "0" | ( "1" … "9" ) [ [ "_" ] decimal_digits ] . 

Given that, how can 0600 and 0_600 be valid integer literals in the examples?)

[mseepgood]

You're looking at the wrong production. They are octal literals:

    octal_lit      = "0" [ "o" | "O" ] [ "_" ] octal_digits .

[neild]

0600 and 0_600 are octal literals:

    octal_lit      = "0" [ "o" | "O" ] [ "_" ] octal_digits .

[j-scott]

My original comment was incorrect. These are being parsed as octals, not decimals: https://go.dev/play/p/hyWPkL_9C5W

[tptacek]

I don't understand the framing you have here, of Rust being an asymptote of language capability. It isn't. It's its own set of tradeoffs. In 2025, it would not make much sense to write a browser in Go. But there are a lot of network services it doesn't really make sense to write in Rust: you give up a lot (colored functions, the borrow checker) to avoid GC and goroutines.

Rust is great. One of the stupidest things in modern programming practice is the slapfight between these two language communities.

[throw-the-towel]

Unfortunately, it's the remaining 20% of Rust features that provide 80% of its usefulness.

[morshu9001]

Language can be bottleneck if there's something huge missing from it that you need, like how many of them didn't have first class support for cooperative multitasking, or maybe you need it to be compiled, or not compiled, or GC vs no GC. Go started out with solid greenthreading, while afaik no major lang/runtime had something comparable at the time (Java now does supposedly).

The thing people tend to overvalue is the little syntax differences, like how Scala wanted to be a nicer Java, or even ObjC vs Swift before the latter got async/await.

[ezst]

I'll be the one to nickpick, but Scala never intended to be a nicer Java. It was and still is an academic exercise in compiler and language theory. Also, judging by Kotlin's decent strides, "little Syntex differences" get you a long way on a competent VM/Runtime/stdlib.

[throwaway894345]

Similar story for me. I was looking for a language that just got out of the way. That didn’t require me to learn a full imparable DSL just to add a few dependencies and which could easily produce some artifact that I could share around without needing to make sure the target machine had all the right dependencies installed.

[baby]

It really is a lovely language and ecosystem of tools, I think it does show its limitations fairly quickly when you want to build something a bit complex though. Really wish they would have added sumtypes

[Thorrez]

Go is getting more complex over time though. E.g. generics.

[osigurdson]

>> I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort.

By 20% of the effort, do you mean learning curve or productivity?

[benjiro]

Funny thing is that also makes it easier on LLM / AI... Tried a project a while ago both creating the same thing in Rust and Go. Go's worked from the start, while Rust's version needed a lot of LLM interventions and fixes to get it to compile.

We shall not talk about compile time / resource usage differences ;)

I mean, Rust is nice, but compared to when i learned it like 10 years ago, it really looks a lot more these days, like it took too much of a que from C++.

While Go syntax is still the same as it was 10 years ago with barely anything new. What may anger people but even so...

The only thing i love to see is reduce executable sizes because pushing large executables on a dinky upload line, to remove testing is not fun.

[tialaramex]

> I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort.

I don't see it. Can you say what 80% you feel like you're getting?

The type system doesn't feel anything alike, I guess the syntax is alike in the sense that Go is a semi-colon language and Rust though actually basically an ML deliberately dresses as a semi-colon language but otherwise not really. They're both relatively modern, so you get decent tooling out of the box.

But this feels a bit like if somebody told me that this new pizza restaurant does a cheese pizza that's 80% similar to the Duck Ho Fun from that little place near the extremely tacky student bar. Duck Ho Fun doesn't have nothing in common with cheese pizza, they're both best (in my opinion) if cooked very quickly with high heat - but there's not a lot of commonality.

[klodolph]

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

[NoboruWataya]

I guess the 80% would be a reasonably performant compiled binary with easily managed dependencies? And the extra 20% would be the additional performance and peace of mind provided by the strictness of the Rust compiler.

[password4321]

Single binary deployment was a big deal when Go was young; that might be worth a few percent. Also: automatically avoiding entire categories of potential vulnerabilities due to language-level design choices and features. Not compile times though ;)

[kace91]

Wild guess but, with the current JS/python dominance, maybe it’s just the benefits of a (modern) compiled language.