Announcing Rust 1.8
blog.rust-lang.org
blog.rust-lang.org
$ rustup target add x86_64-unknown-linux-musl
info: downloading component 'rust-std' for 'x86_64-unknown-linux-musl'
13.77 MiB / 13.77 MiB (100.00%) 1.47 MiB/s ETA: 0s
info: installing component 'rust-std' for 'x86_64-unknown-linux-musl'
$ cargo build --target x86_64-unknown-linux-musl
Though, I guess Android NDK uses a custom toolchain, linker, so it might not be that easily achieveable. Though it will give Rust an advantage over other newcomers. Crosscompilation for multiple OS'es/Architecture seems like a big selling point.
EDIT: Huh. I guess they do have binaries for arm linux now, at least for nightly and beta versions, as of literally two days ago.
In this document is a perfect example of the problem, they list several Rust RFCs by RFC number, then talk about IP RFC based loopback detection, expecting everyone to know that RFC 6890 refers to an IETF one and not a Rust one. I mean, most of us can infer that just by length of the number, but it is pretty ambiguous especially when they're used in the same document like this.
I've found myself using Rust for little one-off tools and scripts lately because it's so darn easy to type `$ cargo new --bin foobar` on any of the three operating systems I use daily.
There's already a pretty nice ecosystem of web servers, graphics libraries, crypto libraries, etc. -- Not to mention the bindings to existing libs.
At the end of the day I always end up with wicked fast binaries that I can run on Windows, Mac, or Linux with fairly minimal fuss.
---
I really haven't found a language that hits this niche the way Rust does, which is really strange to me considering Rust's mission statement.
No shell scripting language is that easily portable barring something like MinGW.
I've never had what I'd call a pleasant experience using Ruby, Python, or Javascript on Windows. Not to mention if the language runtimes / stdlibs don't demand it: many of the 3rd party libraries assume a *nix toolchain to build all the C extensions.
Go and Java probably come the closest to writing easily portable software, but I personally find writing Rust to be a more fulfilling endeavor.
---
The other day I wrote a tool to deduplicate my image library in Rust. The first binary to compile worked perfectly on both Mac OS and Windows, ran wicked fast (on my SSDs anyways), and it was really a pleasure to write. -- Rust's iterators alone really make for some beautiful code.
---
This was a really long-winded way of saying I love Rust, and thanks for all the hard work ^^,
I wanted to do some pre-build command execution/file moving/etc and was shocked at how little fuss was actually involved.
More work than bash/python? Sure. Worked first time barring logic bugs? Hell yes.
Also +1 on Rust iterators, they're a sublime mix of ownership semantics and functional constructs.
I did think about comparing images by similarity but ultimately tabled it for a later evening because:
- I quickly realized I had a lot of reading to do
- Resolving "similar images" conflicts is a fuzzier, more time intensive process since: (a) maybe the comparison is just plain wrong?, (b) maybe it's not strictly a worse crop, but rather two common aspect ratios which you'd like to keep, (c) maybe it's not actually "watermark" text but rather it's a meme or image macro, etc.
- Personally: my real problem with images of varying sizes is that I download thumbnails by mistake. That's just PEBKAC and no amount of software can fix that.
(Now that I think about it: it might be nice to have a script which iterates over low resolution images and tries to find a large resolution version w/ Google Image Search.)
> I've never had what I'd call a pleasant experience using Ruby, Python, or Javascript on Windows.
Perl is probably the tool you are looking for. There are official technet articles about how to use Perl on Windows. Older, now that powershell exists, but they're there.
If you're already familiar with Ruby I imagine it's not too hard to pick up most most of what you would want to know (except context! Probably the most important thing in Perl to grasp coming from other languages).
With go, I think it's easier to accidentally end up with some kind of not-quite-portable thing, despite the fact that go is a new language.
Interesting (and good!) that you have such a pleasant experience with Rust too.
> The other day I wrote a tool to deduplicate my image library in Rust.
Hm, did you by any chance share that somewhere? I'm planning to do some reinstalls and consolidation of storage, partly from having several machines, and partially from dual-booting (having extra file-systems). I'll probably figure it out with find and xargs or what-not, but a Rust-binary would be a welcome change of pace :-)
// Colliders are bi-directional
impl<T, K> Collider<T> for K where T: Collider<K> {
fn intersect(&self, other: &T) -> Option(Contact) {
other.intersects(self)
}
}I don't want just FP, personally I find it too restrictive.
[Slightly more formally, the first can be rephrased as "no omnipresent non-obvious partiality excluding that from non-termination".]
It's a gateway drug to ML/Haskell-style FP because it eases you into expressive type systems, pattern matching, higher order functions, and pervasive use expressions over statements. Many people have told me that it was much easier to learn Haskell or Ocaml, etc. after learning Rust.
There is no such thing as OO either, and trait objects are not super common in idiomatic Rust anyways.
-No GC, purely RAII based resource management.
-Awesome ownership with first-class support for move semantics.
-Great functional constructs(Sum Types, Pattern Matching and map()/filter()/etc).
-Compiles down to native code via LLVM.
It's not a forced requirement :).
> GC is technically optional in C++, because you can stick pretty much anything in a reference-counted pointer (shared_ptr<T>).
Unfortunately it was pushed out by MIT's cartography-oriented zealots, and we know how well that paradigm worked out!
Moon patiently told the student the following story:
“One day a student came to Moon and said: ‘I understand how to make a better garbage collector...:-P
In my experience, this is not however a significant concern.
edit: this of course implies an easy program with 65 conditionally moved boxes that can't be encoded under your system.
Someday, long from now, I'd like to do a crater run with eager drop and see if anything actually breaks.
(Note that all of these GCs use RAII under the hood, but not in the simple delete-when-destructor way)
Go, Python and Java (or any JVM language) are all high level garbage collected languages that focus on developer productivity. You pay certain costs just as the price of entry, like garbage collection, and the requirement for a fairly hefty runtime. In return you get various useful features.
Examples:
You would not use Rust to write a large complex webapp as part of a corporate team, that spends most of its time talking to databases or message queues. The best tool for this from your list would be Java.
You would not use Rust to write a small script to do system administration tasks or quickly prototyping a new idea. The best tool for this from your list would be Python.
You would not use Rust to write a small, simple command line tool that nonetheless could benefit from being garbage collected. You could use Go for that (I hesitate to say it's the best tool but plenty of people use it in that way).
I would have thought that the Go's concurrency model would give it an edge.
for the record, i ran to python.
I only started using Go in the last couple of years, so I don't know how different it is now from when you tried it last, but I bet you would be pleasantly surprised if you gave it another look.
because your large webapp is made by a large team, over a large time span. The same as you don't deploy on power8 but on x86, because x86 is more common than power8 and cheaper.
One of your java programmers leave ? replace him is easy Need to find java programmers ready to do shitty and boring debugging ? easy Your large webapp is in maintenance mode and nobody internally wants to touch it, so you decide to find a cheap company abroad to outsource the maintenance ? easy
Hard to find these three with Go (or rust, and I love both) because right now it's taught in no large scale university nor a lot of people have been exposed "accidentaly" by it. SO if you have been exposed to Go (or rust) and decide to stik with it it's because you actively decide to, not just because of market force. Hence so you don't belongs to those who will want to do shitty bug fixing 8 hours ago, nor to the price of a developer people hire just to have two more hands, nor the kind who will accept a job under-payed for a outsourcing company.
Java, permits your management to feel they can scale the development
I certainly agree this is a big plus for Java.
here I was playing the devil's advocate, but to have been at both seat (having hard time to hire as a CTO and needing to fallback on PHP in one company / trying to push Rust in my current one) I now see why chosing a stack is not only about tehcnical merits.
Hopefully we aim to not work on such shitty apps. And in such a case, the overhead of learning a new language is dwarfed by the overhead of learning the domain-specific stuff.
And Rust, like any good language seems to have a, coherent(?), or elegant design. Stuff makes sense. As compared to some languages where things are just thrown in willy-nilly. This makes Rust easier to learn, as you can somewhat reason about how things must work.
The only difference is lack of special syntax and being harder to use for basic blog post examples.
Usually people that compare parallel programming in C++, Java or .NET vs Go, never went beyond the basic thread features.
Possibly some of the reason people think they're similar is that Google's internal use case for C++, as I understand it, involves writing things like HTTP API servers in it—things that the rest of us would write in Python/Ruby/etc., or Java. And they do things like statically link the resulting binaries and deploy them in containers. So Go is replacing C++ at Google, but that doesn't have a huge overlap with what the rest of us would consider C++ for. Rust is more suited than Go for many of those use cases (embedded software, kernels, ABI-compatible replacements for things in existing operating systems, etc.).
The other reason is that Rust 0.x once had features that were pretty similar to goroutines, a garbage collector, etc. Those were all removed before 1.0, but the impression still lingers.
----------------------------------------
In term of expressiveness, it offers:
- Expression-based languages (instead of statement-based)
- Has anonymous functions (lambdas)
- It has a match mechanism which is powerful
- Enums are enumerated data-types rather then integer types
- Has traits and explicit implementation blocks for them (vs Go's implicit interface contracts)
----------------------------------------
Other than that, it also offers:
- Built-in concurrency
- It has a thing called the borrow checker that makes sure you're handling memory safely (this will get a little but of getting used to, but it is powerful)
- Everything is private by default. You put `pub` in front of an identifier if you want it to be public
- It isn't very verbose in the Java sense, but you still have to write a crap lot of code in comparison to Go and Python. The trade off is that the code is very explicit, and you get to type more in order to have zero cost abstractions at runtime
- Zero cost abstraction at runtime
Please correct me if any of those points are wrong/misleading, I'd love to learn more about Rust too.
This is a bit misleading, rust does not come with concurrency out of the box. The compiler is able to infer some basic properties of your program to ensure that it is 'concurrency safe'[1] any additional concurrency features are offered through libraries that mostly wrap C libraries. The std lib only comes with system threads, and some basic primitives like mutexes and channels. However, because of these features its fairly easy to build libraries that offer concurrency primitives. For example, `mio`[2] can be used for async socket programming, `rayon`[3] can be used for some parallel computation.
[1] http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht... [2] https://crates.io/crates/mio [3] https://crates.io/crates/rayon
Would you please clarify something to me?
1. So to say that a language has concurrency built-in is, in general, misleading, correct?
2. Than a language may have concurrency primitives, but the capability comes from C through the OS?
In general, very little of Rust is technically "in the language", but to the user, something in the standard library vs the language itself often doesn't matter, it's the same experience either way.
BTW, I remember in the alpha days when the decision was made to make Rust support concurrency in the standard library rather in the language itself. So in that sense (Rust = language spec + stdlib) Rust does have concurrency built-in.
Languages with keywords like `volatile` and `synchronized` have concurrency built in to some degree. Similarly, languages where the concurrency/parallelism system cannot be implemented as a library (e.g. Go) have it built in. So, languages can have concurrency[1] built in; Rust doesn't.
You can duplicate Rust's core concurrency abstractions and safety requirements almost exactly in a library. Rust offers lower-level building blocks as part of the language which can be composed to provide safety from data races.
The only time Rust's stdlib concurrency system factors in to the language is in the behavior of `static mut` (it requires `Sync` types), which is a pretty niche feature and not strictly necessary for safety given that `static mut` is `unsafe` to access.
[1]: Also, "concurrency" is the wrong term to use here, too, but that's a nitpick within a nitpick
> keywords like `volatile`
As other people have posted it seems to compete with C/C++. I am really excited about this since I think there are a lot of problems with C++ we just don't see them because there is no competitor.
For example in C++ reflection and interfacing to other higher level languages is awful. I am hopefully with rust we can do better! That might really open up rust a lot of uses for rust as a language.
Another area where rust is different from python and java: the rust crates in the wild still seem like a wild west of 0.x version packages that break frequently (at least for games programming). It is a great opportunity to contribute to OSS but can also be frustrating.
My recommendation: if you have a pet project unix daemon or CLI tool you wanted to make try it with rust. Most of the rust standard library seems to have stabilized and is nice to use now. For complicated applications be prepared to contribute upstream fixes to crates and bring lots of patience :)
So it's a decent language, but there are other decent languages around these days. I tried to compare them at http://m50d.github.io/2015/09/28/when-rust-makes-sense.html . I'd look at OCaml first, particularly given their relative maturity levels, but if you really can't stand OCaml's syntax then Rust may be worth a look.
Could you explain this? A lack of explanation makes it seem flippant and is probably why your comment is greyed out.
EDIT: https://github.com/kud1ing/awesome-rust
I'm loving the pace of the release cycle! I don't think I can hold off the temptation to try it out - it's too shiny!
We're hoping to do more showing off of our production users in the future. Getting more production Rust in the wild is a big personal goal for me this year.
So it begins.
I don't think we intended to ship the Rust bits by default, but we didn't disable them for release builds, so there you go. It is pretty tiny, just a little bit of mp4 parsing code that (IIRC) we're running in parallel with the existing C++ code: https://dxr.mozilla.org/mozilla-central/source/media/libstag...
If you run your Firefox from a console and browse sites that serve you shady mp4 files you can see the occasional panic message as it fails to parse something! :)
If I understand correctly, having it disabled on Firefox 45 beta broke the build because of a script that tests whether the beta build config matches the nightly config. This forced a decision, and release engineering opted to enable it. So it wasn't planned long in advance, but it was a conscious decision at the time 45 went to beta.
It's a pretty small bit of code right now, and it's not on the critical path for anything, so I don't think it's harmful.
Q: Which companies use rust in production? A: Dropbox, Mozilla, Skylight, OneSignal, etc with links to the relevant tech blog posts.
I think there once was such a Q but it seems to have gone or I can't find it anymore.
The goal here was a single binary that would work on most modern Linux distributions, and which could make some HTTP calls and then exec another program, typically all from inside a Docker container.
Rust was a bit overkill for this, but we already had a couple of the necessary libraries available from in-house experiments, and it was fun to write. The two best features of Rust for this project were: (1) If the program compiled, there was a 95+% chance it would work flawlessly on the first try, and (2) Cargo was really just lovely all around.
Was the prediction accurate in that case? Sounds like it so far.
We are still working on musl as a host, it's not there yet, in my understanding. Cross-compiling to it should be easy, but that doesn't help much if you're on Alpine.
In the beginning, there was rustup. And it was good. Then, Rust matured, and we started the release channels. Now there wasn't just "Rust 0.9", there was Rust stable, beta, 1.0, 1.1... so many versions. rustup.sh wasn't really built to handle that.
And so, multirust was born. mutlirust was/is a bash-based shell script that wraps up rustup and gives you the ability to manage multiple installs of Rust. And fun things like "this project uses rust stable, but this project uses Rust 1.1" and "please update every Rust I have installed". Stuff like that.
But it was a bash script. Nobody knew that this whole Bash in Windows thing was happening. And we already have a perfectly good, general purpose programming language that runs on all the platforms Rust supports: Rust! So the multirust-rs project was begun, to re-write multirust in Rust.
Once that started to become closer to being finished, we took a step back, looked holistically at all of this, and thought "If we started from scratch, what would we do?" https://public.etherpad-mozilla.org/p/rustup-new-experience
And so, "rustup" was born. It's pretty much multirust.rs, but without trying to mimic the old multirust itself. There's still lots of stuff to do before it's ready to become the default way you manage rust installations: https://internals.rust-lang.org/t/beta-testing-rustup-rs/331... and https://github.com/rust-lang-nursery/rustup.rs/issues?q=is%3... And of course, many people will want to use their system package manager too. Choice is good. They also play together. But that's for another post, this one is already getting long.
You can find rustup here: https://www.rustup.rs/
It's always much preferable to have as few dependencies for bootstrapping a platform as possible. Therefore, this is a good development.
Similarly, I'm hopeful the Python requirement in the new Rust based build system for rust itself will be removed sooner than later. Building Rust already requires Rust, so what's more logical than replacing the Python part with Rust. It will definitely be easier to get going than having to install some Python modules first. Same improvement should happen in servo's build system which since a few months or a little longer depends on virtualenv.
You might want to join #rust-tools on mozilla's IRC for better help, I bet this is offtopic for a lot of HN.
https://github.com/rust-lang-nursery/rustup.rs/blob/master/R...
I understand your skepticism, but we care about this use case and are working to make it easy.
does it have native support for
- vectorization/SIMD
- hinting at likely branches
- prefetching memory
- forcing or blocking inlining
and all the magic in gcc C extensions
Branch hint intrinsic: an accepted RFC but not yet implemented https://github.com/rust-lang/rust/issues/26179
Prefetch intrinsic: Looks like a rejected rfc https://github.com/rust-lang/rfcs/pull/125
Inlining: As far as I understand the attributes are #[inline(always)] and #[inline(never)] respectively.
But it looks like low level optimization is a low priority for the Rust project at the moment.
(prefetch is rejected b/c of insufficient testing and branch hinting might get hampered b/c Rust developers aren't trusted to use them correctly)
Maybe I'll revisit it in the future! Appreciate the help =)
IDE is a current goal : https://www.rust-lang.org/ides.html