It's not so much that it's hard, as is there's lots of options. Can you afford to read it all into memory as a String? Do you need to only read it bit by bit?
> Why is it my job to tell it how to buffer?
Systems langauges need to expose these kinds of details and levels of control.
> Nobody is going to know how to do this
I googled "rust open a file and read by lines" and got these results:
https://users.rust-lang.org/t/read-a-file-line-by-line/1585
https://doc.rust-lang.org/std/io/
https://doc.rust-lang.org/std/fs/struct.File.html
The first two show you directly how, though the first one is dealing with the error message. The last one shows reading it all in. I have some more work to do :)
However, many languages make a reasonable assumption that you can afford to fit each line in memory, and provide an obvious way to do this.
Again, it's about control. Maybe you're only loading a small configuration file, and so fetching it all in one go is better than dealing with a buffer.
> an obvious way to do this.
If you search for 'line' or 'lines' in rustdoc, the correct thing is right near the top, which will show you how to use it with BufRead.
If it's small, it can't be that much worse to buffer. What's wrong with reasonable defaults?
Can you tell me what it means to search for 'line' or 'lines' in rustdoc? Is this a command-line tool? I'm aware of the 'rustdoc' that generates documentation, but not of anything by that name that searches documentation, and Googling isn't turning up much of anything except the Rust book here.
It would be great to have an offline way to search Rust documentation and examples, as things like this make it very hard to write Rust on a plane, for example.
Googling often gives answers that are wrong or pre-1.0. You seem to have better luck at searching for the right things, perhaps because you are an expert in the language and know exactly what to search for.
(Amusing related anecdote: I googled for "how to return self in rust" and got a suicide prevention website. Jeez, Google, it's not that bad.)
Rustdoc has a search bar at the top. with 'line' it's the third result, 'lines' is the first https://doc.rust-lang.org/stable/std/?search=lines
and the short description makes it clear that the first two results are irrelevant in this case.
> It would be great to have an offline way to search Rust documentation and examples,
It all works offline. These docs are pre-installed for you when you install Rust, and 'cargo doc' will generate them for your whole project.
> perhaps because you are an expert in the language and know exactly what to search for.
I copy-pasted my search term exactly in the previous post.
Let me assure you that I mean only the best for this language and I appreciate your persistent willingness to help, but I want to help debug your use of internal terminology that doesn't help beginners.
"rustdoc" is not how you should be telling beginners to look for documentation. As far as I can tell, "rustdoc" is the tool for generating documentation, not searching it. I assume you use rustdoc a lot and that's why the name comes to mind.
Maybe the term is overloaded, but I cannot find anything called "rustdoc" that involves a search bar. Googling for "rustdoc" gives many forms of Rust documentation, none of which have a search bar. DuckDuckGo-ing for "rustdoc" (as some documentation suggests instead of Googling) gets me some of the same things, plus rustdoc.com, which is a big honking security warning on top of someone's broken personal blog.
I know that exact link you gave me includes a search bar, but that's an example of finding the answer because you already know it.
And if you know to go to doc.rust-lang.org and go to the Standard Library API Reference, you get a search bar, but that's not where I would think of going to answer the question "how do I iterate lines".
That's why I end up Googling and getting to Stack Overflow, full of wrong answers and someone named Shepmaster yelling at newbies.
Sorry, as I mentioned elsewhere I was in a meeting; I should have just waited to apply to you. It's true that "rustdoc" is overloaded, people use it to mean "rustdoc's output" which would mean the standard library docs in this case. My bad!
Please make sure to leave a comment and/or downvote any answers that are wrong to help people coming after you. I also apologize for whichever specific way I harmed you.
>> It all works offline. These docs are pre-installed for you when you install Rust, and 'cargo doc' will generate them for your whole project.
Not by default, anymore[0], as I found out when I wanted to read the book offline.
To set up offline documentation, do:
rustup component add rust-docs # One-time thing
rustup doc
rustup doc --api
rustup doc --book
[0] https://users.rust-lang.org/t/psa-rust-documentation-is-now-...
I'm bringing up a problem with how the language presents itself to beginners, not asking you to solve a specific problem for me. If searching is the answer to everything, then there needs to be a concerted effort to take Google-juice away from bad or deprecated answers.
Incidentally, the search result you're describing for "lines" says "An iterator over the lines of an instance of BufRead.", which only appears to be the answer to "how do I iterate lines of a file?" if you already know what the answer is.
I think we have two searches confused. When I meant "my exact query, when we were taking about Google, here: https://news.ycombinator.com/item?id=13585902
I find it interesting that we got different results.
I thought "an iterator over lines" would be enough; maybe not.
In other languages, you might do File.ReadAllLines("foo.txt"), and bam, you're done.
In Python you can just loop on anything declaring the __iter__ method, and it will lazily yield results little by little.
IO related objects implement it plus an additional layer of interface so that you can do:
with open('file', [mode, encoding]) as f:
- for `line in f` to lazy read it line by line. This calls __iter__.
- `f.read([byte_count])` to read it all or some bunch of bytes. `f.seek(index)` to move around, etc.
- `f.readlines()` to get a list of all lines in memory.
- `f.close()` if you wish to close the file manually instead of letting the `with` keyword doing it work you.
This interface works for most IO, including files, sockets, in memory buffers, etc.
So you can choose an automatic lazy loading, a manual loading, load everything in memory, etc. And still have a lot of control.
I think rust should get some traits to expose such a common high level interface on top of the current way it deals with files, to ease simple operations. Just make sure the documentation states what you can do to go lower level.
There is a similar trend with many basic topics trying to do that as 3rd party libs too. click makes creating cmd UI very easy on top of argparse which is lower level. pendulum is higher level than datetime. requests higher than urllib. etc. Those all make doing those very common operation super easy.
Now rust is not meant to be Python/Ruby/whatever, being very low level, and checking safety at compile time implies very different requirements.
But those communities have some good concepts on API ergonomics and it would be a shame to not steal ideas from them.
The interface for reading is split into multiple parts. Read is the lower level interface for any stream of bytes, and is what lets you read a specific number of bytes into a preallocated buffer. Seek is implemented for files, but not all streams, because in most cases it makes no sense. There are also a number of file-specific methods directly attached to File for handling permissions and sync and such.
BufRead is the trait that lets you read all the lines, but it is explicitly not implemented for File, since using it for a File would be slow, and generally the wrong way to do things. It does have an implementation for Stdin, because that is already buffered, but if you want to associate a buffer with a file, you have to do it yourself by wrapping it in a ReadBuffer.
If I were to find a problem with the File documentation, it is that it does not mention BufReader.
On top of handling errors (which I understand is necessary, and which the ? operator makes easier), it requires importing BufReader and BufRead, and wrapping a reference to a file handle in BufReader.
Nobody is going to know how to do this unless they come across it in Rust By Example or on Stack Overflow. Shouldn't a standard library be able to abstract over fiddly details like this? Why is it my job to tell it how to buffer?
I say this as someone who is enthusiastic about Rust, but still learning.