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

111–120 of 253 posts

Re: Rust's 2018 roadmap

#111

Post by kibwen »

neurotrace wrote: post #98
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…

Where are you seeing four string types? As far as I know, there's only `String` and `str`. Heap allocated vs. stack/statically allocated. There's also things like `CString` and `OsString` but I don't think I've had to deal with those. If so, it was so similar to working with any other string that I didn't even notice. I'm still relatively new to Rust but this is my understanding. Please correct me if I'm wrong.

There are two string types in Rust: String and &str. The CString and OsString types only exist for FFI and platform-dependent interop (because unlike Rust's string types, there's no guarantee that the rest of the world is UTF8-encoded). The only time you'd use CString and OsString (or see them get used) is at the very edges of your system, and you'd convert them into String or &str as soon as possible (or Vec, but that's hardly a "string type").

Re: Rust's 2018 roadmap

#112

Post by smoe »

jhoechtl wrote: post #91
smoe wrote: post #65

I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…

> 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…

I'm coming mostly from Python for web development, so I haven't spent much time of my life thinking about strings. But I also usually have not really any clue what is going on under the hood when working with them. Which is fine, because most of the time it doesn't matter (as long as you don't do a+b+c... too much) in my work.

What I like about the page is not that it makes strings easy to understand for a beginner, but that it doesn't hide difficulties about strings, that there are different ways to look at them and Rust doesn't presume a certain one. They say it isn't easy, then go on explaining why.

To me this makes the steep learning curve feel justified. Where as some other language tutorials brush away any difficulty by saying "you don't need to understand that, just trust us."

This is also a matter of perspective. I'm not looking at Rust for general web development (at least not as main language) but for more lower level stuff I want to get into. And least to me as a beginner in that domain it sounds very believable that those distinctions matter in that context

Re: Rust's 2018 roadmap

#113

Post by pimeys »

fnord77 wrote: post #76
Shoothe wrote: post #75

> Tooling improvements For me that's the biggest issue currently with Rust. Type inference via "let" only makes it harder as I can't really know what type a certain variable or expression is without carefully tracking docs. I've tried two Rust plug-ins for VS Code and even though they installed required dependencies I still couldn't have proper list of members when pressing "dot" and without that I feel like programm…

intellij's rust plugin is pretty good at type interference. Also sometimes I just let the compiler tell me by forcing the let variable to something that it is obviously not: `let not_a_string: String = get_something_that_I_have_no_idea();` error [4242]: expected type String, found type &*YouWouldNeverHaveGuessed

This works quite well, until you're dealing with stuff such as `AndThen` with 10 different nested futures. Here, again, async/await will be a great help.

Re: Rust's 2018 roadmap

#114

Post by krylon »

Okay, after two failed attempts (mainly due to lack of motivation, I hasten to admit), I think it's time for me to learn me some Rust.

I spent a long time working mostly with dynamically typed languages, but over the past few years, I have slowly drifted back into statically typed territories. At home, I have used Go a lot, at work, I have grown to like C#. Rust kind of looks like the next logical step along that trajectory, doesn't it?

And I get the impression that people who took the time to learn Rust enjoyed it very much. So here's my delayed new-year's resolution (I am the ____ing king of procrastination!): I am going to learn Rust and I am going to like it (I hope)!

Re: Rust's 2018 roadmap

#115

Post by dragonwriter »

marshray wrote: post #108
zanny wrote: post #52

Heres just hoping that Mozilla is prepared to take responsibility for what they are trying to accomplish in the long haul. A lot of companies have tried to make products that are both infinitely backwards compatible and always supported while still introducing breaking changes like this. It quickly becomes a giant internal mess of trying to figure out what the most common denominator of feature requirements to implem…

> C++ had an era of malaise where conflicting implementations of the standard library across a dozen+ platforms led to the complete abandonment of it by the mid 2000s What are you talking about? C++ has continually been in the top 5 on the TIOBE list. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/cplusplus/

GP seems to be talking about abandonment of the C++ standard library, not abandonment of C++ language.

Re: Rust's 2018 roadmap

#116

Post by neurotrace »

Rusky wrote: post #103
neurotrace wrote: post #98

Earlier quoted context omitted.

Where are you seeing four string types? As far as I know, there's only `String` and `str`. Heap allocated vs. stack/statically allocated. There's also things like `CString` and `OsString` but I don't think I've had to deal with those. If so, it was so similar to working with any other string that I didn't even notice. I'm still relatively new to Rust but this is my understanding. Please correct me if I'm wrong.

> Heap allocated vs. stack/statically allocated. `str` is very rarely stack allocated, and often points into a heap-allocated `String`. Further, there's an optimization on the table that will let `String`s point to static allocations. The distinction is rather owned vs borrowed. A `String` is in charge of the memory it uses, so it can grow it by reallocation, free it when it goes out of scope, etc. A `str` is not in…

Ahhh, that makes a lot of sense. Thanks for the correction.

Re: Rust's 2018 roadmap

#117

Post by marshray »

dragonwriter wrote: post #115
marshray wrote: post #108

Earlier quoted context omitted.

> C++ had an era of malaise where conflicting implementations of the standard library across a dozen+ platforms led to the complete abandonment of it by the mid 2000s What are you talking about? C++ has continually been in the top 5 on the TIOBE list. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/cplusplus/

GP seems to be talking about abandonment of the C++ standard library , not abandonment of C++ language .

Strange. I have been continuously employed developing in mostly C++ since the 1993 and have only ever seen increasing adoption of the C++ standard library.

Re: Rust's 2018 roadmap

#118

Post by kibwen »

marshray wrote: post #108
zanny wrote: post #52

Heres just hoping that Mozilla is prepared to take responsibility for what they are trying to accomplish in the long haul. A lot of companies have tried to make products that are both infinitely backwards compatible and always supported while still introducing breaking changes like this. It quickly becomes a giant internal mess of trying to figure out what the most common denominator of feature requirements to implem…

> C++ had an era of malaise where conflicting implementations of the standard library across a dozen+ platforms led to the complete abandonment of it by the mid 2000s What are you talking about? C++ has continually been in the top 5 on the TIOBE list. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/cplusplus/

I'm loathe to dignify TIOBE with analysis, but even by TIOBE's own numbers C++ has fallen from 15% in 2001-2004, to 10% in 2005-2013, to 5% in 2013-2018. And given that C++ was ranked #2 as early as 1993, even the era of 15% was likely a fall from an earlier height. Compare C, which has held steady since 2001 (with the exception of that huge anomalous dip last year which is being corrected (and which caused C to trigger TIOBE's "language of the year" despite having hugely fallen in TIOBE's own rankings, which helps illustrate how little regard we ought to give TIOBE).

Re: Rust's 2018 roadmap

#119

Post by kibwen »

krylon wrote: post #114

Okay, after two failed attempts (mainly due to lack of motivation, I hasten to admit), I think it's time for me to learn me some Rust. I spent a long time working mostly with dynamically typed languages, but over the past few years, I have slowly drifted back into statically typed territories. At home, I have used Go a lot, at work, I have grown to like C#. Rust kind of looks like the next logical step along that tra…

If you have any questions, feel free to come ask at /r/rust, where we strive to be moderately less of a shithole than reddit in general. :)

Re: Rust's 2018 roadmap

#120

Post by eeereerews »

Rusky wrote: post #103
neurotrace wrote: post #98

Earlier quoted context omitted.

Where are you seeing four string types? As far as I know, there's only `String` and `str`. Heap allocated vs. stack/statically allocated. There's also things like `CString` and `OsString` but I don't think I've had to deal with those. If so, it was so similar to working with any other string that I didn't even notice. I'm still relatively new to Rust but this is my understanding. Please correct me if I'm wrong.

> Heap allocated vs. stack/statically allocated. `str` is very rarely stack allocated, and often points into a heap-allocated `String`. Further, there's an optimization on the table that will let `String`s point to static allocations. The distinction is rather owned vs borrowed. A `String` is in charge of the memory it uses, so it can grow it by reallocation, free it when it goes out of scope, etc. A `str` is not in…

A `str` is just an unsized blob of UTF-8 data. It's `&str` that is the (fat) pointer.
Post reply on HN