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

81–90 of 253 posts

Re: Rust's 2018 roadmap

#81

Post by nemothekid »

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

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 cases for the language.

It is important for projects, now, to state their goals upfront and be clear, especially when you could have 1000s of contributors from all over the world. This is something that's new for software projects, but as open source becomes larger and more diverse its becoming more necessary. The alternative has been a community based loosely around some invisible set of rules that alienates or drives away potential contributors or sparks some drama that ends up on the top of Reddit/HN/etc.

Lifetime checks will stop working if the project gets abandoned over political issues.

Re: Rust's 2018 roadmap

#82

Post by chmln »

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-known but taboo reasons behind the lack of so-called diversity in tech and other highly intellectually demanding areas. And as long as uncomfortable truth cannot come out in the overly sensitive cultural climate of today, initiatives and policies in this direction will remain misguided.

Re: Rust's 2018 roadmap

#83

Post by Shoothe »

tototomtoboro wrote: post #77
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…

Have you tried https://marketplace.visualstudio.com/items?itemName=rust-lan... ? You will need the rls from nightly but its working very nicely for me.

Nope, I'll try that out tomorrow, thanks for the advice!

VS Code's handling of TypeScript really spoiled me but on the other hand it seems like tooling becomes more and more important in programming languages (e.g. Roslyn).

Re: Rust's 2018 roadmap

#84

Post by Shoothe »

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

> Also sometimes I just let the compiler tell me by forcing the let variable to something that it is obviously not:

Ha! Very clever! Thanks.

Re: Rust's 2018 roadmap

#85

Post by swfsql »

nemothekid wrote: post #81
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

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?

Re: Rust's 2018 roadmap

#86

Post by [deleted] »

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

[deleted]

Re: Rust's 2018 roadmap

#87

Post by harpocrates »

gilmi wrote: post #73
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…

> a common problem I have in Haskell is figuring out _which_ monad a certain `do` block is using. Does type signatures not help in that case?

Yes, when people use them. There is no really elegant way of adding a type annotation to a `do` block.

    (do x
It isn't uncommon to have to scan the `do` block for some statement that constrains the monad somehow.

This is a known and discussed problem, so I'll refer you to the article usually reference around this issue: https://wiki.haskell.org/Do_notation_considered_harmful

Re: Rust's 2018 roadmap

#88

Post by tatterdemalion »

Ygg2 wrote: post #53
kibwen wrote: post #11

Earlier quoted context omitted.

The tracking issue for const generics is here: https://github.com/rust-lang/rust/issues/44580

As far I understand the RFC won't allow for `Array[Y, N]` (or `Array ` in Rust parlance) note eddyb's comment: Note that all of this should allow impl Trait for [T; N] {...}, but not actually passing a constant expression to a type/function, e.g. ArrayVec . What I'm actually looking is `Array >` for support for data structures that vary depending on size of `T`.

The RFC supports it, eddyb's list of milestones in the compiler just don't get you all the way there.

Re: Rust's 2018 roadmap

#89

Post by moosingin3space »

gandreani wrote: post #33

Lots of nice language improvements lined up for this year I haven't played with Rust but I like the ecosystem and transparency. Something that stands out is the Compatibility across editions section. Seems like they really thought this through: > you can be on a different edition from your dependencies. > Edition-related warnings...must be easily fixable via an automated migration tool (rustfix). Only a small minorit…

> Only a small minority of crates should require any manual work to opt in to a new edition

Is this going to be tracked through the system that catches compiler regressions against the entire crates.io ecosystem?

Re: Rust's 2018 roadmap

#90

Post by pcwalton »

pknopf wrote: post #12
woah wrote: post #6

Earlier quoted context omitted.

Do they ship a GC with every webpage then or am I misunderstanding how it works?

Each module has to have it's own GC. In my experience, it's been easier to integrate two languages that have GC (JavaScript and Go) than two languages where only one is GC'd (JavaScript and Rust). What will the interop with Rust and JavaScript look like? How will pointers be managed?

It's not at all easier to interoperate two separate GC'd languages unless you have one garbage collector to manage them both. Web Assembly does not provide the hooks necessary to integrate GC, and JavaScript does not provide critical features, such as finalizers, that are necessary to do things like break cross-language cycles. Absent that support, manual memory management of DOM objects is necessary, and Rust is going to have a much easier time of that than Go will.
Post reply on HN