Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's 2017 Roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

141–150 of 274 posts

Re: Rust's 2017 Roadmap

#141

Post by douche »

rspeer wrote: post #140
gcp wrote: post #59

Earlier quoted context omitted.

Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.

Here's a wart. Why is reading lines from a file so hard? It's one of the first things people are going to need to do in a programming language. On top of handling errors (which I understand is necessary, and which the ? operator makes easier), it requires importing BufReader and BufRead, and wrapping a reference to a file handle in BufReader. Nobody is going to know how to do this unless they come across it in Rust B…

That's a good point. It's slightly reminiscent of Haskell, where you have to start trying to understand the IO monad and do notation to do the most trivial real-world examples.

In other languages, you might do File.ReadAllLines("foo.txt"), and bam, you're done.

Re: Rust's 2017 Roadmap

#142

Post by vertex-four »

JoelMcCracken wrote: post #129
vertex-four wrote: post #118

Earlier quoted context omitted.

It's pretty much the reason for segfaults and use-after-free issues (which manifest as either memory corruption or security vulns) in reasonably sized codebases - without a good understanding of ownership, it's non-obvious when a pointer is supposed to become invalid, and if that doesn't match up with when the data is actually freed, you have an issue that's hard to track down later. If you're using a language with g…

Problems involving memory deallocation in the GC applications I've written seem to happen infrequently, certainly infrequently enough that it is one of the lowest items on my list of things I'd like to fix that cause problems in development. > but you can still run into logic errors when part of your code assumes that it's done dealing with a piece of data and another part has a different idea. Mostly I think this is…

Mutable borrows are not shared - you can't touch the data elsewhere while it's borrowed mutably, and you can't get a mutable borrow while there's immutable borrows. Shared state is unfortunately a common affliction on large codebases, and if the language supports and even encourages it, it can be difficult to prevent it from happening as the codebase grows and customers want features that don't fit into the architecture wonderfully.

Re: Rust's 2017 Roadmap

#143

Post by rspeer »

gcp wrote: post #59
ainar-g wrote: post #41

Earlier quoted context omitted.

What about the warts part? Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just - take a random C++/Go/Python developer - ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust - look and take notes on their s…

Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.

Another wart (in a separate post from my other wart so that replies are coherent):

I understand why &str and String are different, but why do they act like they've never heard of each other? Why do they implement such different sets of methods? Why can't they be compared for equality, so I don't always have to type "literal".to_string()?

Haskell has problems with too many string types as well (worse than Rust, because the type of their default string literals is best avoided entirely), but they fix much of the problem with the OverloadedStrings extension, which uses the type checker as something that helps you coerce string literals, instead of arguing with you.

Re: Rust's 2017 Roadmap

#144

Post by e12e »

lmm wrote: post #95
zyxzkz wrote: post #57

Earlier quoted context omitted.

Man, if developing programming languages was this easy, we should have done it years ago!

We did. The ML family has been around for about 4 decades now. Not sure why they never caught on until Rust.

Also: Ada.

Re: Rust's 2017 Roadmap

#145

Post by throwaway91111 »

lmm wrote: post #95
zyxzkz wrote: post #57

Earlier quoted context omitted.

Man, if developing programming languages was this easy, we should have done it years ago!

We did. The ML family has been around for about 4 decades now. Not sure why they never caught on until Rust.

Memory management generally make them unviable for systems coding languages.

Re: Rust's 2017 Roadmap

#146

Post by steveklabnik »

rspeer wrote: post #140
gcp wrote: post #59

Earlier quoted context omitted.

Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.

Here's a wart. Why is reading lines from a file so hard? It's one of the first things people are going to need to do in a programming language. On top of handling errors (which I understand is necessary, and which the ? operator makes easier), it requires importing BufReader and BufRead, and wrapping a reference to a file handle in BufReader. Nobody is going to know how to do this unless they come across it in Rust B…

> Why is reading lines from a file so hard?

It's not so much that it's hard, as is there's lots of options. Can you afford to read it all into memory as a String? Do you need to only read it bit by bit?

> Why is it my job to tell it how to buffer?

Systems langauges need to expose these kinds of details and levels of control.

> Nobody is going to know how to do this

I googled "rust open a file and read by lines" and got these results:

https://users.rust-lang.org/t/read-a-file-line-by-line/1585

https://doc.rust-lang.org/std/io/

https://doc.rust-lang.org/std/fs/struct.File.html

The first two show you directly how, though the first one is dealing with the error message. The last one shows reading it all in. I have some more work to do :)

Re: Rust's 2017 Roadmap

#147

Post by richardwhiuk »

tormeh wrote: post #126
mdzn wrote: post #89

Earlier quoted context omitted.

References (lifetimes and borrow checking) and mutability are there for safety, not speed.

Copying everything every time is a trivial (and very slow) solution to the memory safety problem. It just means that everything is on the stack (or at least that only one stack frame has a reference to any given object), so it is simply deallocated along with the stack frame. That's it. There's nothing unsafe about it. What do you mean by saying mutability is for safety? That's a very unusual opinion.

Explicitly tracking shared mutability is for safety - obviously not mutability in of itself.

Copying everything every time isn't a solution in a multithreaded world if you actually want your threads to share data.

Re: Rust's 2017 Roadmap

#148

Post by rspeer »

steveklabnik wrote: post #146
rspeer wrote: post #140

Earlier quoted context omitted.

Here's a wart. Why is reading lines from a file so hard? It's one of the first things people are going to need to do in a programming language. On top of handling errors (which I understand is necessary, and which the ? operator makes easier), it requires importing BufReader and BufRead, and wrapping a reference to a file handle in BufReader. Nobody is going to know how to do this unless they come across it in Rust B…

> Why is reading lines from a file so hard? It's not so much that it's hard, as is there's lots of options. Can you afford to read it all into memory as a String? Do you need to only read it bit by bit? > Why is it my job to tell it how to buffer? Systems langauges need to expose these kinds of details and levels of control. > Nobody is going to know how to do this I googled "rust open a file and read by lines" and g…

It would be silly and wasteful to read the whole file into memory just so I can iterate its lines. I'm not sure why that's an option you'd need to accomodate.

However, many languages make a reasonable assumption that you can afford to fit each line in memory, and provide an obvious way to do this.

Re: Rust's 2017 Roadmap

#149

Post by steveklabnik »

rspeer wrote: post #143
gcp wrote: post #59

Earlier quoted context omitted.

Given the number of Rust developers reading this, it's probably going to be very helpful for them if you can describe what you actually got hung up on.

Another wart (in a separate post from my other wart so that replies are coherent): I understand why &str and String are different, but why do they act like they've never heard of each other? Why do they implement such different sets of methods? Why can't they be compared for equality, so I don't always have to type "literal".to_string()? Haskell has problems with too many string types as well (worse than Rust, becaus…

> Why do they implement such different sets of methods?

String gets all relevant str methods from Deref; it has some additional methods, but it should largely be shared.

> Why can't they be compared for equality,

Hm? They both compare just fine with ==.

Re: Rust's 2017 Roadmap

#150

Post by steveklabnik »

rspeer wrote: post #148
steveklabnik wrote: post #146

Earlier quoted context omitted.

> Why is reading lines from a file so hard? It's not so much that it's hard, as is there's lots of options. Can you afford to read it all into memory as a String? Do you need to only read it bit by bit? > Why is it my job to tell it how to buffer? Systems langauges need to expose these kinds of details and levels of control. > Nobody is going to know how to do this I googled "rust open a file and read by lines" and g…

It would be silly and wasteful to read the whole file into memory just so I can iterate its lines. I'm not sure why that's an option you'd need to accomodate. However, many languages make a reasonable assumption that you can afford to fit each line in memory, and provide an obvious way to do this.

> I'm not sure why that's an option you'd need to accomodate.

Again, it's about control. Maybe you're only loading a small configuration file, and so fetching it all in one go is better than dealing with a buffer.

> an obvious way to do this.

If you search for 'line' or 'lines' in rustdoc, the correct thing is right near the top, which will show you how to use it with BufRead.

Post reply on HN