Did you mean HTTP server? If so, there are at least 3 good ones in Rust that are only a `cargo add` away. If you've already taken the trouble to set up a toolchain for a new language, surely a single line isn't asking too much.
> How often are folks writing applications that don’t need to connect to the web these days?
In Go? Rarely, I would expect. In Rust, I'd assume connecting to the web is the exception rather than the norm. Most Rust projects tend to be lower-level infrastructure & systems programming.
This probably explains, and in turn is explained by, their different choices re: http in stdlib. They have much different aims and target use-case.
I would complaint about Rust as well, but setup a HTTP server in Rust is actually not that hard if you accept the fact that you'll have to use third-party framework. Then, the HTTP server will come to alive in within 20 lines of code.
But, of course, the demo code is always easy. The real nightmare starts as soon as your application became complex enough, that the demo no longer fit and you need to manually spawn something (To handle TCP connection before it hits the framework for example) rather than just "actix_web::main" or "tokio::main".
It amazes me that this language was supposedly written to be the groundwork for an entirely new html engine and yet there has never been a really nice HTTP library; built in or third party. Look at some of the last language hype parties: Node and Go; they both didn't even hit alpha stage before they had fantastic HTTP/networking libraries built in.
I get that Rust is targeting low-level, "systems" programming, but I really don't see how you can't also be a very performant server language.
We're considering moving the new Rust language service over to this protocol, or possibly, having it as a default protocol while supporting other protocols.
Since I've been learning it recently, maybe some points to help understand it:
It's just the protocol piece. Currently, VSCode will stand up the language server and communicate using the protocol over stdin/stdout. Nothing to say they couldn't support http servers in the future, but currently it seems lower level that that.
They do support hovers, which you can use for seemingly anything. We currently are using them for type information and showing API docs.
I'm hoping this takes on with other editors, as once they support it, then they'll get the stronger language support the servers provide, which can do hovers, on-the-fly error checking, code navigation, and more. It's not perfect, but as a baseline set of features, it's a pretty good starting set.
I understand there are a lot of people on HN with "web goggles" and a severe case of "all development is web development" myopia, but seriously this is just over the top. I'm a "C++ guy" (that is, I like writing programs using C++ and probably always will, even if I use others from time to time), but I would never object to a language like Rust on the basis that it lacks an http package. HTTP is a high level communication protocol. It isn't the only such, certainly not the most efficient, and definitely not even the best. To bash on a language for lack of "native" support for http is just a bit ridiculous.
> Nowadays the Rust http libraries to use are warp or axum
Warp and axum are certainly not the only choices, and saying they are the best choices is a matter of opinion. Actix-web, rocket, tide, warp, axum are all great web frameworks.
rust-http was the very first thing that I worked on when I came to Rust, not knowing the language up until then. And it hasn't been turning out too badly.
I'm fairly experienced and I still can't throw up an HTTP server in Rust, even with libraries.
I almost can do in with NodeJS and Express from memory.
Something like
app = require('express')
app.listen('/', function ( req, res ){ res.send (' Hi Hn') }) ;
It's ok for different languages to do different things.
I can't imagine anyone being faster with Rust than Python or JS. Of course eventually Rust gets a performance boost, but it's never going to matter unless you're talking about a larger scale project.
I think Rust has a very bright future in web servers. I have one small service (using warp[0]) in production. The level of confidence I have once the dang thing compiles is quite comforting.
I don't see why not, making a simple HTTP server is fun and interactive, doesn't take much time and you can learn a lot if you don't know much about the language yet.
Seeing that function signature, I can imagine why a lot of people avoid Rust just based on first impressions.
Did you mean HTTP server? If so, there are at least 3 good ones in Rust that are only a `cargo add` away. If you've already taken the trouble to set up a toolchain for a new language, surely a single line isn't asking too much.
reply