this post was submitted on 16 Jul 2023
4 points (64.3% liked)

Golang

2206 readers
2 users here now

This is a community dedicated to the go programming language.

Useful Links:

Rules:

founded 1 year ago
MODERATORS
top 12 comments
sorted by: hot top controversial new old
[–] [email protected] 5 points 1 year ago (1 children)

This is just a rant about personal frustrations. I even probably agree with him on most of these things, but I don't think we need to share this kind of thing here. So tired of threads about how much we all hate and disagree with each other's languages. It's better if the rust people get rust and the go people get go. There is no one holy grail of a language that everyone is going to like.

[–] [email protected] 1 points 1 year ago

Now I kind of want to make a Holy Grail language. Probably Monty Python themed, and you have to do a lot of nonsense to make anything work.

[–] [email protected] 5 points 1 year ago* (last edited 1 year ago) (2 children)

And overall the author does not really make any good arguments beyond rust did it different to go but they are already used to the way go does things. And honestly, all the points they make are points that frustrate me about go, not rust. Which is all a matter of personal preference, no technical arguments were really made.

[–] [email protected] 4 points 1 year ago

Yeah, statements like this just sound like "me not want learn complex language for complex tasks":

generics look like they've been put through a syntax juice blender

Like... What? No, they look like what you'd expect them to look like in the context of Rust's typing system

[–] [email protected] 2 points 1 year ago

Agreed, this reads like a list of things I miss from rust when I'm writing go to me.

[–] [email protected] 4 points 1 year ago (1 children)

I went into this with an open mind, then I saw the rant about error handling and I closed the article immediately.

Rusts error handling in combination with eyre/anyhow is the most pleasant error handling I have used in any language. You know exactly which lines can return errors, you can very quickly propagate them and attach context so that you can quickly troubleshoot later on, and it's completely natural and unintrusive. No figuring out whether you already logged the error somewhere else, no inconsistent handling of them, it's one library that does everything for you and you never have to think about it.

The go example is comparatively awful. You are forced to handle the error at each stage, and it runs into the same problem as exceptions where you're not really sure at which point you actually handled the error among other things.

[–] [email protected] 0 points 1 year ago (2 children)

@gnus_migrate @nebiros In Go we consider errors as values and not fatal or exceptions. For example sql.ErrNoRows , io.EOF, custom... It's why they are returned and used like any other values.

[–] [email protected] 2 points 1 year ago

Errors are values in rust too. There are a couple of differences, like the ? syntax, rust returning a value or an error instead of a value and an error (or nil) for example, but everything you wrote applies to rust as well.

[–] [email protected] 2 points 1 year ago

The difference is that you can't have a generic mechanism in Go for error handling. It's basically up to the programmer, and every if error != nil line is a potential source of bugs.

[–] [email protected] 1 points 1 year ago

Disclaimer: Rust is an awesome language, and this blog is meant purely for some fun and perhaps a bit of frustration!

Yeah, yeah, ok I get it. But please, please don't use images for code samples!

[–] [email protected] 1 points 1 year ago

This only made me dislike go more

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

I know this is a piece of humor, but half of these are not surprising coming from a FP background (expression oriented, sum types, strong generic typing... )

Also, daring to compare Go and Rust error handling, and saying that Go's one is better is... bold. It's arguably one of the worst in any language.

load more comments
view more: next ›