Live data from Hacker News

I want off Mr. Golang’s Wild Ride (2020)

fasterthanli.me

31–40 of 477 posts

Re: I want off Mr. Golang’s Wild Ride (2020)

#31

To say go's simplicity is a lie, then to go and and say this; > This function signatures tells us a lot already. It returns a Result, which means, not only do we know this can fail, we have to handle it. Either by panicking on error, with .unwrap() or .expect(), or by matching it against Result::Ok / Result::Err, or by bubbling it up with the ? operator. What the hell? I'm not a rust dev. I have no idea what half of…

What's your argument? The point the article is making is that Go says it's simple, but isn't, while Rust doesn't say that it's simple, and uses its complexity to solve the complex problem.

Bubbling up means returning the error to the caller, and is general error handling jargon.

Re: I want off Mr. Golang’s Wild Ride (2020)

#32
post #8

Earlier quoted context omitted.

This submission came up because the article author is on twitter today complaining about golang and posted the submission link.

So they wanted out in 2020 and they’re still on in 2022. So either the language isn’t really that bad or they have an attention deficit?

Eh, plenty of people get stuck using technologies they hate.

Perhaps the OP is forced to use it for work, or already put the time and effort into building something and cannot afford to rebuild it from scratch.

Re: I want off Mr. Golang’s Wild Ride (2020)

#33
post #9

My Anecdotal Experience: Golang is great for spinning up new services and tools with very little overhead, the language is well designed for the backend - and the lack of avoids "odd" decisions which other engineers will dislike in the future. If your job is building lots of new things using relatively common building blocks, then Golang looks fantastic! However on mature services, engineers often need because they a…

Seems too many devs use go for something it is not meant for. Tried doing math calculations in go - not a good a idea. But for backend stuff like rest api, web servers, networking, sysadmin and devops tasks, it shines.

Re: I want off Mr. Golang’s Wild Ride (2020)

#35
post #29

To say go's simplicity is a lie, then to go and and say this; > This function signatures tells us a lot already. It returns a Result, which means, not only do we know this can fail, we have to handle it. Either by panicking on error, with .unwrap() or .expect(), or by matching it against Result::Ok / Result::Err, or by bubbling it up with the ? operator. What the hell? I'm not a rust dev. I have no idea what half of…

"Bubbling up" is the default in C++, when the code you call throws an exception and you don't have a try/catch for it.

Do C++ people actually call it "bubbling up"? I don't think I've used a language where this isn't the default behaviour so I'm not sure I've ever heard it given an actual name, it's just what happens when you don't catch the exception - it keeps going until someone does catch it, or it hits the runtime and demolishes your program.

Re: I want off Mr. Golang’s Wild Ride (2020)

#37
post #26

Go has a lot of issues. Some of them would be easily fixable if people promoting and developing Go actually admitted the problems. However, the fanbase usually acts as a cult pretending that issues are features. Thing is, just like broken, hackish dependency "management" had to be fixed (introducing tons of complexity for the sake of not destroying backward compatibility), other problems will have to be fixed as well…

I mean, all programming language communities are partial to their language, but among Go there seems to be an unusual tolerance for disagreement and discussion of language issues compared to most other programming languages. But yeah, when you come in guns blazing talking about how certain language features are "shit" and there's no possibility of elegance, people are rightly going to think you're not there for any sort of productive conversation.

For example, I regularly have productive conversations with people in the community about error handling and sum types and generics, including my criticism for the way Go does some of those features. A little civility goes a long way, and this isn't particular to the Go community or even programming language communities in general. Note that there definitely are PL communities that generally can't handle any criticism irrespective of civility, but the Go community isn't among them. Indeed, in my experience, Go's critics are very often much more zealous than its proponents.

Re: I want off Mr. Golang’s Wild Ride (2020)

#38

To say go's simplicity is a lie, then to go and and say this; > This function signatures tells us a lot already. It returns a Result, which means, not only do we know this can fail, we have to handle it. Either by panicking on error, with .unwrap() or .expect(), or by matching it against Result::Ok / Result::Err, or by bubbling it up with the ? operator. What the hell? I'm not a rust dev. I have no idea what half of…

"Bubbling up" is common parlance for "exit this function early and return the error we got from our callee" (or "wrap the error we got from our callee and return that")

In Go, this looks like

   thing, err := call()
   if err != nil {
       return nil, er
   }
In Rust, this looks like

   let thing = call()?;

Re: I want off Mr. Golang’s Wild Ride (2020)

#39
Golang is great because it was the first to include excellent tooling in addition to the language (strict compiler, linting, non-customizable gofmt, package manager, good html docs, online playground, etc.)

It’s undeniable that it brought a lot of good ideas that languages like Rust borrowed.

Golang is still undefeated in terms of battery included. Its standard library is top notch and full featured.

On the other hand it is more high-level, has a GC, and has made a number of mistakes (no sum types). The biggest trade off it does though: it lacks expressiveness. The new generic will probably help, but the trade off of Golang is deep. It makes writing code harder so that reading is easier.

Re: I want off Mr. Golang’s Wild Ride (2020)

#40

To say go's simplicity is a lie, then to go and and say this; > This function signatures tells us a lot already. It returns a Result, which means, not only do we know this can fail, we have to handle it. Either by panicking on error, with .unwrap() or .expect(), or by matching it against Result::Ok / Result::Err, or by bubbling it up with the ? operator. What the hell? I'm not a rust dev. I have no idea what half of…

>"bubbling up"? What the fuck even is that?

When you throw an error and don't catch it, you just let the error immediately propagate up to the calling function. Think "return err"

>> Either by panicking on error, with .unwrap() or .expect()

This means fatally terminating the program immediately when an error is encountered in this spot.

>> or by matching it against Result::Ok / Result::Err

Result is an enum can be one of either Ok or Err. Pattern matching is one way of finding out which, and running code depending on which variant it is. It's just a fancy and convenient if statement, if that helps.

Post reply on HN