Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.0 Alpha

blog.rust-lang.org

Post reply on HN
Print view View original

41–50 of 255 posts

Re: Announcing Rust 1.0 Alpha

#41

Post by vilya »

steveklabnik wrote: post #15
kibwen wrote: post #14

Earlier quoted context omitted.

The upside to a batteries-included stdlib is, of course, that you don't have to go fishing around for the best lib to do $WHATEVER_PARTICULAR_TASK, and you also don't have to wonder whether whatever lib you eventually choose will be abandoned by its developer next month. At such a young stage of language development, I agree that it makes more sense to let the community develop libraries in order to foster competitio…

It's been my experience that the standard library is _never_ the place for the best lib to do $WHATEVER_PARTICULAR_TASK, but different folks have different preferences. We'll see how it all shakes out!

The useful thing about a standard library is that it provides a common vocabulary for code, which is a great help for interoperability. For example: c++ doesn't have a 3D vector class in its standard library, so pretty much every 3D-related library invents its own & you end up having to write lots of useless glue code to convert from one to the other.

Re: Announcing Rust 1.0 Alpha

#42

Post by binarycrusader »

Ao7bei3s wrote: post #29
binarycrusader wrote: post #18

Earlier quoted context omitted.

I think Python and Go are two examples where the standard library has very much proven invaluable. Without it, it's difficult to be confident in the portability of components, and it quite frankly makes the language less attractive for use. Like the other poster mentioned, I'm happy for the RUST folks to take a "wait-and-see" approach, but at some point, I believe "blessed" components are going to be expected and str…

Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), tha…

While I'll readily agree that some parts of the standard library are rotten, that's not sufficient justification to say that there shouldn't be one.

I should also clarify my expectations about a standard library; to me, a standard library should have all of the basics covered (interaction with the underlying system, I/O, networking, etc.) and anything that benefits from better integration with the runtime (think data types such as those found in python's collections module).

If anything, I'd argue that the main problem with Python's standard library is not the library itself, but the lack of more focused curation.

Note that I never said that I expect all functionality to be available in a language's standard library; for me personally, Go's standard library has roughly the right balance.

Re: Announcing Rust 1.0 Alpha

#43

Post by steveklabnik »

vilya wrote: post #41
steveklabnik wrote: post #15

Earlier quoted context omitted.

It's been my experience that the standard library is _never_ the place for the best lib to do $WHATEVER_PARTICULAR_TASK, but different folks have different preferences. We'll see how it all shakes out!

The useful thing about a standard library is that it provides a common vocabulary for code, which is a great help for interoperability. For example: c++ doesn't have a 3D vector class in its standard library, so pretty much every 3D-related library invents its own & you end up having to write lots of useless glue code to convert from one to the other.

Yes, this is very true, and one of the reasons that we have a pretty big set of things like collections. Common traits are an excellent thing to put into a standard library.

Re: Announcing Rust 1.0 Alpha

#44

Post by rdtsc »

Ao7bei3s wrote: post #29
binarycrusader wrote: post #18

Earlier quoted context omitted.

I think Python and Go are two examples where the standard library has very much proven invaluable. Without it, it's difficult to be confident in the portability of components, and it quite frankly makes the language less attractive for use. Like the other poster mentioned, I'm happy for the RUST folks to take a "wait-and-see" approach, but at some point, I believe "blessed" components are going to be expected and str…

Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), tha…

I agree about urllib and unittest. However over the last decade I still find Python to be a one of the best "batteries included" language/platform.

That is not small thing either. It allows getting started easier, which in turns gets more people to use it.

Here is a list of modules I used and was happy there were in stdlib:

socket, shelve, cPickle, tarfile, urllib[2], Tkinter, time, ctypes, subprocess, asyncore, json, SimpleXMLRPCServer, wave (sorry, I did use it many time ;-) ), timeit, syslog and many others.

Most of the time I was happy to find them there.

Re: Announcing Rust 1.0 Alpha

#45

Post by eslaught »

I've been incredibly impressed by the willingness of the Rust team to take a step back and re-evaluate old decisions. I think this 1.0 release will be much better for all the iterations put into e.g. dynamically sized types and other things that never quite fit in their first half-dozen iterations of the design. Congrats all!

Re: Announcing Rust 1.0 Alpha

#46

Post by vhbit »

steveklabnik wrote: post #34
Animats wrote: post #27

Earlier quoted context omitted.

Finally! I hadn't used Rust for two weeks, and when I downloaded the nightly last night, code from two weeks ago was breaking. Feature stability will help.

The last week has been extra intense. We set the date for alpha around the time we thought we'd be able to ship everything we needed, and we hit those deadlines! But that meant that the past seven days has seen a _lot_ of stuff land.

> past seven days has seen a _lot_ of stuff land

Yep, and for those who has to stay on master it was pretty nasty time - one day you patch a library, another day you're almost revert yesterday's patch.

Re: Announcing Rust 1.0 Alpha

#47

Post by vruiz »

jfaucett wrote: post #39
kibwen wrote: post #14

Earlier quoted context omitted.

The upside to a batteries-included stdlib is, of course, that you don't have to go fishing around for the best lib to do $WHATEVER_PARTICULAR_TASK, and you also don't have to wonder whether whatever lib you eventually choose will be abandoned by its developer next month. At such a young stage of language development, I agree that it makes more sense to let the community develop libraries in order to foster competitio…

I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? But would agree that the only thing Rust might need are officially supported crates, while keeping the language itself fully separate. The language is then completely free of the hastles of maintaining a stdlib that probably isn't used by most people anyway. But at the same time offici…

> Give me an example of any ecosystem where the standard library is the defacto best solution?

In Go that's certainly the case and in my experience it's a great thing, only time will tell if it will end up suffering stagnation like maybe happened to python.

Re: Announcing Rust 1.0 Alpha

#48

Post by apendleton »

Ao7bei3s wrote: post #29
binarycrusader wrote: post #18

Earlier quoted context omitted.

I think Python and Go are two examples where the standard library has very much proven invaluable. Without it, it's difficult to be confident in the portability of components, and it quite frankly makes the language less attractive for use. Like the other poster mentioned, I'm happy for the RUST folks to take a "wait-and-see" approach, but at some point, I believe "blessed" components are going to be expected and str…

Python is a prime example of a rotten standard library. Take urllib/urllib2 (use requests instead), unittest (use py.test or nose), os (too low-level, hence arcane usage) or time as examples (use pytz for anything serious), and of course Tkinter. Take all of the modules that solve minor/niche tasks that could easily have been put in a seperate library (e.g. wave), that are usually a bad idea to use (e.g. pickle), tha…

It all depends what you're using it for. If I'm writing code that's going to be around awhile and can tolerate some dependencies, I'll totally use, say, requests. But I use urllib2 from the repl all the time, especially if I'm on a machine that isn't mine. The fact that any Mac already has the tools on it to grab some JSON from an API, parse it, and do something useful with it from the command line, without having to download or install anything, is immensely useful, even if the API is a bit suboptimal. The same applies to quick and dirty things I'm shoving into a Gist to share with colleagues. Not all things have to be elegant to be useful.

(That said, those kinds of usecases aren't really in Rust's wheelhouse, so I still think in Rust's case having batteries not included is probably the right call.)

Re: Announcing Rust 1.0 Alpha

#49

Post by JulianWasTaken »

binarycrusader wrote: post #37
JulianWasTaken wrote: post #22

Earlier quoted context omitted.

Python's standard library was only invaluable when its packaging situation was near-unusable. If Rust's isn't, the same thing will be true.

I strongly disagree with that assertion; while I readily agree that some parts of the standard library are less maintained than others, as a consumer of many third-party components, I can say without a doubt that items in the core library are generally better maintained (from a security perspective) and easier to deal with. The ease of installation has nothing to do with the desire for core components. Core component…

That's just not true. Standard library components are not better maintained, not more secure, and not easier to deal with. There are too many examples to even count of each of those -- you can take a look at PEP 476 for just one recent example.

Re: Announcing Rust 1.0 Alpha

#50

Post by norswap »

jfaucett wrote: post #39
kibwen wrote: post #14

Earlier quoted context omitted.

The upside to a batteries-included stdlib is, of course, that you don't have to go fishing around for the best lib to do $WHATEVER_PARTICULAR_TASK, and you also don't have to wonder whether whatever lib you eventually choose will be abandoned by its developer next month. At such a young stage of language development, I agree that it makes more sense to let the community develop libraries in order to foster competitio…

I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? But would agree that the only thing Rust might need are officially supported crates, while keeping the language itself fully separate. The language is then completely free of the hastles of maintaining a stdlib that probably isn't used by most people anyway. But at the same time offici…

For things that the standard library can do, it is usually the best choice. It's code that's already sitting on the user's machine, why use something else?

And also, those are generally relatively straightforward things whose design are hard to get wrong (but there are exception, e.g. Python's urllib). Being a standard library and not a standard framework helps.

For what it's worth, I use Java's standard library whenever possible. It's quite extensive and the fact that the documentation is top-notch makes it a joy to use. That being said, there are still a lot of supplemental things you might want to do, which is what things like Google Guava or Apache Commons are for. But they are to supplement, not replace the standard library.

By the way, some parts of Apache Commons would be a good example of how not to design a standard library, I don't want to piece 10 objects together to do a simple utility function call.

Post reply on HN