Rust 2018 All Hands!

[aturon]

o_O Oh really? What’s this?

I believe we had a chat about this a few months ago with you and Carl – the basic idea is that hyper, over time, has been increasingly targeting the lowest-level cases and providing the greatest flexibility. The networking WG is interested in a higher level crate that pulls together a few best practices to provide a simple, ergonomic async http story (building in TLS, configuration, and a few other concerns). Hyper would be taken as a private dependency, actually providing the implementation, while provided API surface would be narrower and something we could hope to reach 1.0 on relatively quickly.

[Eh2406]

Public deps

• Change resolution heuristics to favor fewer duplicates where possible

I am willing to help with the resolver part of this, when we have a public description for the gole and there is work on the lint part.

[aturon]

I am willing to help with the resolver part of this, when we have a public description for the gole and there is work on the lint part.

i was so hoping you’d say that! I’ve also been wanting to invite you to the Cargo team meetings; can you email me at aturon@mozilla.com so we can get that set up?

[jdm]

Public deps

Major change of plans here:

Improve rustc errors on incompatible types from different versions of the same crate (e.g. serde(1.0)::Serialize

Allow crate authors to label deps as private, which enables a lint Change resolution heuristics to favor fewer duplicates where possible

These all seem obvious in hindsight, but I really like the sound of these plans.

[fafhrd91]

is this good idea? high level http api proposal from language committee may prevent alternative implementations or wouldnt be usable in real world. for example python standard library

[Keats]

is this good idea? high level api proposal from language committee may prevent alternative implementations or wouldnt be usable in real world. example for second is python standard library

Or in Go where packages not using the built-in net/http are shunned.

[Eh2406]

i was so hoping you’d say that! I’ve also been wanting to invite you to the Cargo team meetings; can you email me at aturon@mozilla.com so we can get that set up?

@alexcrichton beet you to it.

[aidanhs]

I wouldn’t say that fragmentation is something to strive for. Alternatives can certainly be a good thing in combination with other factors, but I’m not clear that it brings benefits by itself. For example, I’ve had cases where hyper hasn’t been suitable so I’ve had to use libraries missing a lot of the functionality hyper includes. This is just a natural result of people investing time into new projects (‘alternatives’) rather than existing ones.

That aside, I’m not sure that Python is a good example of preventing alternative implementations given that http://docs.python-requests.org/en/master/ exists.

[anp]

It sounds a bit like tyger has some overlap with https://github.com/seanmonstar/reqwest?

[fafhrd91]

python is example of opposite, python’s http in standard library is bad. i developed asyncio’s web framework aiohttp, it was part of original asyncio project. before merging asyncio to the standard library we moved http implementation to separate repo, and i think this was very good decision. otherwise that would prevent fast evolution of aiohttp and would prevent alternative implementations.

[bradleybeddoes]

What is the differentiator between tyger and any of the existing web ‘framework’ type projects that are currently active within the Rust community?

For instance I had a look at https://github.com/withoutboats/tyger/blob/master/src/serve.rs and (as I know Gotham best) this pretty much looks like what we’d arrive at once https://github.com/gotham-rs/gotham/issues/32 and https://github.com/gotham-rs/gotham/issues/26 land.

If it is essentially the same result that I’d suggest focusing efforts one of the existing projects, who have created communities and already solved a few other issues at this level. Naturally I’d strongly advocate for Gotham filling this role, we have a wonderful community of folks interested in developing in this space and newcomers are always very welcome.

[aturon]

Friday recap

A surprise talk from Marijn!

Website

• follow up to previous meeting
• CLI team spent time working on their showcase code example
• Docs teams kicked off content discovery and organization work
• Embedded team explored other “embedded technology” sites for inspiration
• http://rust-wubwub.herokuapp.com/

Compiler

• Explored RLS integration
  • Why RLS isn’t using incremental compilation yet?
    • No real reason… we’re going to try!
  • How can we refine APIs to make this integration better
• Action items (i.e., for eddyb)
• Contributor and mentoring experience for the compiler

WG: net

• Covered a few issues around async/await and lifetimes and “off-by-one” errors around borrowing/owning values
• Surveyed syntactic design space around async blocks & functions
• Discussed ways to implement task::context inside libcore

Tools - IDE planning

• https://github.com/nrc/dev-tools-team/blob/master/berlin-2018/ide-planning.md
• compiler code completion is a long way off, but perhaps some partial solution
  • need to maintain Racer
• testing infrastructure
• debug mode
• new features - pick low-hanging fruit from codegen/refactoring/module auto-imports

Libs

• Large amount of triage
  • Regressions in 1.26 (which is soon going into beta)
  • Long list of outstanding issues
    • name for the simd module
      • std::arch
    • global allocator trait design
    • “needs decision” issues

Lang

• Talked about extern type and its interaction with size_of_val
  • Thoughts are on the thread, tldr want to stabilize soon
• Discussed a possible RFC around #[derive(Ord)] and friends
  • targeting new edition
• Discussed mitigation strategies around regressions arising from new AsRef impls
  • TLDR: let’s make this better by finding a good syntax for type ascription
• Discussed how we can make using dyn Trait better
  • Grand plans came crashing down
  • Maybe we can use a proc macro to autogenerate some boilerplate…
• Discussed “best practices”
  • Had idea of creating a sort of cross-cutting Guidelines effort:
    • API Guidelines
    • Style Guidelines
    • Lints

Community (Events Team - Florian!)

Came up with areas of event standards we want to hold, around:

• Diversity Outreach
• speaker support and quality
• program guidelines
• review committee guidelines
• communication and transparency (e.g. timelines)
• attendee experience, accessibility and support

We discussed how a relationship between events and us as a project could look like.

Work session produced articles on all topics.

Infra

• Got people selected for the work on the bors plan of action, as well as other high priority things
  • Better docs for the tools infra has and the processes we follow
• We’ve started up new crater machines to handle the excessive productivity from this all hands
• Wish list things
  • Trialling a crater bot (from member of the release team, ‘pietroalbini’)
  • @Tim N is trialling an “extract errors from travis logs” bot (Demo)
• High fives all round, great to meet in person

Cargo

Two related RFCs to write:

• Cargo project templates (needed for WGs)
• Project-scoped cargo subcommands/tasks

Rust Reach

• discussed the goal of bringing new people in and KEEPING them
• how to make people feel like part of a community
  • if you would like to sign up for a 20min chat (video/phone) about what you do for rust with the participants GET IN TOUCH WITH ME (ag_dubs) (may15-aug15)
• https://rust-reach.herokuapp.com/ goes live next monday
  • worked on CLI project
  • worked on embedded project details
  • formed application committee (welcome aidan and diane!)

[jesselucas]

Thank you for these updates! As a new rust user it is amazing to feel included in the inner workings

CLI team spent time working on their showcase code example

This is very exciting, I’m following the working group closely and can’t wait to see the example. The link at the bottom seemed to 404. Is there another place to access the example?

[jmst]

Discussed a possible RFC around #[derive(Ord)] and friends

targeting new edition

Is this a proposal for making derives implicit somehow? (certainly a major ergonomic issue in current Rust)

In that case, I’m going to take the opportunity to suggest to always autoderive Debug, autoderive everything for types with all public fields, and possibly require specifying a derive on all other types even if empty so it can’t be forgotten.

[seanmonstar]

I vaguely remember talking about a blocking IO server lib, is that what you mean?

Either way, this WG sounds like it’s interested in the same space I am. We should talk!

[jdm]

https://www.reddit.com/r/rust/comments/7y7tz0/is_there_a_reason_rust_does_not_derive_fmtdebug/ has a bunch of interesting discussion about this. You may want to subscribe to https://github.com/rust-lang/rfcs/issues/2207.

[varkor]

@TimNN is trialling an “extract errors from travis logs” bot

From what I’ve seen so far, this is already working really nicely! Nice work!

[mark-i-m]

@Tim N is trialling an “extract errors from travis logs” bot

Woah! That would be great!

[Dylan-DPC]

Hey. You can track the progress here and do join us on gitter

[Keats]

Cargo project templates (needed for WGs)

I mentioned it on the internals post already but I made a prototype of what would be needed to be useful for templates: [Pre-RFC] Cargo Templates

I can clean it up a bit and make it over http/git if there is interest