I would like to take this opportunity to formally apologize to the HN community for that time back in early 2012 when I predicted that Rust 1.0 would be released "in about six months or so", and later proceeded to proudly proclaim that 0.4 would be the last release with major breaking changes to the syntax. I hope you all can find it in your hearts to forgive me. :) But at long last, we did it, and it's almost too good to believe.
But as much work as it's been just to get to this point, the real struggle begins today. Months and years of brutal campaigning, compiler engineering, and careful language design lie ahead. If you've yet to take a look at Rust, please do, and report your findings so that we can better prioritize our efforts for the near future. If you like what you see, there's plenty of work to go around and a welcoming community should you decide to dig in and join us. And if you don't like what you see, that's fine too; Rust is not the language to end all languages! We're just here to make the world a little safer, however we can. Hopefully today is but the first page in that story. :)
Thanks for all your hard work on this amazing project. I am currently learning it and liking it a lot!
If I could, make a little suggestion?
Focus on building a community around the language, the way Go did, which was masterfully executed:
Newsgroups, conferences, videos, tutorials, more videos, talks, speeches, more tutorials, books, articles, blogs, docs. All of that, churning non-stop.
It's tedious. It's just as much effort as the language itself. I realize that. But it's truly why I even bothered with Go, which is, IMO, arguably a not-as-exciting language as Rust, yet already has amazing library/community involvement and support.
Being a project that Mozilla is invested in; I bet this is going to happen pretty well. Mozilla does community growth very well, and they care a lot about it.
(Also: these things already happen to a degree, and I hope they start happening even more now that 1.0 is out!)
Even though a solid package manager was enough to get me on board, I deeply agree with you in that building a community around it will make all the difference.
I'd also like to think it will be a bit less difficult for Mozilla to accomplish this because, well, Mozilla's values inspire loyalty, even love in my case, I love Mozilla.
Thank you ever so much for the hard work done by yourself and the rest of the Rust developer community. It has been an absolute pleasure seeing the language evolve, and now that it's hit 1.0, I look forward to the incredible opportunities it makes possible.
It takes great courage to go against the grain in terms of the core language (e.g. abandoning GC, M:N scheduling, etc. as core parts of the language), but the end result promises some truly exciting times. Thank you again and thank you also to you and the others for commenting here on HN despite the heavy criticism at times and being ever so helpful for those of us on IRC. It's been a fantastic ride and I look forward to it getting even better.
> It takes great courage to go against the grain in terms of the core language
So, what I like to say is this: If you look at Rust by mission statement, it hasn't changed at all. If you look at it by feature list, it's a completely different beast.
The focus of Rust has always been a safe, fast, concurrent systems language. It just took a while to figure out exactly how we wanted to accomplish that goal.
And I'm grateful that you took your time to let the language mature.
If Rust fulfills it's mission statement, it might become widely adopted. While that's generally good, it also makes changes to the language hard, see C++.
So, let's hope you got the things right that you can't change without breaking compatibility.
So, in general, Rust should be good for writing VMs. If you want a JIT, though, Rust may not have any super huge advantage with it, specifically, as it would basically be all unsafe anyway.
I'm pretty sure even when building a JIT Rust would provide advantages. The only unsafe part of JITing is allocating the underlying instruction buffer and marking the memory as executable to the OS. You could still leverage Rust in building compilers from IR -> Instructions.
The point is that whenever you do "IR -> Instructions" you are opening the possibility for logic errors to become memory errors. E.g. emitting opcode 9 instead of opcode 8 might (on some system) allow an attacker to execute arbitrary code. And these sorts of bugs cannot be prevented by pure memory safety alone, once you have (intentionally) opened the door to writing executable memory. You would actually need a full theorem prover to check the correctness of your code for you (which obviously Rust does not provide).
For what its worth Java had an even longer gestation period and it wasn't until Eric Schmidt declared that we had to have 1.0 in Bert Sutherland's desk by 1/1/95 or "else" did it actually get to that point.
I'm really excited to start trying it out in earnest.
This is a bit disconcerting though:
ls -lh
total 588K
-rwxrwxr-x 1 cmcmanis cmcmanis 8.4K May 15 13:02 hello_world
-rw-rw-r-- 1 cmcmanis cmcmanis 83 May 15 13:02 hello_world.c
-rwxrwxr-x 1 cmcmanis cmcmanis 565K May 15 13:01 main
-rw-rw-r-- 1 cmcmanis cmcmanis 42 May 15 13:01 main.rs
I'd love to write a safe embedded system in rust and that is going to mean much smaller footprint for a 'hello world' level of program :-)
As you can already read in this thread (see [1]), this is due to static linking of the whole standard library. This limitation is known and solutions are being worked on.
Only one component of the three is really even being worked on, the other two are there: use LTO or dynamically link. Not linking to the standard library itself is behind a feature gate for now, but it should be relatively easy to stabilize in the future.
As steveklabnik (see [1]) stated, there are 3 things missing: dynamic linking, link-time-optimization and the possibility to not link to the standard library. Each of these techniques will be able to reduce the size of Rust binaries.
[ed: to add: If I strip the binaries, hellors ends up at 5.8k, hellogo at 1.3M. I built hellogo with just: "go build hellogo.go" -- I'm not sure if there are any flags that would make sense? ]
Ok. That code is from the go-lang homepage (except for changing the text, so the two programs are mostly identical), so I'm guessing (hoping) it should be considered (more) idiomatic?
Would using naked println be similar to using putc in C?
Anyway, just tested, and stripped a version without fmt is 414k.
I thought println was like puts in C but it appears to be capable of printing multiple types and support a variable number of arguments(?). It has zero dependencies (in theory) and is just a little bootstrapping/diagnostic tool and might even eventually be removed [0]. Importing fmt seems to import the package which adds a lot of bloat to hello world.
But realistically anything more complex than hello world is going to be at least a few MB in go, and eventually you might have to use fmt.Println() and most production code probably does.
Edit: and yes fmt.Println() is idiomatic. I was just mentioning that it is possible for helloworld to be a bit smaller in go than other go programs.
Doing basic imports is a valuable addition to hello world, as it demonstrates the tool-chain is working :-)
I just found out that my rustc-arguments probably were wrong (for most uses, anyway). Or rather, they link dynamically to the rust standard library -- which while "equal" to C, won't hold most of the time. All (non-embedded) systems will have libc for the foreseeable future -- assuming that they have rust libstd is probably not a good assumption to make.
I found this out after I upgraded to rust-1.0, and the lib/libstd-<hash?>.so files changed names.
So while:
rustc -O -C prefer-dynamic -o hello hello.rs
works, that produces a really dynamically linked little binary. One probably wants:
rustc -O -o hello hello.rs
This statically compiles in the rust std lib, and leaves a binary that's ~332k after stripping.
If you are targeting ARM microcontrollers, you may be interested in http://zinc.rs/, which includes only libcore and results in libraries of a few kB (or, hundreds of bytes for just a blinky).
Ok, now we're talking! Made a 'fork' of this repo to start playing with it in parallel. This is exactly my question/investigation which is can you make a nice "safe" embedded OS for bare metal hardware. My thesis is that if you can then a bunch of stuff like embedded routers and IoT things will be safer. And that is a key requirement for this brave new world of 'everything is a computer.'
I'm waiting for this and the dependencies on glibc/libgcc to be sorted out. I keep hearing it should be possible to build lightweight binaries, but the last several times I tried, none of the recipes I found for such a thing actually worked.
That's funny, because I started hacking Rust just because the `~` sigil and friends were gone. :-)
Before that, so many sigils in Rust scared me and kept me from learning it. Rust still has a bit many sigils nowadays, but it's definitely cleaner than before!
>so many sigils in Rust scared me and kept me from learning it.
I had just started seriously learning rust a few months before they started moving owned pointers into `std`.
So I felt somewhat betrayed by the removal of the sigils. It seemed like all the hard work I had spent learning the various pointer types would end up being useless!
Of course that fear was ungrounded. I very quickly came to understand that what I had actually spent time learning was ownership; and _that knowledge_ is still perfectly relevant, even today in rust 1.0.
All that was really changing was the removal of some arcane syntax which had only served as a stumbling block in my quest to learn Rust.
> It seemed like all the hard work I had spent learning the various pointer types would end up being useless!
I always joke about this being "programmer Stockholm syndrome": When you've mastered something that's actually not good at all, don't want that time and effort to have been for nothing, and become a champion for crap. It happens a lot and usually unintentionally - the champion feels genuine joy about the intricacies of what they're pushing and just wants to share it with others. You can see this happening a lot around poorly thought-through and/or overly complex technologies.
This is why Rust's progressive trimming and slimming over the last 1-2 years has been really impressive and gratifying to watch - it really takes a lot to reevaluate and let go. Critics will point out that Rust still is plenty complex, of course, and I think that's healthy skepticism too.
Yep, the dropping of the sigils was a big help in my actually giving the language a chance. It's been on my radar for a while, but went through a pretty ugly period for a while before coming out much better than before.
There was also just a sense of "OK, I get what these things do, but when should I us an @ vs an ~ vs a & in my API", and now I feel like it's much more clear what you use the different reference types for.
That was my reaction as well: not just the sigils, but in general Rust used to have a much larger language, and dropping the sigils was part of a shift towards having a much smaller language and larger library. That seems like a feature, not least of which because libraries can be improved and replaced.
Thanks for your work on Rust, a very cool language. And although the massive 3k poem was removed Rust-created binaries, and it initially pissed me off when I discovered it, thanks to Brian Anderson for sharing.
Any plans to take Rust to the big data arena? Oh how I wish I had Spark Rust API... lower memory footprint, no GC, yet it will be pretty straight forward to migrate Scala / Python jobs to Rust (with a small memory management / borrowing concepts learning curve I assume).
Great, congratulations! Also let's mention Servo (browser engine) - the project has a symbiotic relationship with the Rust programming language, in which it is being developed (also from Mozilla).
That is a GTK GUI application that makes HTTP requests in under 40 lines of code.
Don't get me wrong I love all the safety gaurentes and what not, but just being able to write quick simple apps that would usually be a pain to write in C is a game changer for me. A lot of this is down to Cargo (the Rust package manager, very npm-like imo) and all the great rust libraries that already exist. I'm super excited to see where this goes now that it's 1.0, people can stop worrying about breaking changes in the language and just get down to writing libraries to do everything.
Why is that exciting? You've been able to do that almost line-for-line in Python for at least 8 years, if you're not bothered about the "safety guarantees and what not".
Admittedly, I've never tried using GTK from python and that seems like it does take care of a lot of the "easy" that I'm liking here. However, it's really the combination of everything that rust offers while still letting you make short programs like this.
I really don't mean the downplay all the safety stuff, that is the main reason that I'm interested in rust. I just don't feel like the fact that you can do things so easily in rust gets enough attention.
My biggest "Oh my god, that was awesome!" moment was when I first built the project and Cargo just took care of the whole dependency tree and I never even had to think about it. I've never had that in a low level language before. I've actually been stepping out of a lot of the C that I've been doing into doing more with JS just because NPM makes it so damn easy to whip something up. I'm hopeful that rust will let me come back to a much lower level where a 10MB binary is really large.
Rust is not a replacement for Python, but a replacement for C.
It's exciting that you can have power, portability and speed competitive with C, but with syntax and safety so good that you're comparing them to Python :)
> Rust is not a replacement for Python, but a replacement for C.
I think its a mistake to view any language as simply a 1:1 replacement for an existing language. Newer languages can have the greatest strength in an area currently dominated by one older language (say, Rust with C), and still be better for some applications where another older language would generally be preferred to the first (say, Rust being better than Python at some things where Python would generally be preferred over C.)
Why are you not bothered about the "safety guarantees and what not"? Note that "what not" includes a lot of performance and portability which Python will likely never have, but Rust might.
I agree this is a very good thing by itself, but let's be clear that the extremly poor programmer ergonomics of the GTK-via-C stack have been superseded by nicer kit long ago (even within the GTK community).
That's not much good when you're just talking to ahitty GObject APIs that - guess what! - use reference counted GC and have lots of race conditions. You gain nothing
Yes, you do. Your internal logic doesn't need the overhead of reference counting and can be race-free.
This is how Mac apps tend to be fast: the high-level application logic is reference-counted and uses relatively slow Objective-C dynamic method calls, but things that are performance critical (CoreGraphics, VideoToolbox/AudioCodec, OpenGL, sqlite, the Mach kernel) are written in C and C++.
This is also a general pattern in Rust, cf. unsafe blocks: You wrap code that doesn't adhere to Rust's strict rules (e.g. because it interacts with C) in unsafe { }, disabling various compiler checks and requiring you to check it for correctness manually. Unsafe-ness doesn't bubble up, though, i.e. having an unsafe block within doesn't taint, say, a function - allowing you to silo nasty things away and enforce strict checks around it.
Heck, when doing Objective-C I'd drop down to C++ as quickly as possible just because the language is nicer. I'd be even more inclined to drop down to Rust.
I didn't mean "faster than other platforms", just "not slow". Really it's a testament to the fact that front-end glue logic can often be written in whatever language you want without compromising interactive performance (as long as the implementations of those languages don't require long pauses or something like that), which is something we've known for a long time.
Does this build with something simple like "cargo build" ? It should but I can't test right now on this PC.
If it does than I would disagree - not many other native languages can do that - having a native language with a sane build system, package management and proper modules would be a huge deal on it's own.
Just tried, and it's both a little frighting and a delight to see cargo pull down and build the dependencies. For the information of those that can't test at home, the stripped release build weighs in at 722K, and worked on first try on my Debian Jessie system. Woho!
You might want to add a CC0 license to the project (or something else, but that's usually what I see recommended for "sample code").
Now that Rust reached v1.0, I may finally look into it without the fear of wasting time to learn stuff that will change within next months. (It's quite sad, though, that recently released Debian Jessie won't have it in its main repositories.)
Allow me to ask some questions, because I cannot easily find the answers and they're IMHO crucial for wider Rust adoption:
1. What CPU architectures/platforms Rust currently supports?
2. What's the state of cross-compilation support?
Most of devs have workstation on i386/amd64, but some of us may work with ARM, PowerPC and other architectures. Rust's memory safety seems appealing for embedded solutions, but can it be used there already?
Unless I hover on the 32-bit/64-bit links and read addresses they point to, there's no way to tell whether it's for x86 or ARM for instance. And installation via piping script that is being downloaded to shell is something that shouldn't be present at all.
1. In a sense, anything LLVM supports. Some stuff is more first-class than others, of course. We test every commit on x86, x86_64, and ARM.
2. Exists, but isn't particuarly easy. The biggest hurdle is getting a copy of the standard library for the target platform, then it's pretty easy. It's gonna be a focus in the near-term.
We do test Android on ARM. That's an x86_64 buildbot which builds a cross-compiler to Android on ARM and executes a full test suite on Android emulator using a remote testing support which even includes running gdb remotely.
The official tested support is for V7-A, but V6 support also is in tree.
> installation via piping script that is being downloaded to shell is something that shouldn't be present at all
The alternative is you download a binary and run it, at which point that binary can do whatever the shell script could have done.
(The other alternative is you download source, at which point the Makefile or any other piece of the build that you execute can do whatever the shell script would have done.)
As long as the script is available via https the security is equivalent to the alternatives.
> The other alternative is you download source, at which point the Makefile or any other piece of the build that you execute can do whatever the shell script would have done
Part of the problem with this is that since it's a bootstrapped compiler, and the only one for the language so far, "downloading source" mean you need a binary to compile it with, which devolves to the same problem.
Rust was bootstrapped with an OCaml based compiler. Alas I don't think it has been kept up to date, so you won't be able to use it to compile the v1.0 source. Not sure how many generations in between the last OCaml compilable rust and the current rust you'd need to compile to bootstrap, probably quite a few.
A while back, somebody got Cargo running on an unsupported platform, but bootstrapping was a major problem. The compiler had to bootstrap newer versions of itself tens of times, and that was only for a few weeks of breaking changes …
Rust is going to be the first time I am going to learn a programming language from the day it is born (until now it was tough to learn Rust, given the changing APIs ;).
I see a bright future for Rust. Thanks to Mozilla and the whole community for making it possible.
I wish there could be a site started by the very beginner's to document the learning and adventures one gets from this. I wish it could have people of various expertise, from those never having learned a single language to those with several languages under their belt. I would have a fun time learning alongside them. It will be just like high school all over again.
Congrats to the team and thanks for your hard work! I'm not a Rust developer but it's definitely piqued my interest in doing more native development without being afraid of introducing buffer overflows and other security exploits.
Awesome! I assume you intentionally released this on a Friday just to eat up everyone's weekends :) Thanks for the hard work. As I dig in, I'm hoping that Rust will fit in the "useful and safe" sweet spot in Simon Peyton Jones's diagram here: https://www.youtube.com/watch?v=iSmkqocn0oQ
> I assume you intentionally released this on a Friday just to eat up everyone's weekends :)
Hehe, we didn't choose it for any specific reason, but when we started to do the six-week cycle, it landed on a Friday. I like shipping on Friday for a number of reasons, but there's good reason to pick any particular day.
If you haven't played with Rust yet and are looking for some puzzles to help motivate you to learn, we've updated our Bloomberg CodeCon[1] site to support Rust 1.0. You can login and click the "Challenger Series" to get 17 problems of varying difficulty to solve in Rust.
Requires Twitter or Google+ login. (For me that gets an instant back-button, and the fact that one can't see any of the actual content of the site before logging in makes it worse. But I expect there are good business reasons for it. Anyway, I mention it here because it may save a click or two for others who share my prejudices.)
Wish the problems would come with a sample datasets though
For example, the first problem "gloves" says you have a limit of 1024mb memory, 2s runtime, 100,000 max dataset size
How are you supposed to test that, without going through the motions of generating the data yourself?
EDIT: I do realise you're supposed to use the online editor thing and submit the answers to your server for the code to be judged, but I loathe writing code in my browser, would be nice to test offline in my own editor!
There has been some discussion of adding some language support for something like async/await/yield from other languages, but nothing concrete in the near future on the language front.
So, there's usable third-party libraries for it (at least, if you're on a Unix like platform), language support is in the realm of "it would be nice someday".
> IO is a library concern in Rust, not a language concern.
It often is a language concern: no async/await in the compiler or language-assisted yielding/scheduling means difficult or impossible concurrency model.
With Rust's borrow checker, IO (already unsafe C FFI) + callbacks are hard to write in a pleasing and safe way.
I've been porting some JSON/HTTP API servers from Go to Rust recently, and it's been a really nice experience. Rust has convenient struct serialization just like Go, and Hyper is coming along as a nice (relatively) low-level HTTP library. If you want a higher abstraction HTTP server, go with Iron that builds on Hyper.
The I/O libraries have more work to be done (mostly for the async story), but they're ok for now and the plans I can see look promising. I see a bright future for those of us who like to write robust and high performing API servers, so don't shy away from Rust in that domain!
EDIT: Forgot to say that everyone's very friendly in #rust-webdev where Hyper/Iron authors and others can be found.
With the large box flexibility you get with webdev, I don't know why you would want to use it except for specialized parts. Like a RAW -> jpg transcoder.
- Performance is important even for web applications. For example, after migrating to HHVM, Wikipedia could buy less servers, serve pages faster, and reduce latency.[1] Rust is fast, even compared to other statically compiled languages.
- Safety is also good to have for web development. I personally find it difficult to refactor my Python web applications. This isn't necessarily an advantage of Rust solely, statically typed languages tend to have this property more or less. But Rust does provide more guarantees than ordinary languages do.
One reason: really, really low resource usage. Crates.io is reasonably complex, linking to libgit and such, and still uses roughly 25MB of RAM, constant. A Ruby process is ~30 MB off the bat last I checked, and Rails, well...
Haven't made any direct comparisons (and that would be hard) but from my experience from working with both I would say that you probably won't notice a big difference in RAM usage (< 10% difference).
Not really suitable, more from a dev speed perspective vs Go. You have a GC for example, and the opinionated nature makes managing a large code base better. Also a GC pause isn't a big deal for web apps as far as I know.
A reason why I would choose Rust possibly is because you can prevent data races although with it's memory management model.
Congrats! I've been excited about Rust for a while now, and this gives me a good reason to look into it a bit more. A quick question, though, if it's appropriate in this context:
It seems to me that the borrow checker disallows behavior that I (perhaps naively) wouldn't be concerned about. For example, if I have this C snippet:
{ // Safe C
int *ptr = NULL;
int val = 42;
ptr = &val;
}
Everything is hunky-dory. Translating this to Rust results in this (I think):
{ // Malformed Rust
let ref: &i32;
let val = 42;
ref = &val;
}
Now the borrow checker tells me that "val" doesn't live long enough, because the reference comes to life before the value. It seems like this should be safe behavior, because the reference isn't bound to the value until after the value comes to life.
Can anyone shed some light on this for me? I'm all for safety, but this in particular seems like something that I should be allowed to do.
Well, your first issue is that 'ref' is a keyword, so this doesn't work. Changing to just 'r', you get a 'not long enough' message. This is because you defined them in the order 'ref then val', but they would be destroyed as 'val' then 'ref'. That would leave 'ref' dangling, if even for a moment, like here. That'd be bad.
Well, that whole "ref" thing just shows my ignorance of Rust. Thanks for the information.
> That would leave 'ref' dangling, if even for a moment, like here. That'd be bad.
I'm not sure I agree that it would be bad (except maybe from a purity standpoint). Ref is unreachable during the time it is "pointing" to the out-of-scope "val", so nothing can actually reach the out-of-scope value through ref.
In this specific instance, with these types, sure. Imagine you had two different types, with a destructor defined, which did things. Any amount of code can run between those two things being free'd.
These particular references don't, but many smart pointers do. The borrow checker doesn't currently do something different based on Drop.
You can argue that it would be easier if it just made this work, but at the same time, there would be more special cases. Right now, the rule is very simple.
We'll see once SEME regions and or non-lexical borrows land, though...
Yes, you're correct. One thing people want to improve is Rust's ability to detect situations like this, where there is a dangling pointer but it can't actually affect anything. The current rules are deliberately conservative, and even with these rules we have seen a fair amount of accidental unsafety in weird syntactic edge cases that had to be fixed.
Bug =/= language feature that we want that hasn't been implemented or designed yet, FWIW. Right now the borrow checker is currently performing to spec, but the spec is just a little too restrictive in some cases.
val ceases to exist before the reference ceases to exist, beacuse it's declared after. So after val is destroyed, the reference is invalid. Declare val earlier. Your code would be very nutty in C too.
I think I disagree with the "your code would be nutty in C" comment. Since C requires all variables to be declared at the top of the scope, and the order of declaration doesn't matter for purposes of allocation, there's no reason to worry about the ordering in this case.
(C does not require all variables to be declared at the top of the scope.) Even if you're using a version of C that does, the order of variables implies something about their lifetimes and your code could make somebody refactoring more likely to believe they can lift the pointer out to the containing scope, or put the int in a smaller scope.
It's always exciting reading Rust posts on HN, so very happy about a stable release!!
I can't help but feel the language has a very steep learning curve, however; doing something like making an event-queue-with-callbacks is very hard to write out in Rust if you're a beginner with just the current docs.
I think Rust will benefit greatly if their docs compiled some articles on how to write typical systems-related code (for me, I would love to see how to implement task queues with callback mechanisms).
I thought 1.0 was announced a few weeks ago. Am I going crazy? I mean it's awesome news I'm just confused.
Edit: looks like I'm going crazy. It seemed so vivid too like I actually started checking out the rust documentation and was looking for a book to pick up. Unless everyone is messing with me...
It reminds me of a prank when one of our co-workers left her computer unlocked, one of us sent an email to her from her own account saying "This is a reminder, you were taken by aliens, I am writing this to you so you can remember." She is not technical, so se freaked out a lot. Anyways, Rust 1.0 is released today, so your work of digging into the documentation is not wasted. :)
Thanks so much to everyone who contributed to this milestone. Rust is one of the few pieces of new technology that has made me want to drop everything and dig in to it.
It's also one of the few open source projects that has actually gotten me to contribute.
I think the main problem with the docs right now is that most people looking at them aren't just new to the API, but also new to the lang - it can be quite hard to navigate them if you don't know much about the type system and how APIs may be composed using Rust's various facilities. That is obvious, I guess, but it doesn't stop people from trying.
Some way to conflate the two types of docs might be cool. For example, if there were high-level examples of commonly used API patterns in the std lib ("we use traits in this fashion here to achieve the following goals"), the docs could embed links to them as factoids ("this is an application of <this pattern>"). Heck, even just a ? button next to the "Traits" header linking to the book's Traits section would probably help some folks.
Linking to rust-guidelines in some way to back up the design of various APIs might be cool, too.
(Don't want to be the guy to crash Happy Day with more requests, so I'll just add: Many thanks for all your work, Rust has been tickling my brain in enjoyable ways like nothing else this year.)
We had a long, hard think about it. We had a fairly significant amount of Markdown, the tooling was already written, and on a more personal note, I like the idea of reStructuredText, but I _hate_ writing it. If we'd have overwhelming reason to switch, we still would have, but basically, that's why: not enough reason to overcome momentum.
Steve, wouldn't it be good for the homepage of Rust to have a small news banner/sidebar, so people landing there would be presented with big news?
I do like the homepage for its simplicity, but no-one would know the significance without digging into the 'community' links. If that doesn't seem like an issue, then nevermind. Just a thought.
edit to explain: I'm at work and can't hop into IRC to chat about it.
Do you deal with documentation on parts that have been moved out of std, too?
Some of the hardest parts of the documentation is the functionality hidden behind `impl SomeTrait for SomeStruct`. Eg. `impl PartialOrd for BTreeMap`. What on earth does that do? Or the fact you're meant to make a randomly seeded `ChaChaRng` with `OsRng::new().unwrap().gen()`, which is genius but impossible to guess.
In theory, yes, but I spend most of my time on what's most important, which is the stuff in-tree. I've even been neglecting Cargo, which could use a reorganizaiton at least.
Those implementations should absolutely be in the generated documentation, can you maybe point me to some specific pages? Thanks :)
Thanks. So, I'm not sure what _specifically_ the issue is here with PartialOrd. It has 'impl<K: PartialOrd, V: PartialOrd> PartialOrd for BTreeMap<K, V>', and if you click on PartialOrd, you go to https://doc.rust-lang.org/core/cmp/trait.PartialOrd.html, which has an explanation of what it does. Am I missing something?
ChaChaRng _does_ mention OsRng, but a code sample might help, for sure.
> I'm not sure what _specifically_ the issue is here with PartialOrd.
I know what a partial order is, I just don't know what partial order maps realize. In Python they aren't orderable.
> ChaChaRng _does_ mention OsRng
It says to use OsRng if cryptographic security is needed, not how to seed with it.
The obvious way is something like
let osrng = OsRng::new().unwrap();
let mut key = [0u32; 8];
for word in key.iter_mut() {
*word = osrng.gen();
}
let prng = ChaChaRng::from_seed(&key[..])
Well, when I started learning (around Beta 2, I'm by no means an expert yet but eager to get there!) a lot of the docs about both I/O and type conversions/type casting could've used some work, just to name two features...
Oh, the "T" was confusing me, you mean the standard library docs?
And yeah, there's certainly a ton of weak points. We landed a _lot_ of Rustdoc fixes that make certain things better, but there's still a ton more to write. I've been mostly focusing on the longform docs. I just wanted to make sure that I know where people are having problems, so I can know where to focus my efforts. Thanks.
You can clone the repository, modify it locally, and build and test the docs (yes, the docs get tested, most of the code samples are actually executable tests), or you can just edit them online in GitHub's editor and send a pull request that way if you're just making documentation suggestions that won't need any tests.
Let me begin by saying congratulations to the Rust team and supporting community. I've been following Rust when I realized it would make for a good language to try with robotic controls (due to all the safety stuff). Stupid question time: What does this release mean for the embedded / control systems community? Will you be recommending any specific boards / micros / libraries from now forward? If so, which?
The story for rust in embedded contexts is not quite finished. There are dozens of people writing kernels in rust, there's zinc for arm microcontrollers and I've seen projects for raspi and PSX, so stuff works. It's not great yet, though. Once the allocator api is added to the stdlib it'll be much easier to use the standard library in embedded contexts. There's probably other stuff I don't know about but I know for sure that this is a priority for the near future.
My current approach to the heap problem (I'm working on a toy Rust kernel) is to compile the allocator portions of the standard library (liballoc) with a configuration flag that makes them use a particular set of external functions as the low-level heap allocation machinery. Then, my kernel provides these functions, and all the nice stuff (Box, Vec, etc.) "just works".
Very cool. Going to try to learn some basics this weekend! Exciting times watching (from a spectators points of view) the evolution of Rust to this point. Sounds like more exciting times ahead.
What, and Rustacean doesn't? When we Uplift our Cetacean friends, is this sort of awkward appropriation really how you want to meet the newly-conscious masters of 3/4s of the planet?
I parse 'Rustacean' as appropriating crustaceans, not cetaceans. I'm rather less worried about annoying them, because i eat enough prawn toast that i'm already on their shitlist.
I don't think we currently have a changelog or anything: we were mostly focusing on this new, stable branch this time around. You're right that making a changelog now would be super helpful, I'll add that to the list for next release. Thanks!
Your brain should fire wrong signals when you see mut. I think part of the design of mut is to discourage you from abusing mutable variables. (Personally, I prefer F# forcing you the type mutable).
I'm glad they didn't give it a special prefix because not only would it add unnecessary noise, it would make refactoring tedious. I'd rather give the compiler my intent once, and let it figure out if I violated my own intentions.
One thing I like in the F# toolset is the syntax highlighters will highlight mutable and reference variables different colors. It's a matter of time before Rust developers have that (If they don't already).
That would make refactoring painful I suppose and it's unlike anything in the language. In general the rust devs have tried to get rid of as many sigils as possible anyway so your proposal is very unlikely to gain traction.
As I've pointed out in a previous thread, virtually all of it is from a) iostreams and b) glibc. If you don't statically link glibc (as is the case the vast majority of the time) it's much smaller.
Edit: You made my point for me in your edit :) Leaving my original comment for posterity.
It is possible, with a little manual hacking of the linker and some trickery with storing strings in ELF headers, to get Rust to produces 151-byte executable.
Yes, a simple "Hello World" winds up statically linking a fairly sizeable standard library, in particular anything dealing with strings has to involve a certain amount of UTF-8 manipulation and the formatting and I/O have a lot of features and thus likely fairly large code size. But for the most part that's just fixed overhead, and you can opt out of using the standard library if you want and produce smaller executables.
Congratulations to the team; it is nice to be around when a language is born. I remember when Ruby was born, and most people (that I knew) were like "Huh? Why Ruby, when we have Perl?".
I haven't followed Rust much, but as a total n00b: what are some practical reasons why one would choose to learn Rust? What features does this language have which others (pick: C, C++, D, etc.) don't have? What does it do better than the aforementioned languages? (Please don't take these as a challenge, but as a desire to learn more). Thanks!
Rust manages to fight neck-to-neck with C++ on speed and runtime overhead ("fast" and "effectively none") whilst giving both safety and some really nicely made abstractions.
The one everyone mentions is that Rust gets memory safety without garbage collection. But there are cooler things, like being able to implement units in the type system. Rust also gets safety right in the sense that its defaults are good - its primary random number library has ChaChaRng and IsaacRng instead of a Mersenne Twister, for example.
The sensible library design goes everywhere, from Rust's functional roots, high-quality zero-overhead iteration protocol (none of the mess that C++ gives you) to simple things like a well-designed composable hashing standard.
Even stuff like comparing C++'s move, copy and constructor semantics are much nicer in Rust, and in most cases even lower overhead: everything is a memcpy and is implemented automatically.
I can go on. Rust is one of the few languages that IMHO gets string handling right, and has good unicode support from the outset. It's easier to write error-proof filesystem code than any other language I've used. Threading isn't a mess.
There are disadvantages, such as Rust being one of the hardest languages to learn. Generics are both pervasive and difficult - they're clean unlike in C++ but they're also uncomfortably explicit. There are lots of nonlocal typesystem effects, largely due to the thirst for safety.
But it's a good language. Definitely one of the most exciting I've seen in a while.
> Generics are both pervasive and difficult - they're clean unlike in C++ but they're also uncomfortably explicit.
Maybe it's because I'm used to it, but do you have an example of why you think this? I think with type inference being pervasive, I've never been annoyed by generics. Additionally with type aliases a lot of pain can be avoided.
One of the ugly parts is that call-site type parameters, when given explicitly, have an ugly (but consistent) syntax. This is probably unfixable. Another annoying part is the lack of anonymous return types, which makes some types annoying to read or even impossible to express, but work is being done to improve this now.
> Another annoying part is the lack of anonymous return types, which makes some types annoying to read or even impossible to express
Out of curiosity, impossible to express how? Can't one just store the return value in a variable, investigate its type, then copy-paste that as the function return type?
Well, not really, I was just stretching my brain to think of criticisms you might have been alluding to. I still don't know what is overly explicit about Rust's generics.
> What features does this language have which others (pick: C, C++, D, etc.)
The shortest answer is 'memory safety without garbage collection.' C and C++ don't have 1, D doesn't have 2. D is working on 2, but then it won't have 1.
Secondary reasons: newer, better, more standard tooling, (in some cases, not others: IDE support, not nearly as good. Build system and sharing code? Way better.) Similar concepts in a more orthogonal package. Lack of legacy baggage. Easier (hopefully) for non-systems programmers to get into, as the compiler is there to help. It really depends.
Reasons those languages are better than Rust: adoption, ubiquity, more tutorials and a bigger community.
The introduction in book (linked in announcement) actually explains exactly this, very nicely.
It sounds like this:
Rust is a systems programming language focused on three goals: safety, speed, and concurrency. It maintains these goals without having a garbage collector, making it a useful language for a number of use cases other languages aren’t good at: embedding in other languages, programs with specific space and time requirements, and writing low-level code, like device drivers and operating systems. It improves on current languages targeting this space by having a number of compile-time safety checks that produce no runtime overhead, while eliminating all data races. Rust also aims to achieve ‘zero-cost abstractions’ even though some of these abstractions feel like those of a high-level language. Even then, Rust still allows precise control like a low-level language would.
Aside from many of the other common reasons, Rust is a fun language to code in (once you understand it well). The language design has learned a lot from other languages, and the tooling has been influenced by many other successful ecosystems (npm as a big example) and trendy workflows (the community seems a bit centered around github, which works for me).
A few examples just off the top of my head: the language doesn't hide performance tradeoffs, namespacing makes sense, "zero-cost abstractions" are beautiful and common through the ecosystem, cargo is a wonderful tool for building, creating docs, testing, etc. I've had a lot of fun using Rust to build things I really didn't need it for.
Even if equality was by memory location in the case where the tuple contains pointers, one would still have to work out how equality would work for tuples of non-pointer types.
For example, would (NaN, NaN) match (A, A)? If the implementation makes use of ==, then it wouldn't, and if it uses bitwise equality it would.
Yea perhaps it's just not as easy as haskell. But I was trying to make the meta point that not breaking compatibility between releases can be a bit subjective.
I think the release of the first stable version is an appropriate time to ask how the collaboration with packaging teams from major distributions is going.
Rust is nice, but… Why can't anybody made a language with the exact syntax of Python, but compiled? It doesn't need extreme safety features or other buzzwords.
It's ridiculous of them to downvote you instead of providing an honest answer. This is a good question that I think a lot of Python fans might wonder about.
One of the many great things about Python (and other "dynamic" languages) is how flexible it is in so many ways. Instead of forcing you to be more explicit, make more decisions, and lock more things down in advance, it lets you get away with telling it to figure out a lot of things for itself while the program is running.
This kind of flexibility isn't free. It does a lot of things indirectly, it makes decisions for you and, if they turn out to need changing, it makes those changes as, and so on, while it is running, which requires a lot of computation.
You actually could compile Python, but keeping the "exact syntax" presumably means keeping all of Python's capabilities to be flexible at runtime, so compiling would require essentially building a lot of the Python interpreter right into your compiled app. This, in itself, would just change the packaging and wouldn't buy you much in terms of performance. A lot of clever people are looking for ways to speed up Python without removing features, but it will probably never be possible to make Python as fast as Rust will eventually be, nor to make Rust as convenient as Python.
You might be pleasantly surprised to learn that python by default caches the parsing results between runs. If it makes you feel better, you can think of it as ~partially compiled :) But there is an inherent trade-off between having a lot of flexibility at runtime, and having aggressive code specialization and optimization at compile time. Well, I suppose you could combine those into one language, but you couldn't do both on the same piece of code...
Because syntax isn't that big of a deal to most people, I guess. They are more concerned with actually useful things, like safety features and other buzzwords. ;)
But like mentioned, there is Nim. Which at least have the indentation-thing going for it.
No dice. I also tried to build from source in a VM on that same machine. 32-bit Ubuntu 14.04.2 (3GB of RAM), latest stable toolchain. Again, didn't compile. Core dump.
That is strange; I bootstrap regularly with `--enable-debug` and have not seen an arithmetic overflow during bootstrap (at least, not for a long time).
It would probably be best to carry on a conversation on a formal bug report; did you file one at the url it listed?
I haven't given it a try, but it looks as it provides basic functionality. Since Rust is such a young language, I don't really expect much until at least a few months have passed. We will probably start seeing plugins for Eclipse and other big IDEs in some time.
I was looking to see what UI and database bindings were available as crates and came across the crates.io web site.
It would be useful for people new to Rust to see what existing libraries are available and one way would be to have a link on the www.rust-lang.org site's font page pointing to crates.io site.
Mozilla has several million lines of C++ code. Do you think they would invest substantially in creating an entirely new language with a new ecosystem and from-scratch Servo rewrite if their C++ code could be made secure with C++14 and tons of warnings?
Very exciting! I've worked through the tutorial in the past and enjoyed Rust very much but since then have just been passively following progress on HN. Looking forward to actually building something with it now.
There's lots of stuff that we build, and we say things like, "Language X is slow, but it doesn't matter." "Language Y uses a lot of memory, but it doesn't matter." This is very, very often true. But every once in a while, it really matters.
That's when you want something like Rust. When the details are important. When you need full control, but you'd like a compiler to help catch your mistakes. When a garbage collector has too much overhead. When you need to write something inside of Language X or Y, instead of a C extension, you can use Rust.
Basically, anywhere you'd use C or C++, Rust is a great fit. Elsewhere? Maybe, maybe not. Depends.
Rust is a systems programming language that runs blazingly fast,
prevents nearly all segfaults, and guarantees thread safety.[1]
So, if you care for low memory usage, execution speed or safety guarantees especially for hard-to-debug kind of errors, then Rust might be interesting for you.
It offers low-level access like C or C++ but excels with vastly improved security. So, I'd take that step, and say that where C or C++ is used right now, you might want to use Rust in the future.
Give it some time to mature. Today is the day of the language specification, not the finalization of the toolchain.
The Rust language offers low-level access with amazing security guarantees, and is working on an optimizing toolchain.
Let me take Python as a comparison. It has fundamental[1] roadblocks for being fast on current and probably future hardware, because its dynamic nature requires many indirections which are problematic for CPU cache efficiency.
Will Rust always be faster than C? Probably not, but that is not needed to be blazingly fast. What is important is that there are no fundamental difficulties to be as fast as C.
[1] I know, you can work around some of those indirections.
If you consider that robust and memory efficient parallelization is way more easily achieved in Rust than in C, Rust might already win today for some applications if you limit the developer time. In C it's hard to fulfill the requirements at all.
Humbly suggest the "optimizing performance hasn't been a focus, shipping good language semantics has been" message needs to be repeated louder and clearer.
The expectation that has been created is - "Rust is a systems programming language that runs blazingly fast" - and that may lead to disappointment.
imo it would be helpful to you all, to set a clear expectation that performance will be a priority in some future version but has not been so far. (As that's what you seem to have just said.)
That's all. No reference to "a particular benchmark", or whatever you take "generally fast" to mean.
http://www.areweblazingfastyet.org is free - you'd better grab it before I do :). If you don't take it, I'll just make it return those pieces of the language shootout.
If you want to vapidly denigrate Rust I'd recommend something like, "Pssh. After years and years of wild goose chase, all we get is your basic fleshed out language built around having lifetime types? You can't even make abstractions over monads and lenses. No f128 type?? What's the point of reliable software if you can't use it to calculate hyperspace jumps?"
I'm going to admit upfront that I'm a bit of a rust fanboy but I still have to ask - did you really make an account just to shit on rust on its birthday?
But as much work as it's been just to get to this point, the real struggle begins today. Months and years of brutal campaigning, compiler engineering, and careful language design lie ahead. If you've yet to take a look at Rust, please do, and report your findings so that we can better prioritize our efforts for the near future. If you like what you see, there's plenty of work to go around and a welcoming community should you decide to dig in and join us. And if you don't like what you see, that's fine too; Rust is not the language to end all languages! We're just here to make the world a little safer, however we can. Hopefully today is but the first page in that story. :)