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.
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.
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.
It sounds a bit like tyger has some overlap with https://github.com/seanmonstar/reqwest?
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.
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
- Why RLS isn’t using incremental compilation yet?
- 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
- name for the simd module
Lang
- Talked about
extern type
and its interaction withsize_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
- Had idea of creating a sort of cross-cutting Guidelines effort:
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
- 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!)
Thank you for these updates! As a new rust user it is amazing to feel included in the inner workings
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?
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.
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!
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.