Rust lang should have official team support web framework

Rust lang should have official team support web framework.
The current Rust lang community does not have a good web frameowork.
See java world. They have Spring framework, spring boot .
Rust lang is less popular, due to not easy to get the web development area.

What is the largest development area? web (you always need website, api, etc)

But it's hard to using rust building web apps.

2 Likes

What limitations have you run into with cargo-web + stdweb?

Rust is quite young in comparison to Java, so expecting it to have a web-framework of the same quality as Java's is asking a bit much. (this is also one the major reason why Rust is less popular than Java)

2 Likes

cargo-web + stdweb is for client-side WASM things. It seems OP wants some server side framework like spring or django.

3 Likes

Yes, so we shall need some focus on improve it.

1 Like

Why does this necessitate an official team, though? What's wrong with some people creating a crate and publishing it?

5 Likes

Rust has improved a lot in a lot of areas, and most of that has been lead by external people! Think of the work in WASM, or in async IO, or even in webframeworks (like rocket). All of this was independent work, and it's some of the best improvements made for Rust.

Rust isn't great at web servers yet, but that takes time. An official team could accomplish this, but there would need to be significant benefit. People are already innovating, finding new solutions, and improving code. Projects like tokio, async-std, actix, rocket, tower, gotham are all improving the state of writing web servers in rust without any official team. We can, and will, improve the state of Rust ourselves, as other areas have been improved (like server side tooling, like writing OpenGL apps, like writing client-side WASM).

No any body care about rust, especially the rust team.

I find this especially untrue. The rust team does a lot, it's just that most of that work goes into rustc itself. They write the foundation which everyone else builds on top of!

And to say no body cares would be to ignore the entire crates.io ecosystem. It's a very different model than languages like Java follow, but independent people making and improving crates make Rust what it is today. The myriad of production uses of Rust exist because of the thriving ecosystem of crates. The Rust team plays an important role - building rustc (and cargo, crates.io, etc.) - and the system works.


I definitely recommend looking at projects like rocket and gotham, or the summary page arewewebyet to look at progress. We don't have the same m as other languages, but we're consistently moving forward. It's ten times easier to create a web app today than it was a year ago - and that's not even counting how much nicer async/await is for asynchronous programming than other stuff!

It's just that Rust has had 4 years, and Java has had 23. Or if comparing to a language like Go, Rust is a much more general language, and it's main goal is not to just write nice web servers.

8 Likes

Is that true? (not a rhetorical question - curious to hear what's lacking) So far I can't see what's missing- Rust beats the pants of Python and JS in benchmark tests, and from innovative approaches like warp's filters or actix's actors, it feels like Rust is getting out of the gate with various modern approaches that are production-ready...

From my perspective (without looking too much in depth), it actually feels like the bigger problem is fragmentation and no single official "blessed" solution. And that's a mixed, erm, blessing - since fragmentation allows exploring ideas in totally different directions, but then as a user I/we don't know which one to pick.

(fwiw the concept behind warp looks super interesting to me and fits with my mental model about how web requests work, but I haven't built anything with it yet - so curious to hear what others think)

8 Likes

Where is the evidence for this?

If the goal is to teach someone with no technical background how to write a TodoMVC, then the right framework is probably the most important question.

However, if the goal is writing some 20k+ loc backend, it seems that the choice of programming language (and the ability to get errors at compile time instead of runtime) seems to dominate whatever "dsl magic" a framework might provide.

2 Likes

There is a balance to be made between a hands off ecosystem evolution and official top down driven development.

Rust is an open source language, with an open community, and seems to lean towards natural evolution.

This might come as a surprise to someone hearing about rust for the first time given it is post 1.0 (curious how much this influenced your opinion @netroby).

The top down (e.g. springboot) approach feels like a desirable goal for long term stability. Consensus helps invest effort in developing very good libraries. These kinds of libraries pull in new users of the language because they can become "the" way to do X. (Python and data science comes to mind here).

Having said that, rust is in the position it is today thanks to the evolution of its ecosystem, and it's community.

3 Likes

Is it? Nobody told me that. I'm new to Rust so I just went ahead an did it. I use Rocket to serve up web pages, and a REST API, and deal with my Cockroach database. I also have a web socket server going on.

A gather Actix is a good option as well.

What is it you want that Rust is missing?

The last thing I want is for Rust to end up like the Java world.

There is a lot of Javascript and node.js being used in the web world. node.js does not have a web framework either. People use things like Express.js. That did not stop node from becoming massively popular and widely used.

My take on it is that the Rust team is best employed making the language, it's tools, and core libs rather than being diverted into creating applications like web frameworks. I'm sure the community will create something if there is a need for it.

7 Likes

Amen!

I hope Rust will never have an officially blessed framework.

Like others pointed out, OP would need to expand in their arguments.

I couldn't agree more.

From a purely selfish perspective, everything I can think of that would drastically increase my web dev productivity are core language features. If someone released Java/Spring or RubyOnRails for Rust, it would not change my web dev experience much. However, if someone:

  • shaved incremental rebuild times from 3-5 seconds down to 0.3-0.5 seconds, that'd be huge

  • build a Rust REPL: compile your wasm32 code with debug symbols, fire up a Rust REPL in chrome <-- I would pay a monthly subscription for this

  • improvements to the IntelliJ Rust plugin (it's amazing, but could be better)

These are the things that would drastically increase my Rust / web-dev productivity.

4 Likes

I do think that in order to increase the adoption of Rust in the enterprise some sort of "approved" way of doing things will become necessary. Spring/SpringBoot is maintained by Pivotal. The enterprise embraces SpringBoot as it has all the necessary features, it is open source with a friendly license and there is somebody to provide a full time support.

While I was looking at my project https://github.com/swir-rs I had to spend a good bit of time analysing how well libraries providing common functionality such was http/messaging/etc., are supported, how mature they and how well they fit with each other. I take it as part of the learning curve but from the enterprise perspective dependency management is a pain. Especially when there is a huge overlap between projects and many libraries offer similar sounding functionally. As an example Tokio, futures, std and crossbeam all provide mpsc. Picking one is tricky without going into the details and in my Swir it is easier to use many different forms due to dependencies on other crates.

2 Likes

A good analysis of the fragmentation problem

1 Like

There are two realworld.io backend examples written in Rust. On that site are examples of the same demo app written in many different languages for comparison. The community can contribute alternatives that they believe are more idiomatic or that use better crates. People can then star then to move them higher up the page. When Rust is as old as Java there might be a version that is a clear winner. Until then having more than one example of the same realistic application gives people a great place to start.

4 Likes

@netroby

I think you need to realize that Rust is an open source project financed by a few parties and they don't have endless resources like, say, Go (Google).

Yes, the current situation is bad (ie: there is no clear WebSocket library and the current ones do not support the latest async/await) but all the progress made this far is from contributors who put time for free for the community.

Here is an idea: Help with your time to improve these projects. Using them and reporting bugs is also a step forward.

2 Likes

IMHO Spring Boot is an overengineered Rube Goldberg machine. The core of Spring has good code in it, but the IoC machinery, runtime resolution of dependencies and overuse of reflection makes it really slow, complicated and hard to use and reason about.

If you want some inspiration for good web libraries, look at node or golang instead.

Rust already produced some great minimal and flexible web libraries like Iron. The current situation with the async hiccup isn't great, and the web libraries which popped up after Iron (such as Rocket) are IMO unfortunately less flexible and more magic-heavy with macros and metadata.

I'd like to urge the Rust community to not go down the Spring route, but to focus on easy to use programmable APIs for web development. A Java equivalent to that would be Spark Java.

2 Likes

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