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…
Announcing Rust 1.0 Alpha
191–200 of 255 posts
Re: Announcing Rust 1.0 Alpha
#192Congrats 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…
Re: Announcing Rust 1.0 Alpha
#193The 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.
Re: Announcing Rust 1.0 Alpha
#194Earlier 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…
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
#195Stupid 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/
Re: Announcing Rust 1.0 Alpha
#196Earlier 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.…
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> 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?
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> 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.
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
#199Earlier 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?
Re: Announcing Rust 1.0 Alpha
#200> 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.
2. https://github.com/kud1ing/awesome-rust/ - manually curated list of good libraries