Live data from Hacker News

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

21–30 of 508 posts

Re: I Want Off Mr. Golang's Wild Ride

#21
Rust is great it follows modern programming techniques and theory but it focuses a little too much on zero cost abstractions and because of that the abstractions are a bit complicated.

Go is easy to learn but poorly designed with an incomplete type system hence all these strange issues.

There is a vacuum that exists between Rust and Go. A language that utilizes modern Algebraic Data Types (like rust) but does not necessarily need to create abstractions just to make everything zero cost (like Go).

Re: I Want Off Mr. Golang's Wild Ride

#22
The author spent a lot of time dwelling on Window's filesystems, at which point many of the readers got bored and started commenting. There are actually a couple of excellent points in here, the majority of which relate to Go's tendency to just be silently completely wrong in its behaviors from time to time, and is absolutely packed with hidden gotchas.

Re: I Want Off Mr. Golang's Wild Ride

#23
If you imagine a spectrum of languages from sloppy-but-"easy" to precise-but-"hard", with something like Python or Ruby way off on the left and something like Rust way off on the right, Go is sitting somewhere in the middle.

And so if what you're craving is absolute precision and maximal avoidance of errors or incorrect behavior, then Go is not going to be your jam. I sympathize w/ that.

That said, these specific complaints don't strike me as that bad.

- Filesystem perms exposed on windows, which just no-op. This seems pretty reasonable, though!

- Filesystem paths represented as str type, which is assumed to be utf8, but doesn't have to be. This also seems reasonable! If you want to check for invalid utf8 and specifically print out something special in that case, nothing in Go is stopping you from doing that. This is a classic "easy but sloppy" vs "hard but precise" tradeoff.

- Timeout thing -- I'm a little confused here, or maybe not up-to-date. He says let's do things the "modern" way and pass a context to do HTTP timeouts, which apparently doesn't work, and then goes off on a 3rd party package to then fix this which has an insane dependency graph. But...if you just set the Timeout field on the http client, everything works correctly. So what's the problem? Or am I missing something?

Re: I Want Off Mr. Golang's Wild Ride

#24

Clickbait title. Should be titled "Golang doesn't work well with Windows".

Granted, the article is pretty long, and spends a lot of time talking about this windows pitfall that I was also about to abandon it. Then it speaks of other examples like the monotime issue which I think is a better example of what he is advocating.

Re: I Want Off Mr. Golang's Wild Ride

#25
post #2

Maybe I'm a zealot, but I don't really consider "doesn't work as well on windows" a con of a language. C# is (or at least used to be) utter garbage on Linux compared to Windows. I don't hold that against C#, but rather recognize that Linux/Windows are very different, and that compiler maintenance and development is non-trivial (and obviously Microsoft is going to prioritize Windows). This article is basically a rant…

I absolutely agree. The one time I had the great misfortune of building software for windows I was extremely happy to see Go worked at all.

Linux and OS X largely work the same way due to their shared Unix-ness and pretty much everyone I’ve ever met or talked with uses Go on one of those two platforms.

If you have to develop software primarily for Windows, maybe don’t use Go - it’s easily the least actively maintained OS target and there are many options for languages that are well supported on Windows by vendors who actually care. Kind of the same folly as trying to write an iOS app not in Swift or ObjC and then complaining it doesn’t work well.

Re: I Want Off Mr. Golang's Wild Ride

#26

Rust is great it follows modern programming techniques and theory but it focuses a little too much on zero cost abstractions and because of that the abstractions are a bit complicated. Go is easy to learn but poorly designed with an incomplete type system hence all these strange issues. There is a vacuum that exists between Rust and Go. A language that utilizes modern Algebraic Data Types (like rust) but does not nec…

It's not a void. StandardML file the niche well and Ocaml is getting close (just waiting for multicore support). The issue is a company that wants to put in resources.

Re: I Want Off Mr. Golang's Wild Ride

#27
Most of this rant is a disagreement of how Go handles file system differences between Unix and Windows, most of the rest is complaining about some badly written library.

May be good to know if you’re dealing with any of that, but this much effort would be much better served submitting a proposal to change whatever the author is so worked up about. Either the proposal is accepted, or the Go community will provide a response if the proposal is written with due consideration.

Re: I Want Off Mr. Golang's Wild Ride

#28
post #23

If you imagine a spectrum of languages from sloppy-but-"easy" to precise-but-"hard", with something like Python or Ruby way off on the left and something like Rust way off on the right, Go is sitting somewhere in the middle. And so if what you're craving is absolute precision and maximal avoidance of errors or incorrect behavior, then Go is not going to be your jam. I sympathize w/ that. That said, these specific com…

The http client isn't always directly exposed. I agree with the author. Context is a per request object and timeout should be able to function on a per request basis. Client is often shared and reused, and thus not always exposed in certain design patterns. If context has a timeout why doesn't it work as you would expect?

Also, now that I think about it, why does the basic http.get call mentioned in every go networking tutorial not have a default timeout?

Post reply on HN