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.
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.
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.
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[..])
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.
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.
> 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.
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".
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.
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.
- 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.
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.
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.
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.
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.
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 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. :)
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.
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.
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.
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).
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).
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.
Does Golang support dynamic linking? I think a Hello world binary in Go is about the same size? I know I'm not really comparing Apples with Apples here.
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.
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.'
[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.
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.
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).
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!
328 comments
[ 3.1 ms ] story [ 263 ms ] thread(Cough.)
The purist REST crowd also has used "RESTafarian" for years, and they're almost indistinguishable when spoken...
On the other hand, I can't imagine there are many rastafarians lurking on tumblr.
I'm finally going to get some real sleep tonight, I think.
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.
The book is in the "trpl" directory: https://github.com/rust-lang/rust/tree/master/src/doc/trpl
The standard library docs are maintained in doc comments in the appropriate places in the source: https://github.com/rust-lang/rust/tree/master/src/libstd
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.
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.)
Oh, and rust-guidelines actually moved in tree: http://doc.rust-lang.org/stable/style/ They haven't yet been linked because of all the FIXMEs.
Thanks for the suggestions. :)
ASCIIDoc or something else might be nice too.
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.
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.
Those implementations should absolutely be in the generated documentation, can you maybe point me to some specific pages? Thanks :)
https://doc.rust-lang.org/collections/struct.BTreeMap.html
https://doc.rust-lang.org/collections/vec_map/struct.VecMap....
ChaChaRng is
http://doc.rust-lang.org/rand/rand/chacha/struct.ChaChaRng.h...
although the other implementations also need this. The main page for rand should probably have this somewhere on it, too.
Thanks for helping :).
ChaChaRng _does_ mention OsRng, but a code sample might help, for sure.
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
which is a pain.Thank you for taking the time to spell it out to me.
HashMap in Rust (dict in Python) doesn't have a canonical ordering of elements, so this doesn't make sense.
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...
Um.......yes? Crap.
It's also one of the few open source projects that has actually gotten me to contribute.
What's the plan on those fronts if they won't be in 1.0?
There are already crates that offer some of this, like mio.
The end user doesn't really care. The line between the standard library and the language is usually invisible.
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.
There's work on non-blocking IO at https://github.com/carllerche/mio, which is looking like one of the more promising approaches, as well as https://github.com/carllerche/eventual which provides higher-level abstractions over it.
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".
My remembering is that it uses a different LLVM version than we use, which is very cutting-edge. So we need them to update before it works well.
A reason why I would choose Rust possibly is because you can prevent data races although with it's memory management model.
- 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.
[1] http://blog.wikimedia.org/2014/12/29/how-we-made-editing-wik...
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.
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.
It's a breaking change, but who would mind?
I also hope they are not too conservative in the beginning, because we might have to pay for mistakes for a long time.
No more "cargo clean; cargo update; cargo build; cargo test;" every day! At last.
github.com/pwoolcoc/cargo-do
[1] https://github.com/phildawes/racer [2] https://github.com/Valloric/YouCompleteMe/issues/1297
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.
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. :)
rust-story builds on 1.0, though, so I think I'll be able to forgive you. ;^)
Congrats on the release!
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!
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.
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.
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.
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.
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.
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.
There was a really great blog post about writing a Scheme implementation, including a GC: http://fitzgeraldnick.com/weblog/60/
https://news.ycombinator.com/item?id=9541138 (two days ago on HN) and its website: https://github.com/servo/servo
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:
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 :-)[1] https://news.ycombinator.com/item?id=9552468
[1] https://news.ycombinator.com/item?id=9553366
(go here to address some other comments):
rust-code: go-code: Compilers: Flags for rust (inspired by[1], which may or may not be similar to what cargo build --release does...): [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? ][1] https://github.com/rust-lang/cargo/blob/c874e37fbe195e86d6dc...
Would using naked println be similar to using putc in C?
Anyway, just tested, and stripped a version without fmt is 414k.
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.
[0] http://golang.org/src/builtin/builtin.go?s=10600:10626#L240
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:
works, that produces a really dynamically linked little binary. One probably wants: This statically compiles in the rust std lib, and leaves a binary that's ~332k after stripping.(Btw, -O is equivalent to -C opt-level=2)
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.
(Also: these things already happen to a degree, and I hope they start happening even more now that 1.0 is out!)
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.
https://github.com/rust-lang/rust/issues/13871
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!