Comment by yodelshady | Hacker News Reader

Comment by yodelshady | Hacker News Reader

Parent Full thread

You want to see sadness, from a learning curve point of view?

How to read from stdin on Rust.

https://stackoverflow.com/questions/30186037/how-can-i-read-...

Naturally, `read_line` returns the number of bytes read, rather than... the line. If you want a function or macro that does simply return a string, the best way is to... download an external crate? Because nothing says "security" more than third-party dependencies for basic tasks.

Incidentally, use of said crates is different dependent on Rust 2015/2018. Half of the internet resources you will see are wrong. If you already understand the differences, you'll know which is which.

Oh, and if you see "type" unaware in a Rust codebase, you know the one thing it isn't... is a type. Generics are sometimes elided, sometimes not, and sometimes live in a separate namespace.

Oh, and if you test code on a static array of length < 32, and a similar array of length > 32, you will see completely different behaviour.

Oh, and no REPL. This has got to be my single favourite thing about Python - I am literally never surprised. Because any, single, line of code I'm not 100% on is tested in seconds. A browser-based substitute is just that, a very poor substitute.

Rust has good points, but some huge ergonomic difficulties for a beginner, that are nothing to do with "the core difficulty of programming" - you'll note I've not even mentioned how a reader is supposed to comprehend what a <&'a T> is. The best I can say is that it's good gatekeeping.

> Naturally, `read_line` returns the number of bytes read, rather than... the line.

That decouples the concern of allocating the buffer from reading the actual line. It should be possible to write a wrapper that does "return the line" (in an owned buffer), and that might be a bit cleaner in simple cases. But the stdlib should focus on providing essential functionality first.

> Oh, and if you test code on a static array of length < 32, and a similar array of length > 32, you will see completely different behaviour.

This will most likely change after const generics get fully stabilized. The current code is already using them under the hood, but the separate behavior for size>32 is being kept for forward compatibility in case const generics need to change.

> you'll note I've not even mentioned how a reader is supposed to comprehend what a <&'a T> is.

That comes up almost exclusively when working with references that have different lifetimes. Rust tries to deduce lifetimes whenever possible so that writing them out isn't necessary most of the time, but sometimes the programmer has to resolve ambiguity. The whole system is still quite intuitive.

>It should be possible to write a wrapper that does "return the line" (in an owned buffer), and that might be a bit cleaner in simple cases.

So put it in std lib. The point of computers is to not force humans to duplicate identical, basic tasks millions of times, and a major selling point of Rust is zero cost abstractions.

Stdlib Rust has everything necessary to write a read_line that returns a good abstraction - Result<&str, Err> - and instead provides a leaky one. I shouldn't be giving a pigs' ear about the buffer length. And come on, a language with vec.windows() in the std library is not minimal. It's just inconsistent.

Well actually you couldn't return an &str, because it would be dropped at the end of the read.

You'd need to return either a String (and that would be a big mistake) or a Vec of u8. Which I'm sure you'd also be unhappy with

>It should be possible to write a wrapper that does "return the line"

Is it, or not? What's the point of lifetimes if you can't manage that trivial outlives-the-creator task in literally every other language ever with them? Why would a String be a big mistake?

You STILL think Rust is easy to learn?

It is. The reason it is not in the stdlib is because it is a foot-gun. Quoting myself from elsewhere in this thread[1]:

> Other languages aimed at ease of use will just allocate for you and give you the fully baked contents in a single fn call, but when you're writing code that 1) has to be called often enough where allocations can show up in your flame graphs or 2) the input is big enough that you can't realistically keep the entire thing in memory at once, you suddenly have to care about what the fn is doing internally. Making the default API for file interaction require you pass in your own buffer makes this explicit at the cost of some ease of use.

[1]: https://news.ycombinator.com/item?id=23811980

It is not. A very useful function does not mean you have to use it in the hot path or for huge inputs.

>>>>It should be possible to write a wrapper that does "return the line"

>>> Is it, or not?

>> It is.

> It is not.

I'm arguing that you can write that function. What Misdicorl is saying is that it would be

    fn read_line_alloc(&self) -> Result<String>

and not

    fn read_line_alloc(&self) -> Result<&str>

because the &str would be an "use-after-free" situation, and Rust won't let you compile it. You need to allocate if you are reading from a file in order to be able to close (or seek) that file.

yodelshady seems to be under the impression that this means the functionality they want (single method call that doesn't require passing in a buffer) can't be implemented. It can, it just needs to allocate, the same way that you need to explicitly allocate the buffer you pass into read_line.

> A very useful function does not mean you have to use it in the hot path or for huge inputs.

I'm also arguing against it being provided in the stdlib because Rust is big in avoiding "you're holding it wrong" kind of answers, by removing the possibility to hold it wrong. Reasonable people can disagree :)

I've also found it annoying in the past. If Rust didn't have a design goal of giving programmers full control over the behavior of their code, there are several ergonomics changes that we could make to make it much easier to use, but alas, that is not the language we have and we work with what we can make ergonomic and easy to use.

I will say that I agree with almost everything you’ve said on this thread, but we did add std::fs::{read,read_to_string} for files to have this convenience. Adding something for stdin would bring that up to parity.

Somehow I missed/forgot about that addition to the stdlib. I understand why (as evidenced by the requests in this same thread), but it I'm sad it's another thing I have to look for in code reviews ^_^'

Would that work with /dev/stdin on Linux ?

I’d imagine so.

> I'm also arguing against it being provided in the stdlib because Rust is big in avoiding "you're holding it wrong" kind of answers

Even if it was true that Rust is big on that, such a function is not "holding it wrong", it is just a matter of convenience and development speed vs. performance.

For the vast majority of code it does not matter whether you allocate a few times or not. The timing difference is in the noise.

Let Rust be a convenient language rather than a PITA.

Making it return a string would be a mistake for the space rust wants to (first) play in: low level system development. Returning a String requires figuring out what encoding the string has and parsing the contents in that encoding. That's not trivial or cheap or sometimes even possible (not all byte combinations are valid in all encodings) compared to filling a vec of bytes.

That said, it's probably worthwhile to expose the functionality since people would find it useful in a lot of cases

Returning a String is not necessarily a mistake; you could check for UTF-8 validity and error out if the line is not valid UTF-8 - and if you're providing a wrapper for "simple" uses, this might even be the right call. You're right that the general case involves outputing raw bytes, of course.

Re: lifetimes question.

You can solve this in rust just like you can in every other language. By allocating memory in the function and returning the allocation. String, not &str, is what represents that behavior.

&str is kind of a rust wart that only exists because it's so damn useful to provide static text strings in a binary. Every other usage is pretty questionable and should basically be ignored/changed imo

&str is hardly a 'wart'. It's basically a safe version of C++ string_view, and it (together with array slices, which &str is essentially a special case of) is a very good example of the sorts of features that are enabled by Rust's focus on memory safety and close-to-the-metal efficiency.

Those &str use cases are just as easily handled by &String. Perhaps with some extra sugar to slice at a requested boundary.

&String cannot, by itself, handle a substring because it has to point to an (immutable) whole String struct in memory. Any extra syntax or types to package up subslice boundaries would almost certainly end up as something similar to &str, just with potentially different syntax and likely slower.

I think you are incorrect. Exposing a slice of a String as an &String should have no performance impact (pointer and length just like &str). The only thing that becomes interesting is whether you can expose a mutable string slice

At the very least, retrieving data from a &String will involve two pointer lookups (one for the &, one for the internal pointer in the String) whereas plain String and &str involve just one.

In addition, since the String object itself cannot be mutated, a slice like s[10:20] as a &String requires storing the 10 and 20 outside the String and then doing pointer offsets when reading the data. A &str does not need to do this, because the pointer offset happens on creation. Because of this, the &str is also smaller (and this is more efficient because of caches), because it only needs to store a pointer and length (16 bytes, on typical machines), while a &String needs to store at least a pointer to the String and the start/end indices (24 bytes).

One could have various special cases to make &String “work” but it likely ends up being equivalent to &str. The key piece in mind: if one retains the &String name, it makes the language less orthogonal, with more special cases, because taking a reference to a string variable like &s to get a value of type &String behaves very differently to taking a reference to any others like &some_int (of type &i32), which will cause problems in generic code.

What issues arise by aliasing &str and &String to the same (&str) implementation? Does any code actually rely on &String pointing at the String itself rather than the bytes of the string?

Perhaps its more strange/broken to special case &String that it is to have the (imo) warty &str.

Unsafe generic code likely cares, where it is coercing a &T to a *const T and then relying on pointer stability/consistency. It will also cause difficulties with methods like ‘.capacity()’, because that info is lost with &str.

I don't think anyone is saying Rust is easy to learn. They're saying the complexity is justified (mostly).

On looking at my code that does file reads, and steveklabnik's suggestion - Vec<u8> makes reasonable sense. At least that way, if you want nice encodings you've got the same problem agnostic of where the "string" came from.

Aka... a nice abstraction.

read_line returning the number of bytes read instead of the bytes is a C thing. That's just how you do things in C.

Not arguing it's the best way -- and I far prefer the C++ way of returning a string or a buffer -- but it's the C way.

It's how Java's InputStream and Reader work, too. In any language, requiring the caller to supply the buffer is a prerequisite for efficiency.

As the sibling comment said it's not a C thing. It is done that way in C because you have to babysit allocations. Other languages aimed at ease of use will just allocate for you and give you the fully baked contents in a single fn call, but when you're writing code that 1) has to be called often enough where allocations can show up in your flame graphs or 2) the input is big enough that you can't realistically keep the entire thing in memory at once, you suddenly have to care about what the fn is doing internally. Making the default API for file interaction require you pass in your own buffer makes this explicit at the cost of some ease of use. Seeing this will also serve as a teachable moment, when the dev looks at the docs trying to understand why it has such an obtuse API, hopefully coming away with this comment's explanation. This might seem to be a pedantic distinction but I've seen Java codebases where buffer reuse was mandatory in the hot path and Rust is all about removing foot guns.

I agree with you on why it’s done that way in C, and certainly it can be in other languages. No argument there.

But it really is a C thing, because that’s just “how you do it” in C.

Reply on news.ycombinator.com