Hacker News Reader

Comment by throwawaaarrgh | Hacker News Reader

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 garbage collected, which can be good or bad depending on where you're using it (good because you can be super cavalier with memory, but bad because of stop-the-world pauses).

Rust IMO is much more advanced and expressive. It's a joy to write, makes you think and feel like a developer rather than an assembler that you can feel with Go. IMO it handles most of the common problems with languages well and has probably the best support for Web Assembly if that's your goal. It's not garbage collected, which is critical for systems programming. It is more complex than Go though and takes longer to master. Also, while it's growing rapidly, Rust also has fewer job openings compared to Go, if you're doing this for getting a job.

I think there's two ways people view programming: it's either a means to an end, or it's a fun pizzle trap. Personally I only care about getting the job done in the cheapest and most reliable way possible. There's lots of interesting problems when you think about the dynamics of distributed systems, improving developer velocity, etc. Trying to code golf a single method just isn't appealing to me, so I don't mind slapping together some Go and a good set of tests and calling it a day.

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 your language is "expressive". They want boring. Boring is good.

Rust is the new "I use Arch btw"

It really is.

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

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

Simply looking at the Resolve struct definition tells you.

    /// A map from packages to a set of their public dependencies
    public_dependencies: HashMap<PackageId, HashSet<PackageId>>,

I do agree with you that Rust is easier to read in an IDE though, since then those types gets autoresolved and hinted inline for you.

I have a completely diferente experience coming to go. It is simple and straight forward language to learn. Goroutine alone is a great feature.

> limited language features

That is by design and I like that. I was a C# developer and seem how C# has evolved, I'm glad that go keeps it simple.

> Lack of docs, broken and confusing functionality

Docs for me are just fine, never had a problem. Could you give an exemple of "broken and confusing functionality"? I really like the cli ux and the its std lib, it is really complete from my point of view, so I'm curious to hear from someone with another point of view.

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.

The number of flags required to statically compile stuff when using cgo is indeed a bit complex (if you're not using cgo it will always statically compile), partly because interfacing with C is a bit complex.

There is an issue to make it easier[1], and doesn't seem too hard to find more information about it[2].

More general: I think I've seen every language described as "badly documented" at this point. Someone new comes to the language, knows what they want to do, gets stuck/frustrated because it's a little bit outside the "mainstream path", and calls it "badly documented".

[1]: https://github.com/golang/go/issues/26492

[2]: https://duckduckgo.com/?q=go+compile+static

I honestly have no idea why so many hate the language but I guess the Bjarne Stroustrup rule applies.

For me it's a language I always wanted to have: essentially C with a GC, small enough you can carry it in your head with most of the footguns removed.

I honestly also have no idea why Rust always makes an appearance in a Go thread, I can't think of two languages with such a diametrically opposite learning complexity.

Simply because it's limiting. Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck. For some people it's this feeling of being stuck that they don't like - others can live with it more easily.

> I honestly also have no idea why Rust always makes an appearance in a Go thread

Both Rust and Go people are very vocal about their languages.

> Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck.

Ok, I get it that there are developers that can't live with languages that don't have tons of shiny features to play with, but please don't disparage the others as "inexperienced"! If you have ever gone back to some "expressive" code you wrote months/years ago while feeling very productive and were left wondering "WTF was I thinking when I wrote that? Can someone explain it to me?", then you start to understand the reasoning behind Go's simplicity.

It's not "shiny features". It's things that can make you more productive. Or would you say golang's channls are also a shiny feature?

Also, I'm not "disparaging" anyone here. Please read it again and notice that I was simply saying that golang is good if you are inexperienced. That does not mean that every golang dev is inexperienced. If you interpreted my post in that way, I think you should probably ask yourself why that is.

But you said:

> Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck.

which implies that people who use Go have not grown and become as productive as people that use more expressive languages (because such languages are a "must" to grow in this way). At the very least, you are obviously disparaging Go programmers' productivity.

> which implies that people who use Go have not grown and become as productive

That's not what it says, or at least not what I meant.

People are different and can accept a different amounts of repetitive work. Heck, there are even people who really like it and want to think as little as possible. So all I'm saying is that there exist people in Go that grow and then want to improve their productivity but are now restricted by the language.

And I think I have a point in the sense that Go is already adapting to those people by e.g. adding generics. So the number of those people can't be that small, otherwise I don't think they would follow their requests.

> because such languages are a "must" to grow in this way

And yeah, there are of course different ways to become more productive, e.g. through other kind of tooling, better organization etc. But the language is definitely one of our most important tools so if the language limits you then switching it is the only way to improve in this regards.

In fact, English is not my native language and I often feel limited in both my mother tongue and English. Sometimes I'd love to just mix the two but obviously I can't. It's the same thing, but natural languages are much closer to each in terms of expressivenes than programming languages are.

> At the very least, you are obviously disparaging Go programmers' productivity.

I'm saying that a developer who feels limited by golang can and will become more productive with a less restrictive language, all other things being equal(!).

So there are two categories of Go programmers in your opinion: (1) the beginners, who will eventually feel its limitations and will advance to a better language; and (2), those who don't mind repetitive work and want to think as little as possible, those will happily use Go until retirement. Still not really flattering, is it?

Common! My example of people who don't want to think at all was clearly not in the context of developers. I'm talking about factory workers or sometimes even office workers.

For golang there's certainly devs how just don't mind a certain amount of repetitive work and are happy to use Go until retirement. And I don't think that's a problem at all. People are different and I think we should embrace that. If you think being called a "factory worker" is not flattering, then that's more your personal judgement than me being objectively disregarding factory workers.

Again: Try to read my response in the right context. I'm explaining why some people dislike (or even hate) the language. It was a response. Please try to keep that in mind when you reply.

> Simply because it's limiting. Which is good if you are inexperienced, but not so great once you grow and try to become more productive. A more expressive language is a must then or you'll be stuck.

I've never been "stuck" with Go in the sense that I wasn't able to do something I wanted.

I've programmed in plenty of more expressive languages over the years, and I don't think there's much difference in terms of productivity. Sure, some more expressive languages allow you to do something very quickly and concisely, but it also increases cognitive load when writing and reading and in the end it seems to balances out. Sometimes I do find myself thinking "gosh, I wish I had $feature_x from $language_y" at times, but I have that with every language.

It's a "dumb" languages in that sense, I guess. Which is also why it's nice: you don't have to focus on the mechanics of what you're implementing, you just implement what you want, as per the "Zen of Python"; "There should be one – and preferably only one – obvious way to do it."

I have about 30 years of coding experience, try again. C++ to Python, C to Go. Often I want to get shit done and not marvel at how smart I am.

Seconded. I have been bitten far more often by too fancy abstractions then by not having more fancy abstractions in my tooling. And Go has quite a few fundamental ones, like first class functions and closures.

What's with the notion of "getting shit down" vs "being smart". I want to get shit done as well. And for me, an expressive proramming language helps me with that. Otherwise I would be using assembly. It really doesn't have to do anything with "being smart".

The language is limited, but I do not find it limiting.

Agreed, if anything I think the limitations actually help me get stuff done. No need to think how best to resolve something, just do it the obvious way and move along.

That's okay! You should use what you like. People are different, otherwise we would all use the same few languages.

If you can't learn Go, you're going to have a bad time with Rust.

I do c# in my day job, and so far Rust has been much easier to pick up than Go. Maybe it just happens to be more similar to c#, but given it can be used as a system level lang like c++ I've been very surprised how quick it can be picked up (at least for basic tasks).

Don’t be so sure. I found Go to be frustrating and difficult, but Rust has been a pleasure.

> Lack of docs

Are… you sure? Go has some of the best documentation. You can learn Go in one sitting with its tutorial. Not exactly sure I agree with you there.

> limited language features

This is where people lose me.

> Lack of docs, broken and confusing functionality, limited language features, bizarre operations.

You are painting with a pretty broad brush, can you provide a concrete example of these?

I don't know how applicable this is, but even the basic if-else syntax can hit you with hours of frustrating struggles. The parantheses have to be arranged in a specific way that was never mentioned in the online language specs over at go.dev, otherwise the code will fail:

    if (cond) {
         return x
    } else { 
         return y
    }

works, but

    if (cond) { return x }
    else { return y }

doesn't.

The reason it doesn't work is because of how semicolons work: like in C every statement needs to end in a semicolon, but the compiler will automatically insert them if the last word in a line is a keyword (continue etc.), an identifier, literal value (int, string, etc.), or ++, --, ), ], }. [1]

So your example gets transformed to:

  if (cond) { return x };
  else { return y };

So it is mentioned in the language specification, just as a non-obvious consequence of this.

It's not my most favourite part of the language either, but at least the compiler message on it is better now (it used to complain about semicolons, which was confusing because they're not there in your source code; now it just says "unexpected else, expecting }", which is still a bit confusing but better).

I'm fairly sure The Go Programming Language book mentions this somewhere near the beginning, but some of the online tutorial/tour perhaps could be improved. There's always a bit of a balance in how much to mention.

[1]: https://go.dev/ref/spec#Semicolons

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

To someone coming from C, C++, or Java, the idea that a newline would change the meaning is completely novel. And Go has the same "flavor" as those languages, so most people would expect Go to behave the same unless the difference were called out very explicitly.

I think the absence of semicolons is a pretty big call-out.

I think gofmt will fix this for you?

Reply on news.ycombinator.com