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

21–30 of 255 posts

Re: Announcing Rust 1.0 Alpha

#21

Post by wycats »

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!

For what it's worth, while a lot of people complain about the Ruby standard library, when I want to reach for an HTTP library that is properly threadsafe, properly supports encodings (and in general is properly integrated with whatever version of the language the user happens to be using), Net::HTTP is a godsend.

People who complain about the ossification are often talking about the aesthetics of the API (since API tastes change, long-term stdlibs tend to feel outdated), or the level of abstraction (you have to do a lot to use Net::HTTP, at least in the past), and not about the functionality. I'd rather people build nice abstractions on top of Net::HTTP than tell me to use something else because the API is prettier.

Re: Announcing Rust 1.0 Alpha

#22

Post by JulianWasTaken »

binarycrusader wrote: post #18
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!

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's standard library was only invaluable when its packaging situation was near-unusable. If Rust's isn't, the same thing will be true.

Re: Announcing Rust 1.0 Alpha

#27

Post by Animats »

kibwen wrote: post #7

Congrats to everyone involved (and there sure are a lot of you)! The TL;DR of the alpha is basically this: 1. The concept of a six-week release cycle begins today, with the first beta coming in March. 2. Breaking changes will basically cease, with the exception of a list of libraries that are still unstable and features that may be tweaked ( https://github.com/rust-lang/rust/wiki/Anticipated-breaking-... ). 3. Given…

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.

Re: Announcing Rust 1.0 Alpha

#28

Post by steveklabnik »

wycats wrote: post #21
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!

For what it's worth, while a lot of people complain about the Ruby standard library, when I want to reach for an HTTP library that is properly threadsafe, properly supports encodings (and in general is properly integrated with whatever version of the language the user happens to be using), Net::HTTP is a godsend. People who complain about the ossification are often talking about the aesthetics of the API (since API t…

Yeah, while that's kinda true, it's also incredibly hard to patch bugs. Contributing to Net::HTTP means dealing with a whole lot of stuff that you don't have to when contributing to a random project, and (as I'm sure you know, hahah) it's easy to use my custom patched random gem with Bundler, whereas I have to wait a year to get my Net::HTTP fix.

Re: Announcing Rust 1.0 Alpha

#29

Post by Ao7bei3s »

binarycrusader wrote: post #18
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!

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), that contain some copy/pasteable functions the authors deemed useful as comments (itertools), have documented bugs with copy/pasteable workarounds (csv).

Oh, and the way they do exceptions is a mess.

Oh, and don't try to read the Python standard libraries source code. It's ugly.

No, standard libraries should constrain themselves to providing a good foundation for library designers.

(I still like Python, and use it a lot.)

(Since you mentioned Go. One thing that I love about Go is that everything interaction with the underlying OS goes through the syscall package. Also, their designer went for more minimalism. And they didn't have to worry about design mistakes they made 25 years ago. Python is old. I'm not a fan of Gos compatibility promise: it means Go 1 will rot away too. But they're in a much better starting position.)

Post reply on HN