> The Go way is to half-ass things. This used to be known as the New Jersey school, and is the underlying philosophy of Unix: build a bunch of little pieces that work a lot of the time and kind of fit together if you remember the gotchas, then call it a day. There is an essay on this that I am unable to locate right now which mentions the horror of someone working on ITS when they asked how Unix solved a rollback on…
I Want Off Mr. Golang's Wild Ride
71–80 of 508 posts
Re: I Want Off Mr. Golang's Wild Ride
#72If 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…
You dont have to call Python sloppy just because Go sucks at some things.
Re: I Want Off Mr. Golang's Wild Ride
#73Maybe 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…
C# support in linux and osx are actually quite good these days especially in .NETCore. You run into some cross platform issues if you want to go as deep as shell handling when trying to manipulate processes, though.
Re: I Want Off Mr. Golang's Wild Ride
#74If 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…
You dont have to call Python sloppy just because Go sucks at some things.
Weakly typed is sloppy.
Re: I Want Off Mr. Golang's Wild Ride
#75Earlier 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.
For high-level languages you're writing user-facing apps in domains where your file handing needs are simple, I can see the appeal.
But of course you're ignoring the entire category of systems programming, cross platform apps that need something more than easy access to a file picker, integration code that frequently needs to deal with exactly the edge cases that these pretty abstractions ignore, etc. etc.
VB6 had its place. So does C.
Re: I Want Off Mr. Golang's Wild Ride
#76The 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.
Yes, the latter half made much better and broader points
Re: I Want Off Mr. Golang's Wild Ride
#77Here'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.UUID
The issue is Go encourages reflection for this use-case. The Scan() and Value() methods of a type tell the sql driver how to (de)serialize the type. uuid.UUID has those methods, but when I use a type definition around UUID, it loses those methods.
So the correct way to wrap a UUID to use in your DB is this:
type DogId struct { uuid.UUID }
type CatId struct { uuid.UUID }
[1] https://github.com/google/uuid
EDIT: This issue also affects encoding/json. You can see it in this playground for yourself! https://play.golang.org/p/erfcSIe-Z7b
EDIT: I wrongly used type aliases in the original example, but my issue is with type definitions (`type X Y` instead of `type X = Y`). So all you commenters saying that I did the wrong thing, have another look!
Re: I Want Off Mr. Golang's Wild Ride
#78Re: I Want Off Mr. Golang's Wild Ride
#79Maybe 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…
Maybe I'm also a zealot, but this "second-class citizen by comparison" works pretty well - I've been using Go for some side projects under Windows for years, and was actually surprised how well it worked. I even developed a GUI app some years ago (using GTK). So, if you ask me, the glass is ~90% full, not 10% empty...
Re: I Want Off Mr. Golang's Wild Ride
#80Earlier quoted context omitted.
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 networki…
(I have never personally used context, so I'm not so sure what the expectations are with that.) Looking at the http docs, I don't see any reason to believe setting a context for a request would control timeouts. If the complaint is, "the http library API does not provide a way to set timeouts on a per-request basis," then OK, I guess, that's true, but I don't see why that should be a huge issue (just use different cl…
Author here, the article was actually wrong - I meant to expose yet another timeout you can set on HTTP requests, I've updated it to include that one, and be clearer on what `idletiming`'s purpose is.