4 ms·

It's not just the "not now" approach. It's the rhetoric that often goes along with it. The author of this piece picks up on it when he talks about the "we've al

It's not just the "not now" approach. It's the rhetoric that often goes along with it. The author of this piece picks up on it when he talks about the "we've already thought about this and we're tired of talking about it" vibe, though I might characterize a lot of the discussion around generics from the Go community at large more specifically as "you think you want/need this, but trust us, you don't, and the inconveniences you think you're experiencing are just not that big a deal, particularly compared to the inconveniences you'll experience if we do add it." And yes, if not having an HTTP server implementation in the stdlib seems like it makes your project difficult, that's a perfectly reasonable criticism of Rust. (Though one I suspect will get resolved much more quickly and cleanly than issues like generics in Go.)

steveklabnik 12y ago
> I suspect will get resolved much more quickly and cleanly It's pretty easy. You just add this line to your Cargo.toml: hyper = "0.3.14" And the next time you build, Cargo handles everything. You can now use hyper like any other library that's included with Rust, no biggie. This is one reason we've chosen minimalism for the standard library: It's really easy to use external libraries, and once things land in the standard library, they often don't improve much. The versions become tied to the compiler versions, contributors now need to build the entire compiler rather than just working on a single library, and everything else. We've already seen three distinct major HTTP implementations happen, had we put rust-http right in the standard library, we'd have frozen something the author has already deprecated! Choosing non-minimalism has advantages too: in this scenario, you need to know that hyper is currently the best library, for example. Engineering is all about trade-offs. (Solely chiming in on the HTTP in Rust thing here. I found the part of the article about the Gopher... lacking, and it distracted me from the rest of the author's points.)
- cryptos 12y ago
  > Engineering is all about trade-offs. What a wonderful sentence about a simple, but often forgotten truth!
- EugeneOZ 12y ago
  no. there is a HUGE difference between std lib and third-party libs. Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. And as http is a very important thing for web-programs, it's much better to see support of http in std lib.
  - steveklabnik 12y ago
    Right. That's the kind of thing I meant with "Choosing non-minimalism has advantages too."
  - pcwalton 12y ago
    > Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Rust has language stability (in practice right now, and officially once we hit 1.0 in a month), so we in fact do guarantee this. > Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. Languages can do that too, in which case the entire language and its ecosystem is in trouble. Anything can be abandoned. The crucial thing is that if a piece of infrastructure is in the standard library, then it's much harder and slower to iterate on it. HTTP is a fast-moving standard (see HTTP 2, for example), and so it's very important to be able to iterate quickly to support new features. > And as http is a very important thing for web-programs, it's much better to see support of http in std lib. I disagree. Web applications need HTTP, but many applications aren't Web applications. As a example on the far opposite end of the spectrum, your OS kernel doesn't have an HTTP stack in it (unless you happen to be running something like khttpd), and Rust is designed to be usable for OS kernels. Large standalone standard libraries reduce flexibility, and Rust is designed to be flexible.
    - comex 12y ago
      Hmm... Windows has part of a HTTP stack in the kernel, which I know solely based on hearing about the recent vulnerability in it. And OS X's kernel, IIRC, can load disk images over HTTP for netboot purposes. That leaves Linux as the odd one out :) (Yes, I know that's completely tangential to the point you're making.)
- cgag 12y ago
  Haskell does it the way Rust does and it's pretty frustrating to have tons of solutions to evaluate for everything you want to do. Maybe crates.io will have a better discovery story, or rust will have a larger user base that makes it more likely that there's a clear winner. I hope so.

steveklabnik 12y ago

> I suspect will get resolved much more quickly and cleanly It's pretty easy. You just add this line to your Cargo.toml: hyper = "0.3.14" And the next time you build, Cargo handles everything. You can now use hyper like any other library that's included with Rust, no biggie. This is one reason we've chosen minimalism for the standard library: It's really easy to use external libraries, and once things land in the standard library, they often don't improve much. The versions become tied to the compiler versions, contributors now need to build the entire compiler rather than just working on a single library, and everything else. We've already seen three distinct major HTTP implementations happen, had we put rust-http right in the standard library, we'd have frozen something the author has already deprecated! Choosing non-minimalism has advantages too: in this scenario, you need to know that hyper is currently the best library, for example. Engineering is all about trade-offs. (Solely chiming in on the HTTP in Rust thing here. I found the part of the article about the Gopher... lacking, and it distracted me from the rest of the author's points.)

cryptos 12y ago
> Engineering is all about trade-offs. What a wonderful sentence about a simple, but often forgotten truth!
EugeneOZ 12y ago
no. there is a HUGE difference between std lib and third-party libs. Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. And as http is a very important thing for web-programs, it's much better to see support of http in std lib.
- steveklabnik 12y ago
  Right. That's the kind of thing I meant with "Choosing non-minimalism has advantages too."
- pcwalton 12y ago
  > Std lib is like a contract - maintainers of language have to keep all parts up to date and working. Rust has language stability (in practice right now, and officially once we hit 1.0 in a month), so we in fact do guarantee this. > Maintainers of third-party library can write "Farewell Rust" blogpost and all projects, based on that library will be in trouble. Languages can do that too, in which case the entire language and its ecosystem is in trouble. Anything can be abandoned. The crucial thing is that if a piece of infrastructure is in the standard library, then it's much harder and slower to iterate on it. HTTP is a fast-moving standard (see HTTP 2, for example), and so it's very important to be able to iterate quickly to support new features. > And as http is a very important thing for web-programs, it's much better to see support of http in std lib. I disagree. Web applications need HTTP, but many applications aren't Web applications. As a example on the far opposite end of the spectrum, your OS kernel doesn't have an HTTP stack in it (unless you happen to be running something like khttpd), and Rust is designed to be usable for OS kernels. Large standalone standard libraries reduce flexibility, and Rust is designed to be flexible.
  - comex 12y ago
    Hmm... Windows has part of a HTTP stack in the kernel, which I know solely based on hearing about the recent vulnerability in it. And OS X's kernel, IIRC, can load disk images over HTTP for netboot purposes. That leaves Linux as the odd one out :) (Yes, I know that's completely tangential to the point you're making.)
cgag 12y ago
Haskell does it the way Rust does and it's pretty frustrating to have tons of solutions to evaluate for everything you want to do. Maybe crates.io will have a better discovery story, or rust will have a larger user base that makes it more likely that there's a clear winner. I hope so.