Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's 2018 roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

151–160 of 253 posts

Re: Rust's 2018 roadmap

#151

Post by burntsushi »

kibwen wrote: post #148
comex wrote: post #134

Earlier quoted context omitted.

The only thing that bothers me is that Rust’s standard library has no good solution for when you do want to take a GIGO position, such as if you need to interoperate over FFI with C/C++ code that does so. There’s Vec , but it’s missing a lot of the convenience methods and other functionality available for strings, and its Debug impl (i.e. string representation for debugging) gives you a list of numbers rather than, s…

> There’s Vec , but it’s missing a lot of the convenience methods and other functionality available for strings This is where you've lost me, because Vec is precisely what one should use in Rust for passing around opaque buffers as you describe. I can't even imagine what sort of convenience methods one could implement on strings that deliberately have no specified representation!

> I can't even imagine what sort of convenience methods one could implement on strings that deliberately have no specified representation!

A lot. Go's `string` type, for example, is conventionally UTF-8 encoded, but it is not enforced. Consider, for example, how much simpler this code[1] could be if `Vec` was more convenient to use as a string type.

There's a reason why the regex crate provides an API for both `&str` and `&[u8]`, because being able to deal with `&[u8]` as if it were a string is occasionally convenient. Importantly, without this API, ripgrep couldn't feasibly exist!

Other examples include file path handling. I need to be able to run globs (via regexes) on them, and the only way I can do that in a way that is zero cost on Unix is to get the bytes from the underlying `&OsStr` (on Windows, I do a lossy decode, which avoids the extra allocation in most places, but still requires the UTF-8 check). In particular, on Unix, this isn't even a matter of performance but rather of correctness, since file paths can contain arbitrary bytes and indeed have no specified representation! (Other than some rules like "no NULs and no /.")

It is often very convenient, in practice, to simply assume UTF-8 or at least an ASCII compatible encoding, rather than enforcing it as an invariant. For example, the link above to the ripgrep config parsing assumes the file contains ASCII-compatible text on Unix, and that's it. The file could contain latin-1 or UTF-8, it doesn't matter, and that is required for correctness. (Because file itself could contain file paths which may be arbitrary bytes.)

(To be clear, I think the UTF-8 invariant for String/&str was the best choice, certainly. What I'm saying here isn't that one should use Vec for strings in lieu of String, but rather, that using Vec as a string can be extremely useful in certain circumstances.)

[1] - https://github.com/BurntSushi/ripgrep/blob/7120f3225862f6c71...

Re: Rust's 2018 roadmap

#152

Post by Agathos »

steveklabnik wrote: post #137
derefr wrote: post #106

Earlier quoted context omitted.

I'm not sure—I think it's more, in this case, that Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. So every resource that teaches Rust couches the discussion in terms of justifying why the particular design being presented is better (from the Rust maintainers' perspective) when compared to designs in existing languages, even if it makes other sacrifices to be suc…

> Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. We don't assume that. From https://doc.rust-lang.org/book/second-edition/ > This book is written for a reader who already knows how to program in at least one programming language. After reading this book, you should be comfortable writing Rust programs. We’ll be learning Rust through small, focused examples that…

I think derefr was inferring (or imagining?) a subconscious need to defend certain decisions, even if C and C++ are not prerequisites.

As a post-structuralist, I generally approve of reading the author's stated intentions and responding, "Yes, well, that's one interpretation." :P

Re: Rust's 2018 roadmap

#153

Post by chmln »

matthewmacleod wrote: post #97
chmln wrote: post #82

Earlier quoted context omitted.

Its all just fluff. Might have something to do with Mozilla being left-leaning. Skin color has nothing to do with non-lexical lifetimes. They will say that they value diversity of thoughts that may come when you have people with various backgrounds, but it is much more primitive in practice, always boiling down to companies acquiring people with certain skin color or gender just for the sake of it. There are well-kno…

The only fluff I’m seeing here is your nonsense about about “taboo” or “uncomfortable truths”, which are usually a hallmark or someone with nudge-nudge-wink-wink dogwhistle objectionable opinion. Let’s make it simple - having a diverse and welcoming community makes a project more attractive to contributors, and means that it’s more likely to succeed in the long term.

> Let’s make it simple - having a diverse and welcoming community makes a project more attractive to contributors, and means that it’s more likely to succeed in the long term.

Sure, I never argued against fostering a welcome environment for contributors. We need more of this especially in open source, where contributions can be sorely lacking.

Instead I question the notion that Rust needs to have some sort or diversity to succeed. The assumption that it does implies that without diversity Rust will fail. However, Rust is not particularly diverse at the moment and it is certainly successful.

Re: Rust's 2018 roadmap

#154

Post by binarycrusader »

steveklabnik wrote: post #137
derefr wrote: post #106

Earlier quoted context omitted.

I'm not sure—I think it's more, in this case, that Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. So every resource that teaches Rust couches the discussion in terms of justifying why the particular design being presented is better (from the Rust maintainers' perspective) when compared to designs in existing languages, even if it makes other sacrifices to be suc…

> Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. We don't assume that. From https://doc.rust-lang.org/book/second-edition/ > This book is written for a reader who already knows how to program in at least one programming language. After reading this book, you should be comfortable writing Rust programs. We’ll be learning Rust through small, focused examples that…

For what it's worth, rust's often introspective approach to documentation and community is one of its defining virtues in my opinion.

Growing up, I was constantly taught new things, without often being taught why. They "why" of things is just as important to me as the "how".

So thanks for all you've done and continue to do!

Re: Rust's 2018 roadmap

#155

Post by steveklabnik »

binarycrusader wrote: post #154
steveklabnik wrote: post #137

Earlier quoted context omitted.

> Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. We don't assume that. From https://doc.rust-lang.org/book/second-edition/ > This book is written for a reader who already knows how to program in at least one programming language. After reading this book, you should be comfortable writing Rust programs. We’ll be learning Rust through small, focused examples that…

For what it's worth, rust's often introspective approach to documentation and community is one of its defining virtues in my opinion. Growing up, I was constantly taught new things, without often being taught why. They "why" of things is just as important to me as the "how". So thanks for all you've done and continue to do!

<3

Re: Rust's 2018 roadmap

#156

Post by comex »

kibwen wrote: post #148
comex wrote: post #134

Earlier quoted context omitted.

The only thing that bothers me is that Rust’s standard library has no good solution for when you do want to take a GIGO position, such as if you need to interoperate over FFI with C/C++ code that does so. There’s Vec , but it’s missing a lot of the convenience methods and other functionality available for strings, and its Debug impl (i.e. string representation for debugging) gives you a list of numbers rather than, s…

> There’s Vec , but it’s missing a lot of the convenience methods and other functionality available for strings This is where you've lost me, because Vec is precisely what one should use in Rust for passing around opaque buffers as you describe. I can't even imagine what sort of convenience methods one could implement on strings that deliberately have no specified representation!

Yeah, my use cases are a combination of burntsushi's and dbaupp's answers.

1. As dbaupp said, there are some convenience methods which don't actually depend on a buffer being any kind of string, and would be just as useful for an &[u8] containing true binary data, or even arbitrary &[T] - yet currently are only implemented for &str. For example, find(), for finding the index of a substring/subsequence.

If that was all I wanted, though, I wouldn't be talking about wanting a separate type. So:

2. As burntsushi said, sometimes you have strings that ought to be UTF-8, but might be invalid. If they're invalid, I don't care about displaying the string correctly, but I still want to be able to round-trip between the source (perhaps an on-disk binary format, perhaps FFI with C/C++) and the native Rust representation, without crashing or doing a lossy conversion.

3. A similar use case is strings that could have any representation… that is a superset of ASCII. For example, this is typically a guarantee for locale character encodings on Unix systems - that is, if you want to properly handle legacy locales rather than just assuming UTF-8 (which reduces to the previous case). It also applies to legacy "text-based" formats and network protocols such as IRC. For some use cases, you'd need to actually know what character encoding is in use and convert between it and Unicode. But for many uses, you only need to locate, replace, split, or join based on known ASCII delimiters. And since the environment locale setting is not necessarily reliable (or in the case of network protocols, isn't meaningful at all), if you can do what you need with that alone, you should. For example, in the case of IRC, a low-level protocol implementation would ideally use byte strings for everything, and outsource the decision of how to decode messages to the client. It's not good enough to make the encoding a configurable setting: even if, say, the client wants to interpret all strings as UTF-8, if someone creates a chat channel whose name is invalid UTF-8, the client should still be able to ask the low-level implementation to join the channel, send messages to it, etc., which requires echoing its name back to the server.

This isn't actually all that different from the pure binary use case, since locating, replacing, splitting, and joining is also useful for arbitrary binary data. Unlike the "possibly invalid UTF-8" use case, you don't want any normal code paths to try to interpret the data as UTF-8. However, it would still be useful if the Debug impl did so.

Re: Rust's 2018 roadmap

#157

Post by derefr »

steveklabnik wrote: post #137
derefr wrote: post #106

Earlier quoted context omitted.

I'm not sure—I think it's more, in this case, that Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. So every resource that teaches Rust couches the discussion in terms of justifying why the particular design being presented is better (from the Rust maintainers' perspective) when compared to designs in existing languages, even if it makes other sacrifices to be suc…

> Rust assumes the developers learning about it have specific goals: namely, to evaluate Rust vs. C/C++. We don't assume that. From https://doc.rust-lang.org/book/second-edition/ > This book is written for a reader who already knows how to program in at least one programming language. After reading this book, you should be comfortable writing Rust programs. We’ll be learning Rust through small, focused examples that…

Sorry if I wasn't clear; I didn't mean to imply that the Rust maintainers assume any prerequisite knowledge of C/C++.

I rather meant that the goal of someone learning Rust "in anger" is for that person to quickly decide if Rust is the best language to use to solve the problem they have. And, if Rust is even a candidate in their solution-space, then usually C and C++ (and sometimes also Go or D or C#) are the other candidates the learner is considering learning. They're Rust's "neighbours" in its solution-space.

And so, Rust's documentation is well-written, but it's well-written specifically for this type of person learning Rust "in anger", with the goal of evaluating the language against its neighbours at the same time they're learning it. Such a person wants to see Rust's design-decision guts spilled out on the floor before them, so they can move on if those decisions are not to their liking.

This doesn't mean the documentation isn't approachable to people who don't have any such points of comparison! But just like a movie can be enjoyable for both kids and adults on different levels, Rust's documentation has both a "teaching you Rust" level and another "justifying Rust's departures from the Average Low-Level Language" level.

Re: Rust's 2018 roadmap

#158

Post by syeaj »

steveklabnik wrote: post #138
squiggleblaz wrote: post #136

Earlier quoted context omitted.

Can you clarify your meaning? I'm a little confused. It sounds like you say "Rust isn't really a beginner's language... it's probably easier to teach [Rust] as a first language than a second after Python or Java". At first it sounds like a contradiction but when I inspect closer I realise there's alternative interpretations. Do you mean "learning a system's programming language is not helped and may even be hindered…

I think your parent is saying "Rust isn't a great language to learn programming with", that is, if you've never programmed, Rust is not a great choice. I agree, but I don't think it's inherent; I think it's a lack of resources targeted at this demographic.

While the book is really top notch (I'm usually not a fan of programming language books), there's something to be said for not introducing all concepts at once. A scripting language has many of the same concepts, but not lifetimes, etc. Not to say objects are intuitive!

Re: Rust's 2018 roadmap

#159

Post by comex »

kibwen wrote: post #145
LambdaComplex wrote: post #142

Earlier quoted context omitted.

OsString isn't Unix-specific. Or am I misunderstanding what you're saying?

I think what they're saying is that because Unix doesn't specify any string encoding at all, you can get GIGO by using OsStr on Unix.

Yes, that's what I meant. Actually, both the Unix variant, "GIGO byte sequence probably UTF-8", and the Windows variant, "GIGO u16 sequence probably UTF-16", have cross-platform use cases. For example, the UTF-16 variant could be used when doing FFI with Java, or when reading Windows filesystems. Therefore, I think ideally Rust would provide both variants as cross-platform types, and OsString/OsStr would just be aliases for one or the other depending on the current platform.

Re: Rust's 2018 roadmap

#160

Post by swfsql »

awestroke wrote: post #121
swfsql wrote: post #85

Earlier quoted context omitted.

I see, but this is still a political issue. Maybe a lot of minorities people just voted "no" in that survey question. Because.. why excluding people based on their skin color is discriminatory, but including people based on their skin color is not discriminatory?

Discrimination, noun: > the unjust or prejudicial treatment of different categories of people, especially on the grounds of race, age, or sex. Is it unjust to make sure people from a minority do not feel alienated?

then this brings a discussion on what "just" is. Does just implies impartiality? if so, different treatment by color would not be just, from what I can understand.

Secondly, one can't be sure that others won't feel alienated. You just put them in a different classification. I would definitely tend to feel alienated..

Post reply on HN