Live data from Hacker News

Thirteen Years of Go

go.dev

61–70 of 217 posts

Re: Thirteen Years of Go

#61

Quoted post unavailable.

I've been coding professionally in Go and have recently switched largely to Rust. I feel Go is designed for junior developers: it's easy to get started, like with Python, but comes at the cost of verbosity and lack of expressiveness. E.g., you'll have to live with "if err != nil" all over the place. It's good for orgs though because code written by different people looks the same and readable. Most importantly, it's…

> Rust IMO is much more advanced and expressive. It's a joy to write [...]

Maybe, but is it also a joy to read?

Re: Thirteen Years of Go

#62
post #45

Earlier quoted context omitted.

> never mentioned in the online language specs over at go.dev hmm, what's this then? https://go.dev/doc/faq#Does_Go_have_a_ternary_form

That's the FAQ. The official Language Specification says nothing about this little gimmick, at least in the if-else section: https://go.dev/ref/spec#If_statements You'd think one would want to look for it in that instead of an FAQ page.

If you looked at the spec which provides simple, valid examples that work, then why would you spend hours writing different code wondering why it doesn’t work?

The section you linked does explain it, btw.

  IfStmt = "if" [ SimpleStmt ";" ] Expression Block [ "else" ( IfStmt | Block ) ] .
Note there is no newline or semicolon between Block and the optional “else” clause, and a Block is thusly defined:

  Block = "{" StatementList "}" .
So that being the case I’m not sure why you’d assume it’s valid to put a newline after the trailing “}” of the Block, before the “else”.

The other factor at play here is the treatment of semicolons: https://go.dev/ref/spec#Semicolons

All of this is quite natural once you use the language. in fact, it was designed this way in response to the way it was being used.

It is not appropriate for the spec to constantly reiterate concepts that have already been introduced, but rather it should precisely define each concept once. If you want to learn a language from its spec then it behooves you to consider the document as a whole. That requires a lot of mental overhead and I think most people are better off learning from examples and tutorials rather than reading a language spec.

Re: Thirteen Years of Go

#63

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

Agree on all points.

I'd like to add that it just tends to not punch you in the balls. I originally picked it up trying to solve a simple web hook integration problem. I had a Python Flask app running which received a webhook, did some data transformation and did a POST to an API. After spending a whole morning pissing around trying to get uWSGI, systemd via ansible etc working I went for lunch. Came back, learned enough Go and had it working in a single binary with systemd unit before the end of the day without any 3rd party packages, server mechanisms, dependency management, futzing. It just worked. The same code has been moved into docker, then into kubernetes over the last few years with no change, no bugs and no headaches.

Re: Thirteen Years of Go

#64

Quoted post unavailable.

I've been coding professionally in Go and have recently switched largely to Rust. I feel Go is designed for junior developers: it's easy to get started, like with Python, but comes at the cost of verbosity and lack of expressiveness. E.g., you'll have to live with "if err != nil" all over the place. It's good for orgs though because code written by different people looks the same and readable. Most importantly, it's…

> bad because of stop-the-world pauses

Have you actually experienced this to be a problem in the last half decade with Go? GC pauses in modern Go programs are short enough to be negligible in almost any practical program.

Re: Thirteen Years of Go

#65
Go has almost everything going for it. I only wish it was a bit more C-like and you had the ability to run it without a garbage collector, and that it was more suitable for systems and embedded programming.

Perhaps one day someone will come up with an implementation of Go that doesn’t use a GC.

It’s just such an incredible language, and it deserves the type of Rust fanaticism that Rust has, but I suspect Go users are just a different type of person and we really are fanatics, we just don’t publicize it.[1]

[1]: https://survey.stackoverflow.co/2022/#most-popular-technolog...

Re: Thirteen Years of Go

#66
post #46

Quoted post unavailable.

I don't think they do, but with Go which is indeed a simple language, the focus is on letting developers build abstractions rather than providing them in the form of opinionated language features.

And that is, in particular with an eye on performance, usually the right call. One of the worst traps in modern programming is rather than people building specific abstractions tailored to their own needs organically, starting out with them and trying to impose language features on a problem.

Re: Thirteen Years of Go

#67
post #61

Earlier quoted context omitted.

I've been coding professionally in Go and have recently switched largely to Rust. I feel Go is designed for junior developers: it's easy to get started, like with Python, but comes at the cost of verbosity and lack of expressiveness. E.g., you'll have to live with "if err != nil" all over the place. It's good for orgs though because code written by different people looks the same and readable. Most importantly, it's…

> Rust IMO is much more advanced and expressive. It's a joy to write [...] Maybe, but is it also a joy to read?

Seriously. I think Rust has a lot going for it, but I will say this: the type inference in Rust combined with its expressive type system can make sophisticated programs very hard to follow. My experience was with extensively reading the cargo codebase; trying to figure out what the resulting type of an expression that maps/filters/collects over other complex expressions is a chore.

For example, I find it very hard to figure out what the type of public_dependencies is in this declaration: https://github.com/rust-lang/cargo/blob/8fbc8459d59f3acecdb6...

This is the same kind of thing that makes JavaScript challenging to read. It requires a lot of discipline on the author’s part to make it clear what is going on, and even the best of us lack discipline at scale.

Re: Thirteen Years of Go

#68

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are in…

Go has been an acquired taste for me. I still don't love its syntax but the tooling and interesting combination of properties (GC, compiles to a binary, strongly typed) are what ultimately won me over.

It's perfect for middleware, APIs and CLI tools.

Re: Thirteen Years of Go

#69
post #34

Earlier quoted context omitted.

I've been coding professionally in Go and have recently switched largely to Rust. I feel Go is designed for junior developers: it's easy to get started, like with Python, but comes at the cost of verbosity and lack of expressiveness. E.g., you'll have to live with "if err != nil" all over the place. It's good for orgs though because code written by different people looks the same and readable. Most importantly, it's…

What is it with people who love Rust? If a language is not an absolute behemoth, it's a kid's language. Do you feel the same way about Lua? Like, this notion is wild to me. > Rust IMO is much more advanced and expressive. It's a joy to write It can be argued that in a professional setting, this isn't what a business cares about. Businesses care about getting stuff done, not whether you like to write your code and you…

[deleted]

Re: Thirteen Years of Go

#70

Quoted post unavailable.

Go is the best documented ecosystem I've seen. Since godoc is so widespread, people write doc comments and examples all the time. Every single public project has a doc page at pkg.go.dev too. The syntax rules and the reference spec of the language is very concise too.

Then you clearly have been living with some crap ecosystems. Go is very poorly documented. Basic functionality that is hidden behind environment variables isn't documented at all sometimes. Just figuring out how to compile an app statically took searching through four docs and guessing. The build and install options don't even result in a binary half the time and its not clear why.
Post reply on HN