Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

fasterthanli.me

Post reply on HN
Print view View original

51–60 of 477 posts

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

#51

Post by nmilo »

I see this point everywhere about Rust's union types and it always kind of irks me:

> The point is, this [Result type] makes it impossible for us to access an invalid/uninitialized/null Metadata. With a Go function, if you ignore the returned error, you still get the result - most probably a null pointer.

It's all about framing. You can just as equally say it is "impossible" to access an invalid Go FileInfo, because you'll get a panic for derefencing a null pointer. Or you can just as equally say it is "possible" to access an invalid Rust Metadata, just by doing .unwrap(). Everyone knows an unchecked .unwrap() is just bad Rust code, but then again dereferencing a pointer without checking the returned error is just bad Go code.

Anyways the rest of the article seems like just a criticism of Go's file system API, which seems fair but also seems a little niche given how difficult it is to create a good cross-platform file system API. This particular point irks me though:

    > stat "$(printf "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98")"

    > fmt.Printf("      %s\n", e.Name())
> It... silently prints a wrong version of the path.

What did you want it to do? The author even admits go strings are just byte slices, not UTF8, and then passes a non-UTF8 string to a function that expects UTF8. If there's a chance the file path your program works with might not be UTF8, then you should validate it. I think moving the complexity UTF8-ness out of the type system was a necessary evil.

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

#52

Post by bob1029 »

justinzollars wrote: post #43
HL33tibCe7 wrote: post #22

Could this post be unflagged please? I don't think it satisfies any requirement for flagging.

@dang

You usually need to send an email to the site administrators to get their attention. This information is available in the FAQ:

https://news.ycombinator.com/newsfaq.html

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

#53

Post by shadowgovt »

miloignis wrote: post #31
0xdeadb00f wrote: post #27

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.

And the reason Go keeps a toe-hold in the ecosystem is that file-handling is simple for most people, most of the time.

Rust is expressing the full complexity of a twisty maze of corner-cases built up from decades of filesystem features being slapped on with no care for each others' existence. Go just says "Sure, but you won't need most of that most of the time; here's a subset that usually works." So it solves most people's problem most of the time with far less words (with the trade-off that if you get burned, you get burned).

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

#54

Post by chernevik »

HL33tibCe7 wrote: post #22

Could this post be unflagged please? I don't think it satisfies any requirement for flagging.

Off-topic, but HN needs review of flagging abuse. Maybe assign flagging privileges only to those with X reputation, and revocation if on review the privilege is abused?

It seems that flagging is as much "I don't like this" as "this is not appropriate".

Likewise downvoting. Maybe instead display both downvotes and upvotes, so people can see if a comment is found controversial?

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

#55

Post by throwaway894345 »

mcronce wrote: post #47
the_common_man wrote: post #42

Earlier quoted context omitted.

> For example, Go error handling is shit What is bad about it?

It requires several additional lines of code just to bubble up an error, for starters, and there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data.

The latter is a much stronger argument than the former (no idea why people get so worked up about character counts), but even then, "shit" is really strong considering how often one experiences exception traces when using an application written in Python or Java or some other exception-based language. Point being, we should probably evaluate error handling schemes based on results rather than ideology (even though I tend to agree with some of that ideology).

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

#56

Post by metadat »

Rygian wrote: post #29
0xdeadb00f wrote: post #27

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.

Bubbling is what my guts do when they're unhappy. Not a great programming term.

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

#57

Post by burnished »

throwaway894345 wrote: post #37
gambler wrote: 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 s…

Huh, I had sort of found the opposite, that the Go community I had interacted with was more aggro and prone to offense. I'm forming this opinion from the reddit and the discord though, so if there is another community you favor I'd genuinely love to hear about it.

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

#59

Post by [deleted] »

0xdeadb00f wrote: post #27

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…

[deleted]

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

#60

Post by ryandvm »

gambler wrote: 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…

> the fanbase usually acts as a cult pretending that issues are features

JavaScript kind of went through the same thing a few years ago. While everybody else was complaining about Callback Hell, the JS guys were insisting it wasn't a problem. Then they added promises, and later async/await. And lo and behold, what wasn't a problem eventually got fixed.

For a while you would constantly find folks on forums saying, "yeah JavaScript used to be shit, but with ES* it's now perfect." This went on for years.

I think the cultish "we like it this way" is just basic human programming. We do it with items we purchase, political parties we've joined, cities we live in, programming languages, everything.

Post reply on HN