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

141–150 of 253 posts

Re: Rust's 2018 roadmap

#141

Post by jhasse »

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.

Could also be correlation: Projects succeeding in the long term attract diverse and welcoming communities.

Re: Rust's 2018 roadmap

#142

Post by LambdaComplex »

comex wrote: post #134
hsivonen wrote: post #109

Earlier quoted context omitted.

There are way more than 4, but each one makes sense and has a purpose. Trying to conflate them would make things conceptually less clear. Also, somehow people seem to object less to Vec vs. &[T] than String vs. &str. It's great that owned string with contents on the heap is clearly distinguished from a borrowed view into a string. In C, when you see a char*, do you own the string or are you borrowing a string? The ty…

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…

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

Re: Rust's 2018 roadmap

#143

Post by saghm »

comex wrote: post #134
hsivonen wrote: post #109

Earlier quoted context omitted.

There are way more than 4, but each one makes sense and has a purpose. Trying to conflate them would make things conceptually less clear. Also, somehow people seem to object less to Vec vs. &[T] than String vs. &str. It's great that owned string with contents on the heap is clearly distinguished from a borrowed view into a string. In C, when you see a char*, do you own the string or are you borrowing a string? The ty…

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…

Naive question from someone who's never written FFI code: does std::ffi::CString work here, or is the issue that you need to be able to have null bytes within the string?

Re: Rust's 2018 roadmap

#144

Post by saghm »

steveklabnik wrote: post #122
jhoechtl wrote: post #91

Earlier quoted context omitted.

> An example for this is the lengthy page on Strings: https://doc.rust-lang.org/book/second-edition/ch08-02-string... . I don't know how the 2nd edition of the book deviates from the first one, but as you mention the strings section: I had installed rust with rustup, configured my editor environment, bookmarked and read tutorials and was serious about learning rust, dabbling with code snippets. It was the exact chapt…

The second edition is completely re-written. We had a discussion on the strings thing the other day: https://news.ycombinator.com/threads?id=steveklabnik&next=16... TL;DR, the language only has one string type. The stdlib has more. They’re all needed. Strings are hard.

The link you posted seems to show all of your recent comments, the most recent of which is not related to strings. Did you mean to link this? https://news.ycombinator.com/item?id=16546910

Re: Rust's 2018 roadmap

#145

Post by kibwen »

LambdaComplex wrote: post #142
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…

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.

Re: Rust's 2018 roadmap

#146

Post by steveklabnik »

saghm wrote: post #144
steveklabnik wrote: post #122

Earlier quoted context omitted.

The second edition is completely re-written. We had a discussion on the strings thing the other day: https://news.ycombinator.com/threads?id=steveklabnik&next=16... TL;DR, the language only has one string type. The stdlib has more. They’re all needed. Strings are hard.

The link you posted seems to show all of your recent comments, the most recent of which is not related to strings. Did you mean to link this? https://news.ycombinator.com/item?id=16546910

I did, sigh. I was on mobile, must have messed it up. Thank you.

Re: Rust's 2018 roadmap

#147

Post by kibwen »

saghm wrote: post #143
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…

Naive question from someone who's never written FFI code: does std::ffi::CString work here, or is the issue that you need to be able to have null bytes within the string?

Looking at the docs for CString (https://doc.rust-lang.org/std/ffi/struct.CString.html):

"An instance of this type is a static guarantee that the underlying bytes contain no interior 0 bytes ("nul characters") and that the final byte is 0 ("nul terminator")."

The functions that create CStrings also return a Result where you'll get an Err if your string contains any nul bytes. There's are unsafe variants that don't do these checks, but it's hard to predict what might break if this invariant isn't upheld. There's not much reason to use CString rather than just Vec.

Re: Rust's 2018 roadmap

#148

Post by kibwen »

comex wrote: post #134
hsivonen wrote: post #109

Earlier quoted context omitted.

There are way more than 4, but each one makes sense and has a purpose. Trying to conflate them would make things conceptually less clear. Also, somehow people seem to object less to Vec vs. &[T] than String vs. &str. It's great that owned string with contents on the heap is clearly distinguished from a borrowed view into a string. In C, when you see a char*, do you own the string or are you borrowing a string? The ty…

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!

Re: Rust's 2018 roadmap

#149

Post by Rusky »

jhasse wrote: post #140
awestroke wrote: post #121

Earlier quoted context omitted.

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?

Yes, you should instead make sure everyone doesn't feel alienated, not only the people from a minority regarding their race, age or sex.

That... does seem to be the goal.

Re: Rust's 2018 roadmap

#150

Post by dbaupp »

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!

One might have strings that have unspecified, but identical, representations, meaning one can do things like 'split' and 'replace' (in general, Vec/&[] doesn't have great tools for operating on subslices, like those two string functions: essentially just 'chunks' and 'windows').
Post reply on HN