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

101–110 of 253 posts

Re: Rust's 2018 roadmap

#101

Post by Rusky »

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…

It's a systems language. C++ offers the same choices- std::string, std::string_view/char*, etc.

Higher level languages can get away with simplifying this stuff; systems languages can't.

Re: Rust's 2018 roadmap

#102

Post by _pmf_ »

Here's my wishlist for embedded: first class hierarchical state machines, saturated arithmetic, fixed point types. In bare metal scenarios, these are much larger areas of potential errors than any ownership issues, since often, any dynamic allocation is restricted to a mailbox/queue primitive while everything else is statically allocated.

Re: Rust's 2018 roadmap

#103

Post by Rusky »

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.

> 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 charge of the memory it uses- it's only a pointer into some memory that something else owns, whether that's a static allocation or a `String` or some other data structure.

Re: Rust's 2018 roadmap

#104

Post by shmerl »

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…

Do you mean ffi strings?

At the basic level, there are two types, same as let's say C++ offers std::string, and char*.

Strings are really a hard thing to begin with, many languages simply obscure their complexity.

Re: Rust's 2018 roadmap

#105

Post by w4tson »

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

You can get feedback before the compiler kicks in by asking IntelliJ to explicitly define the type.

It’s a trick I used quite a bit when playing about with rust, and Kotlin actually.

Alt + Enter should invoke intentions pop up, you can do it from there. (I think)

Re: Rust's 2018 roadmap

#106

Post by derefr »

sharpercoder wrote: post #68
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…

> [...] 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 such.

I would contrast this to e.g. the Erlang documentation. Erlang/OTP is a great system, and it's well-documented... but the documentation doesn't actually go into the "why" of various choices (e.g. why the BEAM has a module table with exactly two slots per key; why binaries are shared at ≥64 bytes; why clusters are fully connected; etc.)

But I think this makes sense, given the differing approach: unlike Rust, the Erlang/OTP platform is trying to facilitate an abstraction where you just write high-level declarative-ish code, and then improvements to the platform will make that code perform better over time.

Rust documents its decisions because it expects you to be someone who wants to know those things in order to make precisely those decisions (except you're choosing a systems language, rather than designing one.) Erlang leaves most of its internal implementation as a black box, because it expects you to treat it as a black box and derive advantages (in e.g. maintainability) from doing so.

Re: Rust's 2018 roadmap

#107

Post by Rusky »

harpocrates wrote: post #64
pimeys wrote: post #43

I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources. Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time. Don't get me wrong here, I enjoy using Tokio, but I'd say if you're n…

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` and `Future` are generic traits; some instances require `Fn` or `FnMut` while others require `FnOnce`.

And even assuming those problems could be solved, the way do-notation interacts with control flow is not composable with idiomatic Rust. Nested closures prevent the use of return/break/continue and imperative loops; Haskell doesn't have those features so people just lift their functional counterparts into monads. Monad transformer stacks make the situation even worse- they are a pain to compose even with each other, let alone imperative code.

If you want a unifying mechanism for this stuff in Rust it's gonna need to be fundamentally more powerful than monads. Scoped continuations, maybe? Certainly nothing that looks like >>=.

Re: Rust's 2018 roadmap

#108

Post by marshray »

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/

Re: Rust's 2018 roadmap

#109

Post by hsivonen »

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…

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 type doesn't say. In C++17, however, the distinction is present: std::string vs. std::string_view.

It's also great that Rust, unlike C or C++, distinguishes between strings that are valid UTF-8 and strings that came from a kernel that takes a GIGO position on encodings. Got a std::string in C++? Is it UTF-8 or garbage you got from the kernel? You don't know.

Re: Rust's 2018 roadmap

#110

Post by conradev »

pimeys wrote: post #43

I've been spending a good majority of my work hours with Rust and especially writing network services using Tokio. When things work there, it is very reliable, fast and has a tiny footprint with resources. Now reading the promise to get a stable async/await and also having Tokio 0.2 in the pipeline, I'd say async Rust might be ready for prime time. Don't get me wrong here, I enjoy using Tokio, but I'd say if you're n…

> Trouble like a couple of pages of errors, that are just not readable at all

This is indeed very frustrating. I've had to learn to translate between "what the compiler is telling me" and "what the issue actually is".

Post reply on HN