Live data from Hacker News

Announcing Rust 1.0 Alpha

blog.rust-lang.org

191–200 of 255 posts

Re: Announcing Rust 1.0 Alpha

#191

Earlier quoted context omitted.

> Breaking changes will basically cease, with the exception of a list of libraries that are still unstable It's worth noting that this is a significant point; probably 40-50% of the standard library is 'unstable'. You should expect breaking changes often during the alpha. It's just ridiculous to pretend otherwise. I'm not really a fan of these 'artificial deadlines'. There was no reason today had to be the alpha, oth…

The 45% number is misleading, because that's a per-item count. The majority of almost every module is stable, just some of the internals haven't been marked as such yet. In addition, the three modules which will see changes have RFCS that are in their final stages, so they will also stabilize soon. The alpha was always about language items, and an initial commitment to some degree of stability. Beta is the release wh…

[deleted]

Re: Announcing Rust 1.0 Alpha

#192
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…

> Breaking changes will basically cease, with the exception of a list of libraries that are still unstable It's worth noting that this is a significant point; probably 40-50% of the standard library is 'unstable'. You should expect breaking changes often during the alpha. It's just ridiculous to pretend otherwise. I'm not really a fan of these 'artificial deadlines'. There was no reason today had to be the alpha, oth…

Traditionally alpha just means something works. Proofs of concept are often called alpha. Beta means things mostly work, although there can still be many known blocking bugs. Late in the beta* series you would expect true stability to emerge. The release candidates are the first signal of actual stability, maybe.

Re: Announcing Rust 1.0 Alpha

#193
post #69

The one thing that would put rust over the top right now is something along the lines of gofmt - something simple, with zero configuration, that can be run on commit or even save.

Are you sure you're not exaggerating the benefits of an automatic formatting tool? I'm thinking that a large number of libraries, usage by multiple high-profile companies, a killer app, etc. would be better for Rust at this point.

Re: Announcing Rust 1.0 Alpha

#194

Earlier quoted context omitted.

> Breaking changes will basically cease, with the exception of a list of libraries that are still unstable It's worth noting that this is a significant point; probably 40-50% of the standard library is 'unstable'. You should expect breaking changes often during the alpha. It's just ridiculous to pretend otherwise. I'm not really a fan of these 'artificial deadlines'. There was no reason today had to be the alpha, oth…

The 45% number is misleading, because that's a per-item count. The majority of almost every module is stable, just some of the internals haven't been marked as such yet. In addition, the three modules which will see changes have RFCS that are in their final stages, so they will also stabilize soon. The alpha was always about language items, and an initial commitment to some degree of stability. Beta is the release wh…

If the majority of the modules are already stable, why not wait until they are marked as stable, with a more realistic set of #[unstable] in the standard library for the alpha release?

Anyone using the alpha now is being smashed with pointless unstable warnings until they add #![allow(unstable)]

...which basically negates the point of having the lint at all.

Surely a better approach would be; if 'we have no idea where it's at at the moment', don't tag the api as unstable. Tag things which wont make it into 1.0 as unstable, so people start getting meaningful warnings about using api features that won't make it into 1.0.

Seriously, what tangible benefit do 90 warnings about every single api have when you run a compile?

Even if that number slowly drops over the coming weeks, it's still going to be entirely meaningless as an indicator of what will or will not be broken once the beta hits; you're also going to be getting a lot of rubbish feedback from people asking for certain apis (which will be stable for 1.0) to be stable, because of warnings that they're unstable; for example std::fmt.

...while anyone using say, std::raw::TraitObject, or say, alloc::heap::allocate, needs to get a heads up now that they needs to say something and get involved if they want those apis to make it into 1.0

Practically speaking, it feels like you need to roll back to 'unstable' and 'experimental' tags, with the lint warning about experimental, and ignoring unstable.

ie.

'unstable' 'experimental' <---- wont be in 1.0, lint on these

Re: Announcing Rust 1.0 Alpha

#195
post #184
post #183

Stupid question, but how can a web developer relate to Rust? I had to look up 'systems programming' and Wikipedia basically told me it is writing software for certain hardware components. Will I ever be writing a web application in Rust?

Here's a handy guide: http://arewewebyet.com/

Even assuming all those things are complete, it's not necessarily the best fit for your typical consumer web application. Not unlike how you wouldn't generally turn to C++ for one.

Re: Announcing Rust 1.0 Alpha

#196

Earlier quoted context omitted.

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…

> 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? Python, Go, C++'s STL, Java SDK, to name a few. They might not be 100% perfect, but they are good and reliable, and always there for you. Hunting the latest "best" library that gets abandoned after a year (like in Javascript and Ruby often happens, and also Go too) gets old quickly.…

Woah, that's like a list of what not to do with standard libraries, particularly python. Have you seen the datetime module? httplib? Even go has it's weird databases module.

I think is a good example. It gets the job done, its minimal and simple. That's what a standard library should be.

Re: Announcing Rust 1.0 Alpha

#197
post #11

> The core libraries are feature-complete for 1.0. Can someone well informed about Rust give some impressions on the standard library? It is as comprehensive as in python or Go for example?

For someone that is new to Rust how do I discover where the libraries are for the things I need to do?

In the past year I have needed libraries for HTTP, XML, JSON, CSV, arg parsing, image manipulation, PDF, RDBMS, a trie (and other data structures), async i/o, threads, files, ZIP, and others.

Re: Announcing Rust 1.0 Alpha

#198
post #11

> The core libraries are feature-complete for 1.0. Can someone well informed about Rust give some impressions on the standard library? It is as comprehensive as in python or Go for example?

Core team member here. The standard library is _not_ "batteries included," on purpose. Given that we have Cargo, and it works well, tying package updates to the language version has quite a bit of downside, and very little upside. That said, the Rust team itself maintains and provides a number of packages on Crates.io ourselves. Many of these were pulled _out_ of the standard library over the past few months.

I've always thought a good compromise between these approaches, and for a while it kinda looked like at least Rubinius would go to something like it in the Ruby world (but efforts to modularize the ruby stdlib seem to have fizzled somewhat), would be to have a minimal stdlib but a broader set of basically LTS versions of exceptional packages, where they are expected to have important issues backported to a stable version alongside a version of the runtime itself.

This would still allow for pulling up to the bleeding edge, or simply not using, of some of those blessed packages if you choose to by specifying them in the cargo manifest, but would still provide guidance on basic useful packages.

I think it'd also be easier to boot stale packages in new releases (ie. the eternal security fail that is the yaml lib in ruby's stdlib).

Re: Announcing Rust 1.0 Alpha

#199
post #128

Earlier quoted context omitted.

This is a very old post, but you can encode many uses of typestate pretty easily: http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/ It'd be great for someone to write a more up-to-date version of this post!

Haven't used Rust, but I wonder what you could use in place of the phantom types? Are Traits capable of filling this role? Am I completely misreading what Traits are? Can Rust still do phantom types, and I just can't see them anywhere in the language reference?

Yes, you can read a bit about collections and how phantom types are used in them http://cglab.ca/~abeinges/blah/rust-btree-case/

Re: Announcing Rust 1.0 Alpha

#200
post #11

> The core libraries are feature-complete for 1.0. Can someone well informed about Rust give some impressions on the standard library? It is as comprehensive as in python or Go for example?

For someone that is new to Rust how do I discover where the libraries are for the things I need to do? In the past year I have needed libraries for HTTP, XML, JSON, CSV, arg parsing, image manipulation, PDF, RDBMS, a trie (and other data structures), async i/o, threads, files, ZIP, and others.

1. http://crates.io - central repository of rust crates (i.e. packages)

2. https://github.com/kud1ing/awesome-rust/ - manually curated list of good libraries

Post reply on HN