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.)
> 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.)
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.
> 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.
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.)
Languages can abandon own std lib? Keep away from such languages.
> 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.
Golang doing it just fine, so Rust can too.
> I disagree. Web applications need HTTP, but many applications aren't Web applications.
I'm talking exactly about web applications, not about all applications. And if web applications is not the field of Rust - let us know about it. Right now is not obvious and even web frameworks exist in Rust.
Languages can abandon own std lib? Keep away from such languages.
Not abandon their stdlib. Be abandoned. There is nothing more preventing developers of the compiler/vm from abandoning their efforts than the developers of a library. It would make little sense for developers of the language to abandon just the stdlib, as it is part of the language.
I'm talking exactly about web applications, not about all applications. And if web applications is not the field of Rust - let us know about it. Right now is not obvious and even web frameworks exist in Rust.
Rust is a fine language for web applications, but it's not designed specifically for them. The languages with huge stdlibs date from a time when accessing libraries was much harder than it is today. The internet, as well as package management, was young when Python and Java were born. Now that it's easy to download packages, and we have reasonably passable tools for doing so, there's no need for heavy standard libraries.
Go is specially designed for running on servers and performing network tasks. So it makes sense that it would have a stdlib with rich networking support, including http.
Node was designed as a frontend to libuv, to make nonblocking IO easier to use. The most visible domain where nonblocking IO is extremely useful is in making web applications, AND the fact that it's javascript makes it even better suited to web. So Node has http support baked in.
Rust is meant to exist in the same space as C++. It can be used for anything. OS kernels to text editors to web applications. There is nothing in particular that ties it to any of these domains. It has the option of putting support for all of these in the standard library, which would make it hard to maintain. Every time one part of the stdlib needs to change, the language needs a minor version bump, or there's a delay before anyone can use the new libraries. Not a big deal when you only have one or two domain specific components in the stdlib, but a problem when you have twelve.
If the stdlib supported only some specific domains, it would give people from other domains the impression that they're second class, and drive them away. Not cool.
Language can be abandoned, but it's pointless argument, sorry. When language is abandoned, there's no reasons to argue about any aspect of that language.
In second part of your comment you comparing stdlib and external libs as they are equally reliable, but my point is exactly about difference in this aspect. I agree stdlib shouldn't be swiss knife, but I disagree it shouldn't have nothing except minimal set to serve language constructions. Go was designed as C++ also, not only for networking. And it has image module, not only http (for example). I see how fast and successfully Go evolving, I think Rust is better and that's why I think it's the area where Rust can take better idea from Go.
I would argue that Rust's approach is perfectly fine so long as they have strong organisational support around third party libraries. Look to Java for how to do this. Many core Java libraries are managed by Apache or Eclipse e.g. HTTPClient who manage the process around open source projects.
HTTP clients are not something I would want in a standard library to be honest. Since there are so many different ways to implement them. And not all work for all use cases. It's not the same as StringUtils or ArrayUtils.
Why not let a bunch of third party HTTP libraries pop up. Eventually things will converge on the "best" library for doing http in rust. Open a discussion and start adding great third part libraries to the std lib. The challenge then would be keeping this coherent throughout the std lib.
Not sure why you think I don't want to let libs pop up. I just ask for http module in std lib, not as the only implementation which can exist, but as "last resort", always working, in any new version of language, supported and tested by core team maintainers. Not full-featured thing with routes and other whistles and belts, just basic things.
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.
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.)