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

131–140 of 253 posts

Re: Rust's 2018 roadmap

#131

Post by andrewaylett »

Rusky wrote: post #107
harpocrates wrote: post #64

Earlier quoted context omitted.

You've changed my mind on adding special syntax for `async`, generators, and results (`?`). I previously thought it was a big mistake given that these all generalize as monads (granted, there is some ground to be covered before such an abstraction would fit in Rust). What I hadn't considered: specialized syntax leads to better error messages for the most common cases. That's probably quite a good thing, especially si…

> (granted, there is some ground to be covered before such an abstraction would fit in Rust) I would claim that such an abstraction is fundamentally incompatible with Rust. Not only does Rust lack the means to write a Monad trait on which to build do-notation, but even given HKT there's no single type signature that the various monad instances would fit. `Result` and `Option` are type constructors while `Iterator` an…

You don't need do-notation to use Monads, that's just useful for building up a lazy-evaluated data-structure describing what IO to perform.

Java and Javascript, for example, have been gradually introducing monadic concepts into their ecosystems. Java collections and Futures grow 'of' and 'flatMap', JS Promises aren't quite purely monadic but have 'resolve' and 'then'. So it's perfectly possible for an imperative language to use monadic features to implement async operations.

But much as I enjoy using JS Promises (really!) I prefer ES6 async/await, even though it's just syntactic sugar. Not least because even fairly straightforward-looking async/await code can desugar to something you wouldn't want to try to read by hand.

Re: Rust's 2018 roadmap

#132

Post by Rusky »

andrewaylett wrote: post #131
Rusky wrote: post #107

Earlier quoted context omitted.

> (granted, there is some ground to be covered before such an abstraction would fit in Rust) I would claim that such an abstraction is fundamentally incompatible with Rust. Not only does Rust lack the means to write a Monad trait on which to build do-notation, but even given HKT there's no single type signature that the various monad instances would fit. `Result` and `Option` are type constructors while `Iterator` an…

You don't need do-notation to use Monads, that's just useful for building up a lazy-evaluated data-structure describing what IO to perform. Java and Javascript, for example, have been gradually introducing monadic concepts into their ecosystems. Java collections and Futures grow 'of' and 'flatMap', JS Promises aren't quite purely monadic but have 'resolve' and 'then'. So it's perfectly possible for an imperative lang…

I'm... not sure what you're getting at here. Rust is chock-full of "monadic concepts" like that, including the entire sets of `Iterator` and `Future` combinators. (Note that even without do-notation these have the composability problems I mention- you can't, for example, `break` out of a loop from within a `.then` callback; you have to break the loop down and reimplement it yourself with recursion. This is what the async/await "sugar" helps with- makes normal control structures compose with async code.)

What I'm talking about is a single Monad abstraction to tie these all together. I mention do-notation because it's one example of something you would built on top of such an abstraction, and one way to bring together the seemingly-disparate collection of `?`/`yield`/`await!`. In Haskell, for example, you can use do-notation not only for IO, but also for async code, and list comprehensions, and early returns, and a host of other things.

Re: Rust's 2018 roadmap

#133

Post by [deleted] »

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…

[deleted]

Re: Rust's 2018 roadmap

#134

Post by comex »

hsivonen wrote: post #109
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…

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, say, a best-effort UTF-8 interpretation. There’s also OsString on Unix, but that’s OS-specific and also is missing functionality. Unsurprisingly, there’s a third-party crate that has the functionality what I want, and thanks to Cargo that’s almost as good as it being in the standard library… but I still want there to be something in the standard library. :)

Re: Rust's 2018 roadmap

#135

Post by agumonkey »

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…

I wish all contributors and lead of Rust to have the best collaboration (and hopefully success in solving problems at hand) in the future. It's not perfect, but it's such a nice idea/language.

Re: Rust's 2018 roadmap

#136

Post by squiggleblaz »

baq wrote: post #96
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…

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.

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 by experience with general purpose languages"? Are there any good beginners' systems languages, which help Rust?

Re: Rust's 2018 roadmap

#137

Post by steveklabnik »

derefr wrote: post #106
sharpercoder wrote: post #68

Earlier quoted context omitted.

> [...] include actual reasoning about why things are how they are in Rust and that they seem pretty open about drawbacks of the choices. This trait of documentation (the "why" & openly discussing pros and cons) seems to be a property of great systems being well-documented.

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 build on each other to demonstrate how to use various features of Rust as well as how they work behind the scenes.

That is, we assume programming knowledge, but not specific programming knowledge. Many people come to Rust not knowing C or C++.

Re: Rust's 2018 roadmap

#138

Post by steveklabnik »

squiggleblaz wrote: post #136
baq wrote: post #96

Earlier quoted context omitted.

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.

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.

Re: Rust's 2018 roadmap

#139

Post by steveklabnik »

agumonkey wrote: post #135
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…

I wish all contributors and lead of Rust to have the best collaboration (and hopefully success in solving problems at hand) in the future. It's not perfect, but it's such a nice idea/language.

Thank you! <3

Re: Rust's 2018 roadmap

#140

Post by jhasse »

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?

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