|
|
|
|
|
|
by vec
3087 days ago
|
|
|
In this case, I suppose my specific complaint is that I'm unable to make `range` work transparently with an arbitrary type. I guess you could chalk it up to a difference of aesthetic opinion. I don't want to think about buffers or readables. I want to think about loops and strings. Looping over a collection means `for range`, so I'm gonna assume that Just Works. Maybe `for range` is just syntactic sugar for `bufio.Scanner` under the hood, but I don't want to care while I'm using it. I want to think of a file as a black box full of strings. What's actually in the box? Don't care. How do I get lines out of the box? `for _, str := range blackBox`, same way I loop over every collection. How does that actually work? Don't care. Whoever implemented the box has to care, of course, but I sure shouldn't. I've got more important things to worry about, like whatever it is I actually want the code to do. Every character that isn't about whatever it is I actually want the code to do is a problem. Having primitives and builtins that only work sometimes (specifically, with a short list of builtin types and aliases for same) means I can't just use the builtins without thinking about what I'm using them on. Having to crush down to a lowest common denominator means that what's in my brain while I'm reading and writing code isn't strings and what I actually aim to do with them, it's how the Reader API works, and whether I read a full or a partial line, and whether I need to handle errors before or in or after the loop this time. I want to think about my problem domain, but Go keeps dragging me down into the weeds. |
|
|
Sure, fair enough. But note that you've now shifted the criticism from "I have to import 4 packages" (which was wrong) over "I need to know implementation details of packages" (which was wrong) to "I don't like that Go doesn't have operator overloading".
> I want to think of a file as a black box full of strings.
And what exactly is preventing you from doing that? Like, how exactly is the language preventing anyone from providing this much higher level API? You could even make it work with range, if you so desire (it would be considered very unidiomatic, but presumably you don't care).
The stdlib provides you with composable pieces to achieve the job you want. I still find this complaint incredibly weird, unless you assume that everyone wants to view files as just a bunch of lines (I'd argue, these days, the overwhelming majority of files probably aren't). Like, you will still need the lower-level API; where's the problem with having an stdlib which focuses on providing composable pieces and then having some library do the composition for higher-level concerns?
Last time I checked, having small composable units of code with clearly separated concerns was pretty much universally considered a good thing.
> it's how the Reader API works, and whether I read a full or a partial line
This is just a random aside, but: You never have to care about that, unless you specifically want to. But I would argue that code that calls io.Reader.Read is likely wrong - unless it does so to wrap it. Use io.ReadFull.