[cejast]

Go and it’s standard library. ‘Elegant’ is pretty subjective, but it’s a treasure trove of learning how things work under the hood. I’ve learned loads about networking, compression, encryption and more by browsing through it, because the code is super easy to read and understand.

[earthling8118]

What makes it easy to read and understand though? I am seriously having a hard time figuring this out. People tout Go for this all the time, but I don't know of a single codebase in it that I think fits that description. When I look through them they look convoluted and just sort of messed up. Things like awkward error handling, dealing with null, capitalization for public/private, magic functions, and imports, and much, much more all add up and make me abhor the language. I don't think it's good or easy to use at all, but people rave about it.

[abatilo]

Speaking for myself, the language itself is simple. There aren't a lot of features, which means you do have to write more and it's more verbose, but learning the entirety of the language's features is very easy to do.

Even with the relative magic of things like init functions that execute on import, there's so much less magic that you have to consider.

IMO it's the easiest to jump into for this reason. Yes, the code itself might be excessive, but reading Go is as simple as can be.

[ericbarrett]

I'll echo this. When I'm looking at a Go codebase that somebody else wrote, it's a minimal effort to understand what it does. Rarely, if ever, do I scratch my head at a particularly clever type derivation or obscure language feature; macros are pretty much non-existent; even user-defined types are easily reduced by the IDE and language server. Patterns are standardized and yes, it's verbose, but predictably so. If something calls for containerization, it's dead simple. Go is a language for getting things done straightforwardly.

I know it's not everybody's cup of tea, and that's fine. There's room for different languages in the world. But I'm knocking out useful utilities that make a difference for my team and business in days or hours, and supremely uninterested in code golf, so I don't personally agree with the criticisms.

[michaelcampbell]

> People tout Go for this all the time

What gets me about go is 2 things.

Its touted as being so easy that a junior dev can pick it up easily; it's targeted towards average developers. Fine, this is a virtue; when Java said the same thing, it's a horrifying blight.

The other is that people seem to mistake motion for action. "The code flies from my fingers" is one way I've heard it said. And, sure, you have the same error catching boilerplate (which again, in go is a virtue but other languages seems to be considered a sin) 1000x, as if the clicky-clicky of the keyboard is some measure of productivity.

It's got a big "blub paradox" thing going, to my eyes. I don't find it elegant at all, or maybe I mean not very expressive.

Taken ad absurdum, I have a language that only adds 1 to a variable. I can understand that language in milliseconds. But I can't do much with it. Maybe go hits a good balance, I dunno, but I found it quite tedious.

[teeray]

It’s the complete lack of magic. What you see in front of you is pretty much exactly what happens. You don’t have to keep a cathedral of language semantic subtleties in your head when reading someone else’s code.

[rochak]

Pointer vs value receivers and named returns have so many gotchas that it is not even funny. Lack of magic my ass.

[teeray]

The way you avoid these are twofold:

1) Use the pointer receiver unless you have a really good reason to do otherwise.

2) Never, ever use named returns. Code can (and should) always be written to not use them.

[ssd532]

Can you elaborate point 2, please?I am wondering how is that related to the issue of pointer and value semantics.

[asylteltine]

Can you name any? I have never seen a “gotcha” because it’s just explicit… it’s not like you are surprised by a pointer.

[kaba0]

Then why don’t we go back to assembly? There is even less magic there, every line is trivial to understand, isn’t it?

[quaintdev]

I love Go. I think it depends on what trajectory you followed to reach to Go or any other language. For me it was

BASIC -> VB -> Java -> Python for some time -> Go

How you feel about Go is how I feel about JavaScript

[BrandoElFollito]

I went Pascal, C, Perl, Python, Go

And I like Typescript to some point.

I do not think they languages are mutually exclusive (on the like scale). But I am just an amateur hobbyist dev.

[asylteltine]

That’s because JavaScript is an awful language and I just don’t understand why people keep insisting on using it for everything. It even infected infra as code.

[asylteltine]

That’s because it is easy to use. Maybe you use too much python or Java but go was designed to specifically allow people to memorize the entire syntax, truly.

Want to make a function or variable or field public? Just capitalize it. That’s it.

Error handling? Check if the error isn’t nil and handle it, otherwise move on. No need for silly things like try except.

And there are no magic functions because everything is explicit.

Go is just simple and pleasant to use.

[tesdinger]

Try except isn't silly it shortens the code a lot. An exception can simply break out of a function, checking for error requires an explicit check at every line of the function and an added return statement to get out of the function.

[gravypod]

(Opinions are my own)

At my employer we use a subset of C++ and we use Go. We have a process by which when you write code others have to review it and you need to have a review by someone who is an "expert" [0] in the language [1]. You become an "expert" by being ordained by a shadowy committee who reviews code you submit to the code repository. They look for knowledge of the core language, how this language is used within the company, the external and internal libraries, performance, testing, etc. There are many factors and if you demonstrate all of them you get marked as being this type of "expert."

Before I joined this company I had written code which was launched into production in the following languages: Java, PHP, C, C++, assembly (arm + x86), Python, JavaScript (browser + node), and a few more. I would consider myself about average in all of these. I did not write any golang.

After I joined my current job I obtained this "expert" bit for both C++ and Go. It took ~1.5 years to get the C++. It took ~3-5 months for Go.

You can actually see the first golang code I wrote (this was at home when I was experimenting with the language before convincing some team members we should rewrite some of our infra in go): https://github.com/gravypod/gitfs

It has all sorts of mistakes but I didn't read any guides. I just used https://cs.opensource.google to search for examples of things that I thought I would need to do (ex: "how do I do a switch statement").

For C++ I had worked on ~2 projects that used it. My first few PRs were very rough and I had a lot of performance issues that crept into my code. If I didn't already have a lot of C experience I would have also had a bunch of pointer/lifetime stuff the reviewers would have found (I know this from reviewing new team members first lines of C or C++).

I know that to some C++ represents a literal worst case but most people coming from C++ to Go will think it's amazing because it removes all of the common footguns.

> Things like awkward error handling

Yes, it is very clunky and annoying but it's very simple. It's just a normal if statement and doesn't use any special language rules. I think this would still be better if there was dedicated syntax for it (something like throw/try/catch which works the same way but gives it a different syntax) but honestly I don't think it's as bad as it's made out to be. It's basically a "less bad" errno and that worked go-... dece-... ehm fine for many years.

> dealing with null

I've never really had to think about this too much. There are some times it is important but I rarely return nullable things without errors and it hasn't bitten me yet. My code is not provably correct but for the things I'm working on I don't need that guarantee. If I did I'd probably switch to Rust or something with better type safety.

> capitalization for public/private

Yea, this sucks but it doesn't really get in my way much. I don't like it but it isn't actively hurting my usage.

> magic functions

Like `String()`? I don't know if that's the worst think in the world. Python, C++, and Java have things like this.

> and imports

It's not been too bad for me. What I think is unfortunate is that the package of something is unconnected to where it is in most go usages which is annoying but it makes things more terse. This does actually hamper my productivity.

> I don't think it's good or easy to use at all, but people rave about it.

It's pretty easy to use because all of the libraries I've seen share common interfaces for behavior. This makes things feel a lot more cohesive. fuse-go and billy was very easy to use in gitfs because of this.

[0] - This is not an expert as in "knows everything" but more like "has been seen to consistently write efficient, simple to understand, idiomatic code." It basically means that when someone else from this subset of SWEs reviews your code they often do not have many comments. Again, I want to stress, this is not expert as in "knows everything" just as in "good enough".

[1] - https://abseil.io/resources/swe-book/html/ch03.html#what_is_...

[kaba0]

Well, c++ is literally the most complex language, famously not even Stroustrup would say he knows the whole, so comparing go to that hardly makes it look good.

[cpach]

Is there any programming language that is universally seen as objectively good?

[blowski]

No, because the different trade-offs they make all have costs and benefits. For example, C’s precise memory management can give better performance compared to PHP, but also requires more expensive programmers to work with it. If all you’re doing is a simple CRUD system, C’s power would be counter-productive, so PHP is a “better” language in that context.

So a “good” language depends on what you’re trying to do with it.

[epiccoleman]

I remember with smug satisfaction a time that I was able to settle a pedantic argument from a so called "security expert" by pasting the code from the library function he was questioning.

Very satisfying to be able to say "nope, it's fine, here's the source".

[speedgoose]

I find the Golang standard library code annoying to read and understand because of their use of single letter variables or very short abbreviations. I know some people like this but I don’t.

[superq]

The single letter variable is only supposed to be used within a relatively short function or code block. They should be relatively obvious; I personally find this to work well, but I can understand where sometimes it wouldn't be clear what the author was referring to.