Live data from Hacker News

I Want Off Mr. Golang's Wild Ride

fasterthanli.me

361–370 of 508 posts

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

#361

Earlier quoted context omitted.

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 maintaine…

No one expects iOS to run on Windows. But given that there's a Windows version of Go, it's reasonable that it should work. And also, the points about metadata and path management are spot on. It's 2020. Languages should not be assuming that paths are byte strings. Unix-think is a bug, not a feature. A good language should abstract the file system, not just put a teeny tiny wrapper of modesty around it.

> Languages should not be assuming that paths are byte strings.

Lots of people who know what they're talking about disagree:

https://yarchive.net/comp/linux/utf8.html

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

#362
post #334

Earlier quoted context omitted.

Is that wrong, though? I mean, confounding features like exceptions are... useful. That's why they found in languages in the first place. They're just footguns when used "wrongly". So why not have an "escape" hatch for experts that isn't part of the standard/official/blessed paradigm of the language? I mean, isn't this exactly what Rust did with unsafe? Warn everyone away from it, promise that "normal" code will neve…

No, because anyone can use `unsafe` in Rust. GP’s point was that Go can use the feature internally but no end-user can.

That sounds more like a legal argument than an engineering one. I mean, who cares what the mechanisms are and what the precise rules and enforcement mechanisms are? The point is there are complicated features that are OK in some contexts but not others, that this varies between problems and between languages, and that some parties make different decisions on how to make use of them even when implementing software for people who take contrasting positions.

I mean... so what? Either Go is good because it lacks exceptions or it's bad for the same reason. And it's either a good decision that it uses a similar mechanism internally or it's a bad one. Both of those are arguments worth having, but they are different arguments and there is no technical reason to demand they be resolved in the same direction.

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

#363
post #289

Earlier quoted context omitted.

Isn't that the standard library and not the language?

Go the language lets the Go the standard library play with things that nothing else can. If you can't implement it yourself, is it really a library and not just part of the language runtime?

Oh I didn't know that. I thought anyone could modify the standard library. Do you mean syscall?

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

#364
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…

Rust still doesn't get this right. If I'm calling an NFS library, say, on Windows I need to use UNIX paths. Rust needs WindowsString and UnixString on every platform, with OsString as a synonym for whichever is most useful locally.

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

#365

Earlier quoted context omitted.

C++ has been adding things like optional types; std::optional was released in C++17, there's talk of maybe pattern matching coming soon...

Java has Optional as well, but as you well know, you can't just bolt ADTs onto the side of a language and wash your hands of it. The whole system has to be designed around it to get the benefit of it. Java programmers will be checking for null until the last line of Java is written.

> Java programmers will be checking for null until the last line of Java is written.

Not necessarily. Adding nullability types to Java is a smaller undertaking than adding generics was.

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

#366
Scuolo di Michaelangelo "god, this Carrera marble is so hard to work in why can't we just pour concrete into rubber moulds like the garden gnome factory next door"

Michelangelo "fine, I thought you wanted to learn how to sculpt perfect buttocks but whatever"

Jeff Koons "that garden gnome idea, how about now I know how to carve Carrera marble I make one in marble"

Scuolo ..."Jeff.. we hate you"

The GO authors are gifted. They make tools gifted people understand. If you aren't gifted, they are difficult tools to use.

(I'm not gifted btw)

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

#367

Earlier quoted context omitted.

Off topic: I’ve had success explaining the Monty Hall problem by generalizing it to, say, 10,000 doors, where Monty opens 9,998 of them before allowing you to switch. People seem to intuitively understand that it’s extremely likely that the prize is behind the other door.

You'd think that this would make it evident, but every person I've said this to said "no, you still have a 50-50 chance". I just give up after that.

At that point, the only thing to do is set up 20 playing cards and offer them a prize of $100 for every $10 they wager.

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

#368
post #348

Earlier quoted context omitted.

You can always make input validation errors a checked exception with your own exception type. It'll accomplish what you're trying to accomplish. It's not perfectly clean because it'd be nice if you could stick it under the "IllegalArgumentException" part of the inheritance tree, but it does what you're asking for.

Right but if you derive it from Error it isn't checked and same as if it is derived from RuntimeException. Deriving from Exception is checked but then you aren't fitting in with the hierarchy that pron is recommending, or at least what I think they are recommending, which is why I asked for clarification.

Internal errors are bugs or other conditions that the application is not expected to handle (other than, say, restart the thread a-la Erlang). Input validation is not an internal error. IllegalArgumentException is meant to represent bugs, and so an internal error, and so it is unchecked. It does not represent input validation errors.

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

#369

Can we just stop with the "Rust vs Go" shit? If you want me to take a critique of Go seriously these days, pick another language to compare it to. Any other language. And yeah, I'm aware that 5 years ago there were a ton of "Go vs Java" articles. I didn't think much of them then, either.

Java handles files and their permissions much better than this. It takes Path objects instead of strings, offers generic setReadable, setWriteable, etc methods and exposes finer grained apis to set posix specific bit and windows attributes.

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

#370
post #343

For those unaware, the title is a reference to a hilariously long user-created ride in Roller Coaster Tycoon 2 titled "MR BONES WILD RIDE" [1]. The ride's exit connected to its entrance, so passengers were forced to repeatedly ride the roller coaster forever. [1] https://knowyourmeme.com/memes/mr-bones-wild-ride

Have you not heard of Mr. Toad's Wild Ride?
Post reply on HN