7 ms·

You need a standard web/networking framework. Built in to the standard library, like in Golang. That will speed up adoption. Rust's competitor is C++. C++'s big

by zelly 7y ago

You need a standard web/networking framework. Built in to the standard library, like in Golang. That will speed up adoption. Rust's competitor is C++. C++'s biggest weakness is build tooling, which Rust is demonstrably better at with cargo. C++'s second biggest weakness is poor networking support. Rust isn't any better. That's driving away the JavaScript/RoR/hipster crowd which is the lifeblood of Rust's adoption.

gamegoblin 7y ago
I believe the strong build tooling you mention is what makes it much less painful to have things like high-level networking frameworks in 3rd party packages.
snazz 7y ago
I think that networking frameworks go out of date much more quickly than base languages (see Python for an example). By not including it in the standard library, the recommended Rust library for web and network programming can change over time.
- zelly 7y ago
  UDP is a spec. TCP is a spec. HTTP 1..3 is a spec. There are only a few ways to implement it.
  - nicoburns 7y ago
    Rust already has synchronous TCP and UDP in the standard library (https://doc.rust-lang.org/std/net/index.html https://doc.rust-lang.org/std/net/index.html). But most people want to use async versions, at which point there very much isn't one way to implement it. Once you get to higher level protocols like HTTP, you also have questions like "should HTTP header be strings or encoded as types. There very much isn't just one way to implement it.
  - bsder 7y ago
    Do you do it with callbacks or polling? That's pretty fundamental and completely changes your API. And, before you reply, you might want to know that while the majority of things do it with callbacks, both the lowest embedded AND highest custom networking systems implement networking with polling (for different reasons).
nicoburns 7y ago
What's wrong with Rust's networking support? I actively wouldn't want it in the standard library, because you'll almost certainly end up stabilising something suboptimal. And then your stuck with it. Its not like it's hard to use 3rd party libraries in Rust. Its literally a case of adding one line to your Cargo.toml file.
- glass_of_water 7y ago
  I agree that with the rapid change in the language, it's probably premature to standardize on one API for networking. But as a newcomer to Rust, it's really overwhelming when there are like 5 different async websocket libraries, none of which is a clear standard in the community, each with relatively sparse documentation (other than the method signatures/impls). Also, I haven't been following the Go ecosystem lately, so I could be wrong, but they seem to have done a good job at creating standard libraries for common stuff like http serving, and those libraries seem to have aged just fine.
zelly 7y ago
Java has servlets and Spring. Go has net/http. Ruby has Rails. Python has Django and Flask. C++ has ASIO and gRPC. Rust belongs with the above but it has...checks notes...actix-web which was run by one guy who ragequit and apparently no one else is capable of taking the reins.
- _bxg1 7y ago
  Not true, he passed the reins: https://github.com/actix/actix-web/issues/1289 https://github.com/actix/actix-web/issues/1289
- nicoburns 7y ago
  Rust has Hyper, and Rocket (https://rocket.rs/ https://rocket.rs/). Async version that runs on stable rust coming soon.
- vbezhenar 7y ago
  Servlets are not in standard library (and it's not even library, it's a specification). Standard Java has HTTPURLConnection which is sometimes used and com.sun.net.httpserver which is not used by anyone. Spring is not in standard library either. Also you forgot netty which is best Java networking library nowadays. Java is a good example why batteries-included standard library is a bad idea. The fact that Java keeps reinventing things (Old I/O -> New I/O, Newer I/O; java.util.Date -> java.time.*; File -> Path are just a few examples) also proves that point. Standard library must contain fundamental interfaces which are required by most libraries to interoperate with user code and with other libraries. String type is used everywhere, so standard library must contain String type, otherwise people will invent QString, CString, Glib::ustring and billion other string which do not interoperate with each other, so instead of writing useful code you'll convert one string to another. Array, Set, Map are used everywhere as well, so standard library should provide those interfaces. Filesystem paths, streams are useful. And similar things. But not big libraries like HTTP library. They should be implemented as independent projects, so the best one wins.
  - lmm 7y ago
    > Servlets are not in standard library (and it's not even library, it's a specification). Standard Java has HTTPURLConnection which is sometimes used and com.sun.net.httpserver which is not used by anyone. Spring is not in standard library either. You're arguing against a strawman. These things are not in the standard library, but the ecosystem builds around them, and there are published JSRs that define the interfaces for foundational libraries (including both servlets and DI - of which Spring is just one of many compatible implementations). No-one's arguing that Rust should have a web framework in the language standard library (I hope). But there should be one or more established options that the rest of the ecosystem knows about and interoperates with.
twic 7y ago
If Rust's competitor is C++, you don't need to attract Rails developers, you need to attract C++ developers. If anything, i would say that over the last year or so, too much effort has been put into making Rust a competitor for web development, what with async, and lots of attention paid to web frameworks. Meanwhile, C++ people i know mostly look at it and say "meh, no const generics, no placement new".
- steveklabnik 7y ago
  First of all, we tend to work on what users are asking for. This survey shows a lot of interest for web and rust. Second, we’ve been working a ton on const generics. It takes a long, long time. But it’s been a constant effort. We’ll get there. (Placement new has had less attention.)
  - twic 7y ago
    > First of all, we tend to work on what users are asking for. This survey shows a lot of interest for web and rust. If (if!) Rust's mission was to replace C++, that would be a mistake. That's pretty obvious, right? You decide to replace C++. You make a language which isn't a great C++ replacement. You attract users who aren't C++ programmers. They aren't interested in the things C++ programmers are interested in. You build features which don't appeal to C++ programmers. Lather, rinse, repeat. I think at this point, in practice, Rust's goal isn't to replace C++. It's to become a better Rust.
    - sgift 7y ago
      > They aren't interested in the things C++ programmers are interested in. This assumption only holds if people didn't want to do systems programming before. Many people who wanted to do it crashed into C++ and then said "yeah okay, not for me", which calls this into question.
    - steveklabnik 7y ago
      That’s mission was never to replace C or C++, it’s true. From the very first introduction of Rust to the world: “a complied, concurrent, safe systems language.” Then it was “memory safety without garbage collection”. Now it’s “A language empowering everyone to build reliable and efficient software.” Sure there is domain and design overlap, but the goal was never explicitly attracting C or C++ programmers. At least not exclusively.
_bxg1 7y ago
It absolutely does not belong in the standard library. That said, Rust does need a "go-to" stable library for web serving, like what Express is for Node. It might make sense for the core team to endorse one, or even spend time helping one of the most prominent ones move forward, but I think it needs to remain separate.
- pikelet 7y ago
  Node has an HTTP server in the standard library. A framework it's another thing. My view is that (for example) Go's HTTP implementation will age well, because it is consistent with the design of the rest of the standard library. An HTTP client/server can certainly have a place in a standard library, providing that it is well defined, consistent in style, and keeps its scope sufficiently small.
  - _bxg1 7y ago
    Node and Go are both purpose-built for the web. Rust's target market is much broader than that; some people even use it on embedded devices. One of its headlining features is its slim standard library. That trait shouldn't be thrown away without good reason.
garmaine 7y ago
> That's driving away the JavaScript/RoR/hipster crowd which is the lifeblood of Rust's adoption. I'll bite. Why? Rust is a system-level programming language.
- FridgeSeal 7y ago
  As other people have pointed out, despite being a “systems language” Rust has attracted people from a whole bunch of areas and programming languages and limiting itself to just systems programming would limit its uptake and community for very little benefit. Not that this means that every demand needs to be acquiesced to, there’s balance to be found.
  - danielscrubs 7y ago
    Web development projects in a new language is a good starting point because you can do something with pretty UI quickly and with minimum configuration. But it has no staying power. A web developer will be gone after a couple of months (fun to learn!), leaving behind nothing, and suddenly Rust will have lost its footing (systemdevelopment).
  - garmaine 7y ago
    I’m always happy if people use Rust. But why call out an unrelated field with a use case nearly opposite of Rust’s design requirements as “the lifeblood” of adoption?
- glass_of_water 7y ago
  I also don't quite understand the appeal of Rust for applications that can tolerate a GC. Other than perhaps borrow checking, I don't see the benefits over statically-typed, GC languages. I used to code a lot in C++, but I've come to the conclusion that manual memory management is a cost that has to be considered seriously. e.g. one burden is that when you're declaring a field on a struct in Rust, you have to consider whether it needs to be a reference, value, automatic reference counted, boxed, if its a reference, what the lifetime is, etc. The only thing I miss about manual memory management is the RAII pattern. Rust moves down a level of abstraction that IMO is not useful for most applications.

by zelly 7y ago

gamegoblin 7y ago

I believe the strong build tooling you mention is what makes it much less painful to have things like high-level networking frameworks in 3rd party packages.

snazz 7y ago

I think that networking frameworks go out of date much more quickly than base languages (see Python for an example). By not including it in the standard library, the recommended Rust library for web and network programming can change over time.

zelly 7y ago
UDP is a spec. TCP is a spec. HTTP 1..3 is a spec. There are only a few ways to implement it.
- nicoburns 7y ago
  Rust already has synchronous TCP and UDP in the standard library (https://doc.rust-lang.org/std/net/index.html https://doc.rust-lang.org/std/net/index.html). But most people want to use async versions, at which point there very much isn't one way to implement it. Once you get to higher level protocols like HTTP, you also have questions like "should HTTP header be strings or encoded as types. There very much isn't just one way to implement it.
- bsder 7y ago
  Do you do it with callbacks or polling? That's pretty fundamental and completely changes your API. And, before you reply, you might want to know that while the majority of things do it with callbacks, both the lowest embedded AND highest custom networking systems implement networking with polling (for different reasons).

nicoburns 7y ago

What's wrong with Rust's networking support? I actively wouldn't want it in the standard library, because you'll almost certainly end up stabilising something suboptimal. And then your stuck with it. Its not like it's hard to use 3rd party libraries in Rust. Its literally a case of adding one line to your Cargo.toml file.

glass_of_water 7y ago
I agree that with the rapid change in the language, it's probably premature to standardize on one API for networking. But as a newcomer to Rust, it's really overwhelming when there are like 5 different async websocket libraries, none of which is a clear standard in the community, each with relatively sparse documentation (other than the method signatures/impls). Also, I haven't been following the Go ecosystem lately, so I could be wrong, but they seem to have done a good job at creating standard libraries for common stuff like http serving, and those libraries seem to have aged just fine.

zelly 7y ago

Java has servlets and Spring. Go has net/http. Ruby has Rails. Python has Django and Flask. C++ has ASIO and gRPC. Rust belongs with the above but it has...checks notes...actix-web which was run by one guy who ragequit and apparently no one else is capable of taking the reins.

_bxg1 7y ago
Not true, he passed the reins: https://github.com/actix/actix-web/issues/1289 https://github.com/actix/actix-web/issues/1289
nicoburns 7y ago
Rust has Hyper, and Rocket (https://rocket.rs/ https://rocket.rs/). Async version that runs on stable rust coming soon.
vbezhenar 7y ago
Servlets are not in standard library (and it's not even library, it's a specification). Standard Java has HTTPURLConnection which is sometimes used and com.sun.net.httpserver which is not used by anyone. Spring is not in standard library either. Also you forgot netty which is best Java networking library nowadays. Java is a good example why batteries-included standard library is a bad idea. The fact that Java keeps reinventing things (Old I/O -> New I/O, Newer I/O; java.util.Date -> java.time.*; File -> Path are just a few examples) also proves that point. Standard library must contain fundamental interfaces which are required by most libraries to interoperate with user code and with other libraries. String type is used everywhere, so standard library must contain String type, otherwise people will invent QString, CString, Glib::ustring and billion other string which do not interoperate with each other, so instead of writing useful code you'll convert one string to another. Array, Set, Map are used everywhere as well, so standard library should provide those interfaces. Filesystem paths, streams are useful. And similar things. But not big libraries like HTTP library. They should be implemented as independent projects, so the best one wins.
- lmm 7y ago
  > Servlets are not in standard library (and it's not even library, it's a specification). Standard Java has HTTPURLConnection which is sometimes used and com.sun.net.httpserver which is not used by anyone. Spring is not in standard library either. You're arguing against a strawman. These things are not in the standard library, but the ecosystem builds around them, and there are published JSRs that define the interfaces for foundational libraries (including both servlets and DI - of which Spring is just one of many compatible implementations). No-one's arguing that Rust should have a web framework in the language standard library (I hope). But there should be one or more established options that the rest of the ecosystem knows about and interoperates with.

twic 7y ago

If Rust's competitor is C++, you don't need to attract Rails developers, you need to attract C++ developers. If anything, i would say that over the last year or so, too much effort has been put into making Rust a competitor for web development, what with async, and lots of attention paid to web frameworks. Meanwhile, C++ people i know mostly look at it and say "meh, no const generics, no placement new".

steveklabnik 7y ago
First of all, we tend to work on what users are asking for. This survey shows a lot of interest for web and rust. Second, we’ve been working a ton on const generics. It takes a long, long time. But it’s been a constant effort. We’ll get there. (Placement new has had less attention.)
- twic 7y ago
  > First of all, we tend to work on what users are asking for. This survey shows a lot of interest for web and rust. If (if!) Rust's mission was to replace C++, that would be a mistake. That's pretty obvious, right? You decide to replace C++. You make a language which isn't a great C++ replacement. You attract users who aren't C++ programmers. They aren't interested in the things C++ programmers are interested in. You build features which don't appeal to C++ programmers. Lather, rinse, repeat. I think at this point, in practice, Rust's goal isn't to replace C++. It's to become a better Rust.
  - sgift 7y ago
    > They aren't interested in the things C++ programmers are interested in. This assumption only holds if people didn't want to do systems programming before. Many people who wanted to do it crashed into C++ and then said "yeah okay, not for me", which calls this into question.
  - steveklabnik 7y ago
    That’s mission was never to replace C or C++, it’s true. From the very first introduction of Rust to the world: “a complied, concurrent, safe systems language.” Then it was “memory safety without garbage collection”. Now it’s “A language empowering everyone to build reliable and efficient software.” Sure there is domain and design overlap, but the goal was never explicitly attracting C or C++ programmers. At least not exclusively.

_bxg1 7y ago

It absolutely does not belong in the standard library. That said, Rust does need a "go-to" stable library for web serving, like what Express is for Node. It might make sense for the core team to endorse one, or even spend time helping one of the most prominent ones move forward, but I think it needs to remain separate.

pikelet 7y ago
Node has an HTTP server in the standard library. A framework it's another thing. My view is that (for example) Go's HTTP implementation will age well, because it is consistent with the design of the rest of the standard library. An HTTP client/server can certainly have a place in a standard library, providing that it is well defined, consistent in style, and keeps its scope sufficiently small.
- _bxg1 7y ago
  Node and Go are both purpose-built for the web. Rust's target market is much broader than that; some people even use it on embedded devices. One of its headlining features is its slim standard library. That trait shouldn't be thrown away without good reason.

garmaine 7y ago

> That's driving away the JavaScript/RoR/hipster crowd which is the lifeblood of Rust's adoption. I'll bite. Why? Rust is a system-level programming language.

FridgeSeal 7y ago
As other people have pointed out, despite being a “systems language” Rust has attracted people from a whole bunch of areas and programming languages and limiting itself to just systems programming would limit its uptake and community for very little benefit. Not that this means that every demand needs to be acquiesced to, there’s balance to be found.
- danielscrubs 7y ago
  Web development projects in a new language is a good starting point because you can do something with pretty UI quickly and with minimum configuration. But it has no staying power. A web developer will be gone after a couple of months (fun to learn!), leaving behind nothing, and suddenly Rust will have lost its footing (systemdevelopment).
- garmaine 7y ago
  I’m always happy if people use Rust. But why call out an unrelated field with a use case nearly opposite of Rust’s design requirements as “the lifeblood” of adoption?
glass_of_water 7y ago
I also don't quite understand the appeal of Rust for applications that can tolerate a GC. Other than perhaps borrow checking, I don't see the benefits over statically-typed, GC languages. I used to code a lot in C++, but I've come to the conclusion that manual memory management is a cost that has to be considered seriously. e.g. one burden is that when you're declaring a field on a struct in Rust, you have to consider whether it needs to be a reference, value, automatic reference counted, boxed, if its a reference, what the lifetime is, etc. The only thing I miss about manual memory management is the RAII pattern. Rust moves down a level of abstraction that IMO is not useful for most applications.