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

181–190 of 274 posts

Re: Rust's 2017 Roadmap

#181

Post by comex »

rspeer wrote: post #160
dbaupp wrote: post #155

Earlier quoted context omitted.

String == &str works. Maybe you were encountering some other problem.

Oh, I guess the case of this I encountered most recently was actually Option == Option . I get why that's different, but it would be great if the type system could figure that out, so that the literal Some("foo") could be an Option if necessary. Maybe I'm still being spoiled by Haskell's OverloadedStrings.

Nitpick: if you have a String and a &str, you want to convert the first to the second, not the other way around. Strings are owned, so &str to String does an allocation and copy of the bytes, while String to &str is a trivial operation that just throws away the capacity field.

But yeah, it would be nice if Rust had better ergonomics regarding coercing the insides of wrapper types. Though I'm not sure how exactly that would work.

Re: Rust's 2017 Roadmap

#182

Post by comex »

pjungwir wrote: post #180
steveklabnik wrote: post #47

Earlier quoted context omitted.

> What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sampl…

So I'm only a Rust amateur (I mean I don't get paid to use it), but I'm on my third round trying to build something with it, and I feel like I'm finally starting to get it. A couple warts I've encountered: - No support for default struct fields: https://github.com/rust-lang/rfcs/issues/1594 - Terrible signatures for functions that return iterators: https://www.reddit.com/r/rust/comments/2h26cj/functions_retu... If th…

A feature designed as a fix for the second problem is already in nightly:

https://github.com/rust-lang/rust/issues/34511

Who knows when it'll be stabilized, though.

Re: Rust's 2017 Roadmap

#183

Post by SkyMarshal »

e12e wrote: post #144
lmm wrote: post #95

Earlier quoted context omitted.

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

Also: Ada.

This is the real comparison, the only other systems language besides Rust that provides both safety and manual memory management. Ada does it via Access Types:

https://en.wikibooks.org/wiki/Ada_Programming/Types/access#W...

Re: Rust's 2017 Roadmap

#184

Post by int_19h »

dripton wrote: post #152
douche wrote: post #141

Earlier quoted context omitted.

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.

Unless foo.txt is too big, in which case, bam, out of memory.

In C# (from which the original example is), these days - and for like 6 years now - what you do is File.ReadLines, and you get a lazy enumerator.

Re: Rust's 2017 Roadmap

#185

Post by iopq »

dbaupp wrote: post #73
Animats wrote: post #18

Earlier quoted context omitted.

Rust needs a Rust book not written by the Rust developers. "Rust for Dummies", if you will.

Why couldn't Rust's developers write "Rust for Dummies"? I feel like you're connecting dots that aren't actually connected. Obviously having more books from different authors/perspectives is great for Rust, but I don't see, prima facie, why a non-Rust-developer author would do a better job of "Rust for Dummies" than a Rust developer. For one, I would be surprised if a non-"expert" (which is, I presume, why you're so…

Just look at K&R. It's so... bland and boring. As a 13-year-old I couldn't keep reading it.

Re: Rust's 2017 Roadmap

#186

Post by int_19h »

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…

In higher-level languages, object lifetime is more than just whether the memory is there or not; it's also about whether the usual invariants apply.

For example, in C#, you need to Dispose() objects that are logically no longer used, to have them properly cleaned up. Using an object after it's disposed typically results in an ObjectDisposedException. This isn't as bad as a segfault, but ultimately it's still a crashing bug in the app - and solving it requires figuring out who needs to call Dispose when - i.e. figuring out the lifetime.

Re: Rust's 2017 Roadmap

#187

Post by pjmlp »

throwaway91111 wrote: post #145
lmm wrote: post #95

Earlier quoted context omitted.

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.

There is more to systems coding than writing OSes, compilers and linkers for example.

There having a GC is perfectly fine.

Re: Rust's 2017 Roadmap

#188

Post by iopq »

Manishearth wrote: post #35
XorNot wrote: post #14

Earlier quoted context omitted.

I would say random numbers are a fairly core programming construct for a standard library. They're important, difficult to get right, and have huge implications if you get them wrong.

This doesn't answer my question, though. Most of the "fairly core programming constructs" are not in the stdlib for Rust (like regexes) The Rust stdlib is mostly core abstractions and platform-dependent stuff. Given that, why should they be in the stdlib? The rand crate is officially blessed and the one everyone uses.

You can't use rand in play.rust-lang.org so it's hard to get help from IRC since they can't get your error messages easily and fix them.

Re: Rust's 2017 Roadmap

#189

Post by aldanor »

sgentle wrote: post #99

I'm very excited about improvements to the maturity of the Rust library ecosystem. I'm happy with Rust's syntax, the borrow checker doesn't bother me that much, and the build tooling works well (though more speed would definitely help). What it comes down to again and again with projects I think about using Rust for is "how much extra effort is it going to be compared to a language with good libraries for this?" Ofte…

FYI, serde derive macros already run on stable, since 1.15 :)

Re: Rust's 2017 Roadmap

#190

Post by mook »

Manishearth wrote: post #178
sevensor wrote: post #165

Earlier quoted context omitted.

It speaks to my confusion about the role of these "blessed" crates that I assumed the reason for not including them in the standard library was that they were not supported on all platforms, or that you didn't want to commit to having them in stdlib forever. If neither of these is the reason, and you intend for these crates to persist indefinitely and be available on all supported platforms, surely they belong in the…

The idea is that these can evolve separately from the language; they are not tied to language versions. Contrast that with Python where you have the urllib urllib2 urllib3 issue; with people going and using requests anyway. There's no inherent reason to put them in the stdlib aside from "other languages do it". And yeah, folks don't want to commit to sticking them in the stdlib forever. If a better library turns up p…

The Python urllib/urllib2 issue is a feature. It means any code that uses the old (inferior) urllib continues to work, without having to update it as urllib2 starts being used within the same function so that it can be migrated. That's what promising stability means.

This applies to your last paragraph as well -- I do want to be using code that folks are trusting to be the way to do things forever (well, at least for a few years). I'm not trying to learn yet another CADT language / ecosystem.

Also note that both crates mentioned in this subthread (regex and rand) are at version 0.x; to a not-really-a-rust-person like me, it signals "experimental API, avoid avoid avoid". I assume that is the reason to start a concerted effort to get everything to 1.0 levels.

(I'm mostly commenting because the roadmap under discussion seems to be heading towards the sort of promised stability that I want to see; so having somebody known to be rather close to rust development saying the exact opposite rather unsettles me. Sorry.)

Post reply on HN