Announcing Rust 1.0 Alpha

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html

by steveklabnik • 12 years ago

894 243 12 years ago

im2w1l• 12 years ago

Great news! Have been waiting for 1.0 to jump into rust. Anyone knows when the final 1.0 will come?

steveklabnik25• 12 years ago

TL;DR: twelve to eighteen weeks. Possibly more six-week increments after that, depending on how we feel during beta. Full details: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

slowmovintarget• 12 years ago

Congratulations! I look forward to seeing the ecosystem expand now that core has solidified. Very exciting.

namelezz2• 12 years ago

Six weeks after Feb 16. On their blog: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

higherpurpose• 12 years ago

Likely around summer, which would be a good time for anyone interested in it to start coding with it.

towelguy• 12 years ago

It is summer right now in half of the world.

azdle• 12 years ago

So that's why I'm suddenly getting all these "warning: use of unstable item" after doing a rustup.

steveklabnik25• 12 years ago

Yes, though you will get fewer tomorrow: https://github.com/rust-lang/rust/pull/20786

heinrich5991• 12 years ago

That won't get you less warnings, it just won't turn these warnings into errors for doc tests.

JeremyMorgan• 12 years ago

Well here we are. I think this is what a lot of folks were looking for, anything before Alpha just seems too bleeding edge. Will be interesting to see what the next year holds for this language.

kibwen7• 12 years ago

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 the aforementioned degree of remaining instability, users should still probably stick to the nightly releases in order to help keep their code up to date and weed out bugs in the compiler.

As ever, it deserves to be reiterated that the 1.0 release does not represent the language being "finished" in any way, only that things will stop breaking. The language will continue evolving rapidly after 1.0, and even the 1.0 release will contain several known (and sometimes rather unfortunate) restrictions that will be backwards-compatibly lifted over time.

Post-1.0, I expect there to be a large community outreach to determine which work to prioritize (for example, I foresee a great clamor for making macros more usable). With developer help I intend to publish a blog post before then detailing exactly which deficiencies Rust 1.0 will contain, and the use cases that they currently either prevent or make awkward.

fallat• 12 years ago

It is now time to begin looking into Rust.

xj9• 12 years ago

Good timing too! I have a few projects coming up that could really benefit from the memory safety and performance features rust offers.

Animats3• 12 years ago

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.

eterm2• 12 years ago

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.

steveklabnik25• 12 years ago

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.

Animats3• 12 years ago

Oh, and what's the matching version of Cargo? Is Cargo still changing so rapidly that it needs to be downloaded nightly?

shadowmint3• 12 years ago

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, other than it was previously said that it would be. There's been a lot of great work going into this release, but the standard library is not ready; it's going to under going some major changes over the next few weeks.

I don't really see the point in hitting the alpha 1.0 now, with the library in it's current state.

steveklabnik25• 12 years ago

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 where things are expected to be in their final form.

erikpukinskis• 12 years ago

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.

weatherlight• 12 years ago

This is Super Exciting!

namelezz2• 12 years ago

Congratulations!

vruiz2• 12 years ago

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?

steveklabnik25• 12 years ago

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.

kibwen7• 12 years ago

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 competition and quality. But eventually (read: no less than a year or two from now) I think it will be up to the project maintainers to officially endorse certain third-party packages and commit to their maintenance. At a certain point, the advantages of a library that's well-known, well-maintained, and well-documented outweigh the disadvantages of de jure ossification.

dragonwriter• 12 years ago

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.

With a good package management system, a batteries-included standard library could just be a set of packages where you are guaranteed that a version of each backward-compatible to the one provided at language release (in SemVer terms, a package with the same major version number as the one packaged with the language release) would be available and maintained for the maintenance life of the language version. It wouldn't have to prevent either bug-fixes to packages out-of-band with language version upgrades, or even out-of-band new major versions of packages that support the existing language versions so long as the old major version was maintained in parallel as long as the language version was.

stormbrew• 12 years ago

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).

megaman821• 12 years ago

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.

vhbit4• 12 years ago

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

killercup• 12 years ago

While others mentioned http://crates.io/ you might also be interested in http://rust-ci.org/ (has categories, includes build status and quite often hosted documentation).

burntsushi• 12 years ago

CSV parsing: https://github.com/BurntSushi/rust-csv

Arg parsing: https://github.com/docopt/docopt.rs

valarauca1• 12 years ago

Congratulations to the rust team. I've been having fun for a while in the language can't wait to start developing serious tools now that we have a stable release :)

Exuma• 12 years ago

Great job rust team! I've been playing around with this lately and it's a lot of fun.

jumanji• 12 years ago

Are there any plans for ARM-support? Last time I looked, it did not seem to be supported.

steveklabnik25• 12 years ago

You'll probably want to check out http://zinc.rs

jnbiche2• 12 years ago

ARM is well supported, and has been for quite some time. Where did you read that there was no ARM support?

odroid-user2• 12 years ago

I attempted to install Rust on my ODROID-XU3 (which is running Lubuntu 14.04.1 LTS) just now by running:

  curl -s https://static.rust-lang.org/rustup.sh | sudo sh

The resulting output was:

  rustup: CFG_CURL             := /usr/bin/curl (7.35.0)
  rustup: CFG_TAR              := /bin/tar (1.27.1)
  rustup: CFG_FILE             := /usr/bin/file (5.14)
  rustup: CFG_SHA256SUM        := /usr/bin/sha256sum (256sum)
  rustup: CFG_SHASUM           := /usr/bin/shasum (5.84)
  rustup: 
  rustup: processing sh args
  rustup: 
  rustup: CFG_PREFIX           :=  
  rustup: CFG_DATE             :=  
  rustup: 
  rustup: validating sh args
  rustup: 
  rustup: error: unknown CPU type: armv7l

What should I do?

simias• 12 years ago

I have written rust programs targeting ARM without any difficulties in the past few months. Both running as linux userland and bare metal.

svraghavan• 12 years ago

Congrats to the whole Rust team. Awesome work. Time to jump in.

jfaucett2• 12 years ago

I feel like this is the moment that so many devs who have observed rust over the past couple of years have been waiting for. I for one am looking forward to diving in.

KenoFischer• 12 years ago

Congratulations to the rust team! Committing to 1.0 is a scary step :).

jnbiche2• 12 years ago

Congrats 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!

adultSwim• 12 years ago

Wake me when we get there

eslaught2• 12 years ago

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!

steveklabnik25• 12 years ago

Thank you. Personally, I try to have strong opinions, weakly held. :)

nickik• 12 years ago

strong opinions, weakly held.

I like that, its mine now.

bjz_6• 12 years ago

Yeah, that was what impressed me at the beginning when I was starting. For example: ripping out classes just after they were documented and implemented, because structs/traits were enough.

mopo2000• 12 years ago

How can you have an alpha without generics?

steveklabnik25• 12 years ago

We have them.

Gankro3• 12 years ago

Like three different kinds, too!

        // Old-style generics; monomorphized 
        // with S as an "input" type of MyTrait
        fn foo<S, T: MyTrait<S>>(elem: T) { ... }

        // Where-clause-style generics; monomorphized, 
        // with S as an "output" (associated) type of MyTrait
        fn foo<S, T>(elem: T) 
        where T: MyTrait<Thing = S> { ... }

        // Trait objects; dynamic dispatch
        fn foo(elem: Box<MyTrait>) { ... }

Twisol• 12 years ago

I think you misunderstood something somewhere. This alpha definitely has generics. For example:

    enum Option<T> { Some{value: T}, None }

nercury3• 12 years ago

You can read up here: http://doc.rust-lang.org/book/generics.html, as well about "output" generics here: https://github.com/rust-lang/rfcs/blob/master/text/0195-asso..., and explore usage in collections here: http://doc.rust-lang.org/nightly/std/collections/.

12423gsd• 12 years ago

Are "Traits" basically C++ Concepts?

nercury3• 12 years ago

To be fair, there were _some_ languages and frameworks which did not have generics on the 1.0 release. It is a bit strange to assert that a new language should.

legulere2• 12 years ago

It's pretty hard to add them afterwards in a backward-compatible way that is not a great hack

pinumbernumber• 12 years ago

It does have generics, unless I'm misunderstanding you

gnuvince2• 12 years ago

Wow. Anyone remembers Rust pre-0.1? When it had typestate, ML syntax, garbage collection, etc.? So nice to see how the language slowly evolved and was molded to fit as best as possible the problem they were trying to solve.

bjz_6• 12 years ago

Yeah, looking through the early commits is really eye-opening.

kibwen7• 12 years ago

It's been a fascinating metamorphosis, undeniably. I'm going to attempt to turn it into an interesting talk for the tentative Rust conference that may be happening this year. :)

riffraff• 12 years ago

is it really "so nice"? I wish they had been able to go forward with typestate :(

aturon• 12 years ago

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!

legulere2• 12 years ago

Wasn't garbage collection actually always just planned but never realized (other than reference counting)?

steveklabnik25• 12 years ago

Sort of, yeah. Gc<T> was just refcount + simple cycle detection.

eslaught2• 12 years ago

Yes, I worked on GC as a summer project. Turned out to be way harder than anyone had thought because LLVM isn't really set up to handle high performance GC. I have a talk on it here:

https://elliottslaughter.com/2012/09/rust-precise-gc/

listic2• 12 years ago

the language slowly evolved and was molded to fit as best as possible the problem they were trying to solve.

Which is...? Wikipedia says [1]

"to be a good language for the creation of large client and server programs that run over the Internet"

and that looks too vague to me.

[1] http://en.wikipedia.org/wiki/Rust_%28programming_language%29...

steveklabnik25• 12 years ago

Memory safety without garbage collection.

bjz_6• 12 years ago

Agreed. I think that description should be updated.

chuwy• 12 years ago

Just started to learn Rust. Could you show me examples of this ancient ML syntax? Just curious how it would look like.

agumonkey• 12 years ago

Deeply second that.

iamdanfox4• 12 years ago

Coincidentally, I used Rust for a little board game solver this week and have been delighted by its performance and typechecker feedback!

My Scala v1 was was very concise but took ~3 seconds to simulate a whole game. The naive Rust rewrite did it in 0.7 seconds and my current version churns them out at 0.015s each!!

http://github.com/iamdanfox/qwirkler if you're curious.. This language is really fun!

kibwen7• 12 years ago

Performance is an area where Rust still has a lot of low-hanging fruit to pick, so I'm happy to hear that you managed to make your version fast. Did you have to make any design compromises to that end? We're very interested in optimizing the typical use cases.

iamdanfox4• 12 years ago

I have currently got some bit-swizzling [1] going on to fit the concept of a Piece into u8. (one of 6 colours and one of 6 shapes). I'd like to turn this back into a nice enum if I can!

Introducing laziness by writing an iterator was actually one of the biggest single improvements (I couldn't figure out the syntax for a while, but lifetimes worked much better than I was expecting)!

[1] https://github.com/iamdanfox/qwirkler/blob/master/src/piece....

mike_hearn2• 12 years ago

Could you post the Scala version as well, for comparison?

iamdanfox4• 12 years ago

Sure: https://github.com/iamdanfox/QwirkleSolver

The Rust version has had some algorithm improvements to reach 0.015s, but it was conceptually identical when it was solving in 0.7s.

TylerE2• 12 years ago

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.

steveklabnik25• 12 years ago

We absolutely want one, but we've been actually developing the conventions first. You have to know what you want to format to!

gthank• 12 years ago

Please tell me those discussions are on the mailing list.

2mur• 12 years ago

gofmt is a huge win for Go. Bye bye bikeshedding. I'd love to see that for Rust too.

cpach2• 12 years ago

I haven’t tried Go yet, but gofmt seems like something that every new language should strongly consider.

bjz_6• 12 years ago

There has been talk of it, and one of the core team members had a prototype. It's most definitely something to look at this year.

mhd5• 12 years ago

indent(1) has been around for ages. Where does this sudden need for universal style goose stepping come from?

esrauch2• 12 years ago

1) A lot more code isn't read in vim or emacs nowadays. We don't have the equivalent of indent on the github web ui

2) Everyone and their mother is doing code reviews now, and a lot of code reviews get (very visibly) bogged down by style disputes.

3) indent and his modern friends (eg clang-format) generally only answer trivial whitespace questions, and not even things like method capitalization. gofmt is the obvious extension of indent.

Morpholemew• 12 years ago

indent(1) is not idempotent, at least not in the configuration I tested, which makes it practically useless as an editor save hook or an SCM pre-commit hook.

Of all the C pretty-printers I tried (about a year ago), clang-format came closest but none were idempotent on the codebase I threw at it.

go fmt is idempotent, which means I use it in an editor save hook. I got used to the convenience, so now I miss an automatic formatter when writing other languages.

__david__• 12 years ago

Ugh. I hate gofmt. It's a good idea in principle, but even with "go" there are times when you want things spaced out to align columns, or hide a distracting error handling case on one line (instead of making it take 3 lines of precious vertical screen real estate).

I find gofmt to be too opinionated about certain things and I will never use it for my go programs.

ptx3• 12 years ago

Why is it a good idea in principle then? Automatic reformatting of the source code always seemed like a bad idea to me for precisely the sort of reason you describe.

wtf_is_up• 12 years ago

I absolutely love go fmt. It's got me spamming ctrl+s in sublime text so much. Everything is clean and uniform.

yazaddaruvala• 12 years ago

gofmt is nice.

gofix: way more useful!

gnuvince2• 12 years ago

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.

hamstergene• 12 years ago

This makes me thinking, since world of coding has already reached the point of using zero-configuration fully automated code formatting tools on save/commit, why not make the final logical step — enforce coding style by language syntax, and be done with almost all extra burden of coding conventions.

Right now almost every company and even separate teams develop their own coding conventions document and configure their tools and infrastructure for it. But if all programmers agree that "coding style does not matter as long as it's consistent" and every one is willing to accept a project's coding style when joining that project, why not pick one style for all and put it into programming languages themselves. I imagine a lot of paperwork and human time would be saved.

snake_case10• 12 years ago

Being a game developer, inheritance is a really important language feature. I'm not one to abuse the power. Currently, for school I've been working on an OpenGL game engine in C++. It's a component based system. The only real inheritance situation that's important to me, is to allow the user of the engine to create any object and make it inherit from GameObject (example: Duck would inherit the members and methods from the GameObject class). Everything else is a component that plugs into GameObjects (Mesh component, Transform component, etc.)

Over Christmas break, I played around with Rust and I'm really enjoying it. However, I can't figure out a nice way to inherit members from other structs. My current idea, like many others, is to keep a pointer to a "parent" object. So, Duck would have a GameObject, rather than be a GameObject.

Does anyone have any recommendations for better ways I can achieve what I would like to do? I will also accept the fact that inheritance is not needed in a language, but it does make a few situations easier.

steveklabnik25• 12 years ago

Something that addresses your concern is coming post 1.0. Servo needs something like inheritance to model the DOM efficiently. It may or may not end up looking like inheritance, though. We determined that our possible solutions are backwards compatible, so we are doing it post 1.0, though.

(Oh, and Rust doesn't get everything Servo needs, what I mean to say is "Servo has demonstrated that there is real-world need for something like inheritance, and so we will add it.")

snake_case10• 12 years ago

That's exactly what I wanted to hear! I heard some mumbles about inheritance coming back in one way or another, mostly on GitHub issues I believe. Can't wait to see what comes of that!

Rusky• 12 years ago

If you want closer performance characteristics and simpler use patterns, in the meantime, storing the parent GameObject by value rather than through a pointer might be easier.

snake_case10• 12 years ago

For some reason I had pointers on the mind. You're right, no real use for pointers in that scenario. Storing by value makes more sense.

yoklov3• 12 years ago

I'm a game developer and I don't use inheritance a lot, and when I do use it it's almost never for virtual dispatch. (I wouldn't mind it being added to Rust, but I don't expect I would use it).

Anyway, if you're already doing a component based system, why do you need inheritance? Just do a normal ECS. You don't subclass GameObjects in most implementations of ECS (and this is a good thing).

dman• 12 years ago

ECS - http://en.wikipedia.org/wiki/Entity_component_system (Just trying to save a lookup for others)

snake_case10• 12 years ago

I guess I should do some more research regarding that. Although, I just liked the idea of inheriting from a base "empty" game object. It makes it easy to have lists of GameObjects. Also, all of my components inherit from a Component class which makes it possible to AddComponent() and GetComponent(). That way, a user of the game engine could create a new type of component and easily add that to any game object. However, I may be over complicating that as well...

Jare2• 12 years ago

Duck would have a GameObject, rather than be a GameObject

Duck should not be a class, it should be a factory function that creates a generic GameObject and configures it with the set of components that allows it to look, walk and quack like a duck.

JoshTriplett• 12 years ago

Can you elaborate on the reasons for that?

snake_case10• 12 years ago

This also is a good solution to my problem. Thanks!

tomlu2• 12 years ago

Solution: Don't inherit from GameObject. Make GameObject "final" and simply be a container of components. Move all object-specific behaviour into the components.

snake_case10• 12 years ago

But, I still need inheritance. DuckComponent would need to inherit from Component in order for my GameObject to add that to the list of components attached.

Am I wrong?

Eleutheria3• 12 years ago

Stupid question...

Why not 'let' and 'var' instead of 'let' and 'let mut'?

It's just so ... weird.

steveklabnik25• 12 years ago

One reason is that let takes a pattern, so you can do things like:

    let (x, mut y) = ...

Another reason is that we feel 'mut' more cleanly communicates mutability than 'var.' Another reason is that we prefer immutability by default, and let/var doesn't communicate that as nicely as let and let mut.

There are some discissions about this on the ML archives, RFC repo, or discuss, if you're interested.

Eleutheria3• 12 years ago

let (x, var y) = ... can easily express the intention.

Also, communication is in the ear of the beholder. Var: variable, that varies. 'Let' would be immutable by default.

Thanks for the response anyway.

tete• 12 years ago

Pretty nice! I mostly used Rust Nightly till now. The language, the ecosystem, etc. seems really mature now. I've been following language development for a while now. I've never seen something that is really a new language and is that far before 1.0 or in such a short time.

The language developed rapidly, without sacrificing reinventing things, changing opinions a lot. I am not sure how they did that, but it's really impressive. Usually languages lack documentation, stability, performance, etc., have lots of rough edges, no users or libraries, but none of that is true for Rust.

I am really curious about how this was achieved. Maybe someone involved could describe how that was possible. I am sure I'm not the only one interested in this.

A year ago there was an article about using Rust for an undergraduate class on operating system development. Rust was 0.7 back then and very different and way more mature.

https://news.ycombinator.com/item?id=7009414

M2Ys4U2• 12 years ago

I'm sure that developing a large application (Servo) in parallel with the language helped quite a bit.

nightpool2• 12 years ago

To be fair, rustc is also a pretty huge application that they (and any self-hosted language) developed in parallel with Rust :D

(I'm pretty sure I remember hearing that rustc has more code at this point then servo does, but don't quote me on that)

cottonseed2• 12 years ago

What the status of Rust for Android/iOS?

steveklabnik25• 12 years ago

Every commit is tested against Android. We just merged a PR that improves our iOS support.

cottonseed2• 12 years ago

Thanks for clarifying. I checked the FAQ and there was a question about Windows support, but not mobile platforms.

For others who are interested, there are instructions here for building Rust for Android and iOS, see "Platforms":

https://github.com/rust-lang/rust/wiki/Docs

vhbit4• 12 years ago

For a long time only 32 bit archs were supported for iOS, but just yesterday a PR landed with preliminary support of 64 bit archs. As Rust uses LLVM for codegen, it means there might be a couple of minor glitches, but overall it should be stable.

Considering that in February Apple will deny apps which do not support arm64 it is just in time :-)

So I'd say that iOS is almost first-class citizen - the only drawback here is that it is not in build bots and therefore `master` can be broken sometimes, in this case you can check https://github.com/vhbit/rust which may lag a bit but is always buildable for iOS.

ChuckMcM• 12 years ago

Awesome job! I so want to port it to the VAX so I can say "I put Rust on some old Iron" :-)

Time to start exploring it again.

mlitchard• 12 years ago

Well, there's been some buzz about rust in the haskell community, which piqued my interest. And now it's time to give it a look.

steveklabnik25• 12 years ago

Lots of us Rust people really like Haskell too. What's the Haskell community say? Have any links I can check out?

ibnukamy• 12 years ago

Congrats and thank you guys for all the hard works.

speg• 12 years ago

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?

tiles• 12 years ago

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

bpicolo• 12 years ago

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.

gchp• 12 years ago

My background is primarily web development, however I've been writing a text editor in rust for a few months now. Prior to that, I had never written any software outside of the web.

Honestly, its not such a big change once you get into it. I'd encourage you to just give it a go, build something just for fun with it. Be it a command line tool, game, whatever. My experience has shown me that just because you've only been involved in web development, by no means limits you from systems/low level development!

MrBra2• 12 years ago

To me it's more like s/he asked if they could build web apps with it, not about their chance to like it considering they come from web apps.

listic2• 12 years ago

Is the Book up-to-date? http://doc.rust-lang.org/1.0.0-alpha/book/

tshepang• 12 years ago

most of the stuff; there are some notes when stuff is outdated

arenaninja• 12 years ago

Just downloaded, I'm excited for this

akavel• 12 years ago

Does anyone know of the Rust Book is available in epub format?

Or, if not, but if it's still possible to build one from source, what are the required dependencies I have to install to be able to build the epub?

gascloud• 12 years ago

It would be more useful in a format which works on Kindle, since that's by far the most common. It wouldn't hurt to support both and also pdf. If there was a single page view of the book it would be quite trivial to export it to a single ebook file.

kasabali• 12 years ago

Open source tooling for creating mobi's are nowhere near epub's and Calibre does a good job of converting epub to mobi, so I don't mind when projects offer only epub, although I'm a heavy mobi user.

swetland• 12 years ago

Is there a way to parallelize the build?

I just checked out the github repo on a quad core 3.4GHz i7 with 16GB ram, and make -j8 took 37 minutes -- the c/cpp stuff (like llvm) built in parallel, but all the rust stuff did not, such that 7 cores (HT) of 8 were idle for the bulk of the build.

alouanchi• 12 years ago

Finally time comes to have a look at it.

builtwithrust• 12 years ago

Hi everyone, Have you guys already had any cool projects and want to share with us? I just quickly made a site here where I would love to showcase your Rust project. http://builtwithrust.com/. Thanks all,

MrBra2• 12 years ago

Quick poll: what's your favourite features in Rust? What's the core reasons for you are going to use it soon?

Announcing Rust 1.0 Alpha

Related Stories