|
|
|
|
|
|
by stouset
3088 days ago
|
|
|
> You still haven't described a single piece of your code that requires, in any way to know any implementation details of any of the libraries you are using. Like, you don't have to care how os.File is implemented, it just gives you a Read method that you can use to read from it, just like a thousand other Readers. And then you can use that in a bufio.Scanner to read lines (words, whatever tokens), without that having to care in any way about how the Read method is implemented. You want to scan lines from a byte-slice, use bytes.Reader, that's it's sole purpose and your scanning code does not have to care what Reader it gets passed. These are literally implementation details. Except you're having to implement them yourself. Reading a file delimited by tokens is a solved problem. There is zero reason why I should be having string together code from four different modules to accomplish this myself. This is the entire reason we have come up with the concept of abstraction. |
|
|
This is plainly wrong. All components I mentioned exist in the stdlib.
You have to glue them together yourself, sure, but that's the point of having components with separated concerns, which is usually considered a good thing in software engineering.
> There is zero reason why I should be having string together code from four different modules to accomplish this myself.
You don't. You have to use at most 2. And also, to repeat the question: who cares? Like, what is the actual downside of having to import 2 packages? I also took the liberty of looking for solutions to how to do this in other languages. Here is a Java solution, which is in line with what's requested that has 4 imports and one of them is third-party: https://stackoverflow.com/a/1096859. Here's rust code with 4 imports: https://users.rust-lang.org/t/read-a-file-line-by-line/1585. Python and Haskell get away without imports; because they just make reading files a language-builtin/part of the prelude, which TBQH is pretty cheaty.
Like, even if I'd buy into the notion that modularity and composability are bad things, it's not even as if Go would be in any way an outlier here. And even if it where then at best this is the mild complaint that no one has yet wrapped this in a ~10-line library; the language certainly does allow it, contrary to what's claimed.
I'm sorry, but this complaint is just forcibly trying to make up a problem where none exist to fit your narrative of Go being a bad language. It's not productive.