8 ms·
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 R
by dilap 7y ago
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?
- fhood 7y agoThe 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?
- dilap 7y ago(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 clients for the different timeout values you need). But if you really don't want to do that, it should be easy enough to access the underlying network connection and set the timeout before reading the body, though I've never done this. What Go is doing here still seems very reasonable from my perspective...
- fasterthanlime 7y agoAuthor 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.
- objektif 7y agoYou dont have to call Python sloppy just because Go sucks at some things.
- jsjddbbwj 7y agoWeakly typed is sloppy.
- palerdot 7y agoPython is 'strongly' typed `dynamic` language!!!
- jsjddbbwj 7y agoNo, Python is not strongly typed by any serious definition of the concept.
- Karunamon 7y agoIsn't the existence of TypeError and the various things you're not allowed to do implicitly (eg: 1 + "a", something Javascript will happily let you do) a definition of strongly typed?
- ben509 7y agoIf it's qualified as a "serious definition," they're setting up a No True Scotsman argument.
- kybernetikos 7y agoJavascript has type errors too, and Java will let you 'add' a string to an integer, so it's more nuanced than that... Javascript: > null.bob() TypeError: Cannot read property 'bob' of null > 4 >>> Symbol("four") TypeError: Cannot convert a Symbol value to a number > BigInt(null) TypeError: Cannot convert null to a BigInt > Object.create(false) TypeError: Object prototype may only be an Object or null: false Java: int anInteger = 10; String s = anInteger + "Hello";
- hinkley 7y agoOften these choices are 2 dimensional, but people don't see it because we can always agree that there's one quadrant that nobody wants, but usually there's another quadrant that some people really want, and others need but don't think they want. It gets ignored and everyone behaves as if X = Y when in fact it should be X <= Y As a concrete example, I was struck by something in an interview where the consultant pointed out that easy to implement functionality gets copied by your competitors quickly. Differentiating features are ones that are very valuable but tricky to get right. But nobody wants to prioritize those and so (my words) whole industries are boring dystopias of cheap features with no kick. You should want to implement some features that are worth far more than the trouble of implementing them, regardless of how much trouble it is. Similarly, getting a concise design may be one of the hardest things we can do. So we end up with naive or baroque most of the time. When someone stumbles onto something better a bunch of us copy them in the next generation of tools, but the inspiration/perspiration balance is very evident in the slow rate of change we see.
- dom96 7y agoIf Go is somewhere in the middle and Rust is on the right then Nim is somewhere in between Go and Rust. Personally I think that’s the sweet spot, and now that Nim is at 1.0 there is no excuse not to give it a try. As nice as Rust’s compile-time memory management is, it’s very often overkill.
- totalperspectiv 7y ago> And so if what you're craving is absolute precision and maximal avoidance of errors or incorrect behavior If you are being paid to develop software, doing anything other than aiming for absolute correctness seems negligent, at best. I think this is part of what leads to obsession with Rust. We build so many things on a daily basis with a long long list of 'it depends'. But Rust aims to make you write something as correctly as possible, and provides a really solid base for you to do this. So that list of 'it depends' shrinks drastically and you feel superhuman for building something so solid.
- ClumsyPilot 7y agoYou statement about absolute correctness doe snot really make sence -vast majorulity of bugs in all software I've ever used are not due to the language design, but are due to blatant mistakes of the application developers.
- totalperspectiv 7y agoThe premise of the article is about incorrectness in a language. So while I agree that most bugs are likely caused by the developer and not the language they are using, I think my comment makes sense in reference to the main post.
- pdimitar 7y agoWell exactly. You and your parent's comment are in agreement: languages like Rust that give you less ways to shoot your foot, encourage writing a more correct code.