I Want Off Mr. Golang's Wild Ride • Hacker News Board

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

#181

Post by bsimpson » Fri, Feb 28, 2020, 6:43 PM UTC

> Nine out of ten software engineers agree: it's a miracle anything works at all

There was a beautiful rant about a decade ago called something like "everything's broken all the time and nobody cares." The gist of it is that all software is written by people. Anyone who's written software knows that it's usually riddled with hidden corner cases, unfortunate tradeoffs, rushed deadlines, etc. Software is also moving into critical spaces like aerospace, medicine, banking, etc. The thrust of the article is that we're trusting more-and-more critical infrastructure to a discipline that anyone who's worked in knows is untrustworthy.

Does anyone remember the link to the article? I've often wanted to re-read it and share it with people, but I've never been able to find it.

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

#182

Post by steveklabnik » Fri, Feb 28, 2020, 6:44 PM UTC

klodolph wrote: post #164

fhood wrote: post #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.

That said… I feel that Rust’s use of WTF-8 for OsString on Windows has resulted in some really nasty problems, especially since OsString doesn’t expose any useful methods for string manipulation. As far as I can tell, Rust’s approach fails to hide any of the complexity, and then adds the additional complexity of a new encoding and conversions on top. I can see that there’s some end goal of being able to work with OsS…

I have felt this pain for sure, but only really once. This is because, in languages with strings as paths I tend to use string manipulation to do operations on paths, but given that virtually all of my OsString usage is paths, which have specific manipulation functions already it’s lesser.

This is also why the interface isn’t so rich, there just hasn’t been a lot of demand. That said I think some things are in the pipeline?

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

#183

Post by mehrdadn » Fri, Feb 28, 2020, 6:45 PM UTC

fortran77 wrote: post #155

> So, no errors. Chmod just silently does… nothing. Which is reasonably - there's no equivalent to the “executable bit” for files on Windows. It's simply not true that Windows doesn't have "execute permissions" for files. It does: https://docs.microsoft.com/en-us/windows/win32/fileio/file-s... It's just that the people who wrote the go library couldn't be bothered to abstract this interface across all platforms.

+1 came here to say the same thing. This seems more like a problem with the standard library authors not putting in enough effort than anything else.

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

#184

Post by tedmielczarek » Fri, Feb 28, 2020, 6:46 PM UTC

klodolph wrote: post #149

With the path example… just try to combine this with flags, so we do something like: $ ./my_program --file="$(printf "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98")" Well, just try to write the program that does that in Rust, without using some option-parsing library that hides all the details, and then try to figure out how to get it to work equally on Windows. To spoil the answer, it turns out that OsString only exposes a coup…

The point isn't that it should be easy to do terrible broken things like this. The point is that you will encounter these things in the real world and have to deal with them in some way. Rust's OsStr[ing] let you do that. If you really have a burning need to create files whose paths are not valid Unicode you can do that in Rust but you will have to jump through some hoops. I don't see that as a problem.

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

#185

Post by whateveracct » Fri, Feb 28, 2020, 6:48 PM UTC

uhoh-itsmaciek wrote: post #180

whateveracct wrote: post #77

Here's an example of why Go's simplicity is complicated: Say I want to take a uuid.UUID [1] and use it as my id type for some database structs. At first, I just use naked UUIDs as the struct field types, but as my project grows, I find that it would be nice to give them all unique types to both avoid mixups and to make all my query functions clearer as to which id they are using. type DogId uuid.UUID type CatId uuid.…

Not to mention that sql.Result (the return value of Exec) has a LastInsertId() that's an int64, so if you're using uuids, you can't use that at all and have to call Query instead and manage generated IDs yourself.

Haha yes I've long since resigned myself to using Query + explicit RETURNING for inserts

Cut 2 of 1000

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

#186

Post by totalperspectiv » Fri, Feb 28, 2020, 6:49 PM UTC

My main takeaway is the quote from scottlamb:

> ... these sorts of statements contribute to my belief that Go is an opinionated language that I should hesitate to choose for anything that the language's authors haven't specifically considered in depth.

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

#187

Post by rhinoceraptor » Fri, Feb 28, 2020, 6:50 PM UTC

hota_mazi wrote: post #108

fhood wrote: post #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.

> the majority of which relate to Go's tendency to just be silently completely wrong 100% right on. Go's handling of errors is often ridiculed for its verbosity and lack of thought, but the fact that Go makes it so easy to sweep errors under the rug has real and devastating consequences in the real world. Go programs are much less safe than programs written in Rust or Java for that reason.

It's not surprising that other pieces of golang have incredibly broken assumptions, I know this particular one was discovered independently by many people:

https://github.com/golang/go/blob/71ab9fa312f8266379dbb358b9...

https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

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

#188

Post by Karunamon » Fri, Feb 28, 2020, 6:51 PM UTC

marwatk wrote: post #172

Karunamon wrote: post #107

Earlier quoted context omitted.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.

If multiple functions you call return an error golang only cares if you've checked the last one.

Holy crap, seriously? I guess that makes sense since everyone calls the return 'err', I'd just never noticed before.

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

#189

Post by pcwalton » Fri, Feb 28, 2020, 6:51 PM UTC

Karunamon wrote: post #107

Seenso wrote: post #103

Earlier quoted context omitted.

> Well you should handle the error in the first place. That's like saying you should just write bug-free code in the first place.

Go goes out of its way to ensure you handle the error. You have to do something with that err return, otherwise it's a compile error. If you're just throwing it away without checking, we've gone from the mere mistakes everyday developers make to irresponsibility. There's a reason most go code is littered with "if err != nil" on nearly all function calls.

Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the result of os.Mkdir() on the floor.

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

#190

Post by btilly » Fri, Feb 28, 2020, 6:54 PM UTC

fhood wrote: post #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.

And the other one is the tendency for Go's design to say "exceptions are allowed for me but not for thee".

When I worked at Google I used other languages by some of the same authors and they showed the same design philosophy. Make things with an enforced simplicity, and where there were more special use cases that the language designer needed, they created escape hatches for themselves but not the language users.