Rust's 2018 roadmap • Hacker News Board

Re: Rust's 2018 roadmap

#91

Post by jhoechtl » Mon, Mar 12, 2018, 8:03 PM UTC

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 chapter you mentioned, strings, which drew me away from rust in disgust. Four string types ... for the beginner? Seriously?

Re: Rust's 2018 roadmap

#92

Post by pcwalton » Mon, Mar 12, 2018, 8:03 PM UTC

pknopf wrote: post #19

the_mitsuhiko wrote: post #15

Earlier quoted context omitted.

Since JS and Go do not have the same GC you have the same issue there.

GC's have some kind of inherit reference counting which makes releasing pointers safe, in any direction. You can't do that with C/C++ without something like glib.

No major JS implementation uses naive reference counting, because there's no way to break cycles. Cycle collection requires the ability to trace the heap globally. But the JS engine does not have any way to see inside a wasm heap.

Re: Rust's 2018 roadmap

#93

Post by AceJohnny2 » Mon, Mar 12, 2018, 8:05 PM UTC

> Embedded devices

I'm excited about this. In my experience, embedded (and by extension, a large part of kernel/driver programming) is the last stronghold of C, because it's a place where you really need fine-grained control of your environment and C gives you that by default.

It's my day-to-day workhorse, and I often feel like I'm stuck in the dark ages still dealing with issues of tooling and expressiveness that CS has solved long ago. Free me!

Re: Rust's 2018 roadmap

#94

Post by jhoechtl » Mon, Mar 12, 2018, 8:05 PM UTC

steveklabnik wrote: post #58

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…

So, two things: > Heres just hoping that Mozilla is prepared Rust is an open source project Mozilla contributes to heavily, it's not a Mozilla project. This is the Rust project's problem, not Mozilla's problem. (For example, Mozilla employees, of which I am one, are a minority in governance these days. We're the largest single group of people by employer, but are at 50% representation on the core team and are somethi…

>> Heres just hoping that Mozilla is prepared

> Rust is an open source project

So is Perl6

Re: Rust's 2018 roadmap

#95

Post by matthewmacleod » Mon, Mar 12, 2018, 8:14 PM UTC

swfsql wrote: post #85

nemothekid wrote: post #81

Earlier quoted context omitted.

It's less about goals of the technical project, and more about goals of the organization. Rust the language is written by people, The Rust Team, most of whom I'd imagine are volunteers. In order to guarantee the life of the project, its important for potential contributors to not only feel comfortable using the language and writing code, but also feel comfortable in discussing the future potential features and use ca…

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?

You’ve described something that isn’t happening and won’t happen.

Re: Rust's 2018 roadmap

#96

Post by baq » Mon, Mar 12, 2018, 8:15 PM UTC

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…

Rust in general isn't really a beginner's language. You have to understand computers at a very low level to appreciate the design choices. Given some dedication, it'll help you at that but it's not easy, especially if you already know some higher level languages. It's probably easier to teach it as a first language than a second after Python or Java.

Re: Rust's 2018 roadmap

#97

Post by matthewmacleod » Mon, Mar 12, 2018, 8:17 PM UTC

chmln wrote: post #82

swfsql wrote: post #79

I'm an average programmer, but I honestly don't get the goal of inclusiveness [edit: from the Rust 2017 Survey Results] > Diversity and inclusiveness continue to be vital goals for the Rust project at all levels. I mean.. lifetime checks won't stop working if you don't consider yourself heterosexual or anything o.O The two matters simply don't mix in my head

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.

Re: Rust's 2018 roadmap

#98

Post by neurotrace » Mon, Mar 12, 2018, 8:17 PM UTC

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…

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.

Re: Rust's 2018 roadmap

#99

Post by apendleton » Mon, Mar 12, 2018, 8:18 PM UTC

lmkg wrote: post #80

steveklabnik wrote: post #58

Earlier quoted context omitted.

So, two things: > Heres just hoping that Mozilla is prepared Rust is an open source project Mozilla contributes to heavily, it's not a Mozilla project. This is the Rust project's problem, not Mozilla's problem. (For example, Mozilla employees, of which I am one, are a minority in governance these days. We're the largest single group of people by employer, but are at 50% representation on the core team and are somethi…

Is MIR being treated as part of the language definition? Most languages would treat such a thing as an implementation detail, so defining the constraints in that fashion seems like it still looks like it may tie you to the reference implementation.

My maybe-wrong sense was more than the MIR could change from one compiler release to the next, but that the editions couldn't introduce language changes that would require any given release of the compiler to have to produce MIR of a different kind for code of one edition vs. another. You'll be able to compile a single binary relying on different libraries pinned to different editions, and I think the idea is that from the MIR stage of the build onward, whatever differences may exist (e.g., a reserved word in one edition might be a function name in another) have to be papered over so that whole-program optimization/compilation can occur.

Re: Rust's 2018 roadmap

#100

Post by m0meni » Mon, Mar 12, 2018, 8:24 PM UTC

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…

Your comment is confusing because they only mention two common string types, and then clearly explain the difference between the two (coming from someone who doesn't write any rust):

> We’ll first define what we mean by the term string. Rust has only one string type in the core language, which is the string slice str that is usually seen in its borrowed form &str. In Chapter 4, we talked about string slices, which are references to some UTF-8 encoded string data stored elsewhere. String literals, for example, are stored in the binary output of the program and are therefore string slices.

> The String type is provided in Rust’s standard library rather than coded into the core language and is a growable, mutable, owned, UTF-8 encoded string type. When Rustaceans refer to “strings” in Rust, they usually mean the String and the string slice &str types, not just one of those types. Although this section is largely about String, both types are used heavily in Rust’s standard library and both String and string slices are UTF-8 encoded.