Are there any plans for ARM-support? Last time I looked, it did not seem to be supported.
ARM is well supported, and has been for quite some time. Where did you read that there was no ARM support?
Announcing Rust 1.0 Alpha
31–40 of 255 posts
Re: Announcing Rust 1.0 Alpha
#32Congratulations to the rust team! Committing to 1.0 is a scary step :).
Re: Announcing Rust 1.0 Alpha
#33Congrats 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.
Yes, this is a big deal. I tried looking into Rust a couple of months ago, but the speed of change meant that blog posts and tutorials from just weeks before were sometimes completely broken.
Getting to 1.0 means that the ecosystem has a chance to grow properly which means "lesser" coders such as myself have a chance to learn and get involved.
Re: Announcing Rust 1.0 Alpha
#34Congrats 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.
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.
Re: Announcing Rust 1.0 Alpha
#35Earlier 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'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 think that crates.io still has a ways to go before the situation is ideal. Discoverability of libraries is the first pain point to look at. After that, I'd like to see crates.io automatically parse an uploaded package's docs (thank you, rustdoc!) and host them on the site itself.
Re: Announcing Rust 1.0 Alpha
#36Congrats to the Rust team on all their hard work paying off.
Looking forward to watching Rust expand into almost every corner of the development world: web, applications, systems, embedded, safety-critical, games, hard real-time, on so on!
Re: Announcing Rust 1.0 Alpha
#37Earlier 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'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 components generally bring certain expectations/guarantees about security, reliability, and support.
Re: Announcing Rust 1.0 Alpha
#38Wake me when we get there
Re: Announcing Rust 1.0 Alpha
#39Earlier quoted context omitted.
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.
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 officially supported packages give developers and newbs a place to start, and the community some confidence that libx will be maintained in the future. I really think this solution is the best for seperation of concerns and maximizing developer productivity and efforts.
Re: Announcing Rust 1.0 Alpha
#40Earlier 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!
By extension, language builtins should also never be the place for the best facilities to do $WHATEVER_PARTICULAR_TASK. The line between builtins and standard libraries is extremely variable between languages.