Rust 2018 All Hands!

:heart_eyes: 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?

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

3 Likes

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

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

@alexcrichton beet you to it. :stuck_out_tongue:

1 Like

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.

1 Like

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

1 Like

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.

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.

5 Likes

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

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:

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!)
5 Likes

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

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?

2 Likes

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.

3 Likes

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!

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.

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

Woah! That would be great!

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

1 Like

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 - #54 by Keats

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

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.