WG-Net Web Survey

[yoshuawuyts]

Summary

In this issue we describe a survey we’ll send out to learn more about how people are building networking services, and inform future directions.

Motivation

The Rust Web Networking WG exists to help improve the way people build web services with Rust. So far we’ve never investigated how people in the wider community are using Rust to build web services, so this issue serves to do just that.

The survey will hopefully allow us to understand better how people use Rust. We namely hope to have answers to:

• Which things are do people like about doing networking with Rust?
• Which things are people struggling with when doing networking with Rust?
• Where can we work to improve documentation?
• Where can we work to improve the crates ecosystem?

Reference-level explanation

The idea is to model the Web Survey similar to the Rust Lang Survey. Ideally minimizing the amount of required questions, and leaving as much room for people to answer questions. The projected time to complete the survey should be no longer than 10 minutes.

We should probably follow the Rust Lang Survey’s lead, and establish two flows:

1. A flow for people who have built web services in Rust.
2. A flow for people who have not built web services in Rust.

We should also make sure to involve the Community team early on, as they have multi-year experience submitting the general Rust Survey. We can probably learn from their experience, and prevent making some of the mistakes they might have made early on.

Timeline

The expected timeline for the survey would be:

1. 18/09/2018 start drafting survey
2. 01/10/2018 send out survey
3. 14/10/2018 close survey
4. 28/10/2018 publish survey results in blog post

Contributing

The biggest contribution we need is which questions to ask. We need to figure out both the themes (e.g. “We should ask about framework usage”), and concrete questions (e.g. “What is your go-to framework for building web applications”). It would be fantastic if we could work together to collections of questions, centered around themes in this issue!

Drawbacks

None.

Rationale and alternatives

Alternatively we could hold dedicated sessions with known stakeholders, and document those sessions. This might be closer to the Rust Case Studies. The result of those will probably allow us to ask more directed questions, and extract more information — but at the time we’re not sure what the state of the world is in the first place.

Unresolved Questions

Given the tight deadline, we won’t have time to also do internationalization like the General Rust Survey does. If we intend to run this survey again in the future we should make this a focal point.

[rolftimmermans]

Some suggestions:

• Do you write any networking code in Rust? [yes or no]
• When writing networking code, do you mostly target stable or nightly Rust?
• When writing networking code, do you currently mostly write synchronous or asynchronous code?
• If you are (mostly) writing synchronous code, what are the primary things that prevent you from asynchronous code instead? [provide options, e.g.: compiler stability, library stability, documentation, example code, performance, productivity, I don't need async code at all, other...]
• If you are (mostly) writing asynchronous code, what are the main things you have struggled with? [open or provide options?]
• Which libraries have you used in the past to write (production) networking code? [tokio, futures-rs, hyper, ..., ..., ..., other...]

[yoshuawuyts]

@rolftimmermans these are all great! I guess we probably also need some questions for folks that don't write network services in Rust yet.

• Do you write networking code in other languages?
• If yes, in which languages?
• Are you interested in writing networking code in Rust?
• Why aren't you currently writing networking code in Rust?

Probably others. I reckon we can take some inspiration from the rust survey here.

[sendilkumarn]

@yoshuawuyts valid point.

• What is the coolest feature that you have in your preferred language?

• What is the major pain point that you have in your preferred (or) selected language?

The first will help us in deciding the correct path while the second one will help us in learning the lesson before implementing.

[bIgBV]

Maybe we should consider the level of proficiency someone has when writing networked code in Rust? And about which frameworks they have used previously in other languages (Django, Rails, Flask, Play, Spring?, Phoenix). I think it will give us an idea of what general framework users are looking for in a framework in rust.

Another thing we can ask is what kind of framework they would prefer, say like the barebones approach encouraged by the Go community vs the kitchen sink approach of Django/Rails.

I've come up with some questions, feel free to use/modify/take inspiration from them:

• How would you describe your proficiency in Rust? [Beginner, Intermediate, Advanced]

• How would you describe your proficiency in web programming?

  • Beginner (Wrote simple web applications using a framework)
  • Intermediate (Complex web services/dug into framework code)
  • Advanced (Built web frameworks(maybe?))

• What kind of an approach to web application programming would you prefer?

  • Barebones: Using the modules from the standard library to build your own system a-la Go?
  • A batteries included framework akin to Django or Rails.

[sunjay]

As a part of the "Do you write any networking code in Rust?" question, it might also be a good idea to say a bit about what you consider "networking" to be. For example, if the answer could include just any program that uses the network (e.g. servers, CLI tools that download things, etc.) that is very different than looking for answers specifically from people who have written code for actually doing the networking (e.g. http implementions, socket handling, other protocols, etc.)

Would be great to clarify this so there is absolutely no confusion. :)

[agmcleod]

I myself have yet to really dive into this space with rust, it is something i want to check out. The main question that sticks out for me is:

What are some of the main pain points keeping you from using Rust for production web applications?

[swarnimarun]

I think a couple good questions will be,

• Have you tried any frameworks in Rust?
• Would you and if Yes? Why would you like to use Rust?
• How easy do you think it is to write Networking code in Rust?
• Do people around you also use Rust?

[yoshuawuyts]

Made a first draft for the survey -- it's mostly modeled after the CLI survey that was sent out a couple of months ago. It probably needs a bunch of polishing, so feedback would be very useful!

• link to survey draft

---

On another note: we're slightly behind schedule now. I want to propose we submit the survey next week Monday (08/10). Does that sound alright?

[bIgBV]

Which crates are you currently using that are specific to web services?

Isn't this question and the one following it a little too open-ended? If someone has never written a crate in rust they wouldn't answer that question. Why not have a default list of crates like hyper, rocket etc and give an option to provide any other examples? That way we can gather specific information regarding which part of writing a web application is the most cumbersome in rust.

Just some thoughts.

[yoshuawuyts]

Why not have a default list of crates like hyper, rocket etc and give an option to provide any other examples?

That's a good one! One thing I want to make is that we provide people room to express which libraries they've used, and not only frameworks. This ties in specifically to the "bolster the ecosystem" goal. Perhaps we could ask one question about "frameworks", and another about "other crates"?

[bIgBV]

Perhaps we could ask one question about "frameworks", and another about "other crates"?

That plus maybe also include a question asking what is their preferred approach to libraries. Something akin to asking what do they prefer, batteries included like Django/Rails or a few external libraries with the standard library providing most of the required modules like Golang/Flask.

I think that such a question will help gauge what people are looking for. But I might be wrong since consensus on a question this vague as such might not be straightforward.

[yoshuawuyts]

@bIgBV updated the survey with your feedback!

[yoshuawuyts]

PSA: going to publish the survey tomorrow morning Pacific Time. Keeping the survey open for 14 days. Final reviews would be great!