Hacker News new | past | comments | ask | show | jobs | submit login
Announcing Rust 1.8 (rust-lang.org)
348 points by steveklabnik on April 14, 2016 | hide | past | favorite | 155 comments



It's not mentioned in the post, but 1.8 also includes support for installing additional versions of the stdlib for other targets using rustup/multirust[1], which is huge for cross compilation:

  $ 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'
Which allows:

  $ cargo build --target x86_64-unknown-linux-musl
You can get a list of available targets with `rustc --print target-list`.

[1] https://www.rustup.rs/


Yeah, I didn't mention it in the post because rustup is still in beta. Once it's officially ready to go, trust me, I will start talking about it a lot :)


I wonder if in the long run it will be possible to generate an Android APK without having the Android NDK/SDK installed. Since it could link against the Android's stdlib.

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.


https://users.rust-lang.org/t/psa-rustc-cargo-can-now-be-ins...


Yep. That's exactly what I was thinking about. Rust just keeps getting better and better.


This is definitely going to be big for enabling cross compiling. I've been fighting to get things working sanely. Is there any info on how one would build a new stdlib/corelib for a target? I'm actually anxious to see how much it might help to be able to use Rust on small ARM processors.


We don't have great docs on it yet. https://github.com/japaric/rust-cross is some info. Once we have stuff all in place exactly as we want it, I will be working on good docs to make it much easier for people, but it's still a bit wild-west at the moment.


Good to know that docs will be forthcoming. that link is where i've been working from, and it will usually work but sometimes when i'm upgrading rust it'll just magically not work and i've never figured out why, hence the wild west as you put it. It's definitely looking more and more awesome to be able to get that stuff working.


Are official rustc and cargo releases to be expected for running natively on the tier2 platforms (e.g. official rustc for Linux on ARMv7 that targets Linux on ARMv7)?


Exact platform support, including "cross compile only" or "rustc/cargo runs on it" are listed here: https://doc.rust-lang.org/book/getting-started.html#platform...


It's probably not out of the question, though are there a lot of people out there who want to actually develop on e.g. Android rather than just targeting it?


My laptop is armv7 linux, and not being able to run rustc on it has been annoying. Well, I did find some binary of some old version somewhere, but it's of limited usefulness since it's old, and it didn't come with cargo, which also wants to bootstrap itself from a native binary. The last time I tried it, I couldn't even cross-compile an ARM rustc from x86_64, because the build scripts wanted to run the binary they were building. This is literally the only reason I've been using C and not Rust (which would have been a much more suitable language) for my latest project.

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.


Maybe not on Android but on GNU/Linux on something other than x86/x86_64 sure.


Having just acquired a pixel c tablet, I am increasingly looking forward to being able to iterate on my rust projects while being highly mobile. I don't see it as a primary development platform in the near future, but absolutely invaluable as an auxiliary one.


The last time I checked android compiling looked very complicated, tons of steps, tool chain setup for Windows. I hope one day it's as simple as flagging the build for the specified architecture.


Looks cool. Will it support targeting Windows from Linux and vice versa?


rustc/cargo support any target for which a Rust stdlib is distributed, but you are left on your own to install and manage other software which will be needed to do the compilation such as a C cross-compiler for the target, etc. This is much more troublesome for some combinations of host/target than others. Personally, I have yet to get OS X --> Linux working, but Linux/glibc --> Linux/musl was pretty easy.


They should probably change their terminology away from "RFC" for referring to Rust RFCs rather than IETF ones. Maybe RRFCs or REPs something?

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 have the same thought running through my head while perusing each Rust announcement. Python has the Python Enhancement Proposal[1], and Bitcoin has their Bitcoin Improvement Proposal[2]. On the flip side, this does have the side effect of forcing me to click through to each Rust RFC linked in the announcements just to be sure.

[1] https://www.python.org/dev/peps/

[2] https://github.com/bitcoin/bips


RIP in peace! (Rust Improvement Proposal)


I always thought RFC was generic (and/or predates IETF). Is that not true?


It is generic and does predate IETF but it's ambiguous to which reference material if the number ranges intersect.


It is generic. IETF's RFCs are only one example.


I'm fine with projects locally using "RFC" for their own purposes, but you're correct in that once you start referring to other concepts with the same initialism one should explicitly say "IETF RFC". Namespacing matters. :)


Ember.js uses a similar naming convention. I'm not sure that it's that important to distinguish from IETF RFCs. Especially since the RFCs are linked in that document.


PHP uses the RFC terminology itself, too.


Rather than changing the name (and then me having no idea what a PEP or BIP or whatever is until I look it up—not a good way for a piece of language to work), I'd suggest namespacing the number. "RFC rust/1386" or somesuch.


I've been using Rust more and more for my personal projects. Frankly, I could not give a hoot about the memory management; it's pretty cumbersome to deal with. What I love about Rust is that it's a low overhead language that uses interfaces. I love interfaces! I honestly think that they're the best way to program.


I'm glad you like it :) I'm happy to see more emphasis on the productivity-related aspects of Rust. I talk about memory safety a lot because people ask questions like "what one feature makes you different from C++11?", but the productivity-boosting features like traits and Cargo are just as important in my mind.


The importance of Cargo / crates.io cannot be understated, I think.

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 had somewhat of a similar experience setting up a build.rs for a crate.

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've actually found python3 to be surprisingly pleasant on windows (10), while go has been just ok. I think it is mostly a culture thing: python has a long history of cross-platform, and I think the odds are better that some utility written in/ported to python3 will use the various facilities python provides for "just working" cross platform. It also helps that python3 made virtualenvs part of the standard library.

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


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

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


Out of curiosity, what methods did you use for image dedupes? Simple file hash, or something more complex to find e.g. watermark vs no, different crops/scales, etc.?


At the moment it is just hash based, which actually remedied most of my immediate problem. (I have 8 drives in my workstation. Many of them are donors from computers long gone. [Portions of] my image library have just been copied around many times without much rhyme or reason. Now it's centralized and properly backed up.)

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


This has been one of the biggest things I've enjoyed about it as well! Building cross-platform applications is generally a nightmare. In C++ you have to figure out a build system and dependencies on your own, and also you're writing C++ which is terrible. In scripting languages you either have to require users to install the runtime or you have to use packaging tools that are of variable quality. Being able to write cross-platform code with sane package management and compile down to native binaries takes away a huge headache!


Also, the ability to add template specifiers to implementations is probably the most powerful restricted generic programming technique I've seen. For example, it fills me with joy to be able write lines like this:

    // 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)
       }
    }


As a professional C++ developer, this makes me jealous ;) Waiting for Concepts has become a Duke Nukem meme.


What do you mean by that? Is it different than what you can do in C++ with inheritance (leaving out implementation inheritance)? I'm sure it is probably a little less verbose as the syntax in C++ is odd. C++ 11 adds 'override' which helps.


No, it is not. Pure virtual classes are the same as interfaces. But I only use pure virtual functions, so why mix in non-pure virtual classes?


One difference is that you can implement a new trait for someone else's type.


Aka why Rust is FP gateway drug :P.


Don't think I agree. Rust compromises between FP and OO, and I think it's awesome for it. You get the best of both worlds.

I don't want just FP, personally I find it too restrictive.


Ok ok, the actual truth is that there is no such thing as "functional languages". Rust is a good demonstration that languages that offer the ability to statically prevent bullshit are the best---and does so with a familiar syntax, familiar mutation, etc so as not to trip people's buttons.

There is no such thing as OO either, and trait objects are not super common in idiomatic Rust anyways.


I would say that it compromises between ML/Haskell-style FP and procedural. It doesn't have much to do with OO, bar trait objects, and the dot operator (which is almost entirely syntactic sugar).

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.


Ah, you beat me to it :).


Yeah, there's "FP" and there's "FP-style," and having FP-style usually gets you 80% of the way to what you want.


All I ask of a language (other things are nice but not required) is no "runtime type errors" and no data races. Haskell, Rust, OCaml give me these things.

[Slightly more formally, the first can be rephrased as "no omnipresent non-obvious partiality excluding that from non-termination".]


I never got around to use Rust, maybe I'll get some good answers here on HN, how does Rust compare with Go/Python/Java?


They aren't really comparable. Rust is a lower level language that primarily competes with C++ (finally! C++ badly needs the competition). C++ is still around because it is one of the few languages that has a pay-as-you-go model to features and is not GCd, so, you can reasonably do things like write embedded software for micro-controllers, or kernels, etc.

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


Yup. Think of Go as a compiled Python/Ruby/etc.-family language; think of Rust as a fixed C++ with some influence from functional programming.

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.


Actually, once the ecosystem is fully there (probably ~6 months to a year), Rust would make a great contender for a complex, large web app. The type system Rust uses alone is worth it...


And if it ever gets Higher-Kinded Types worked out... I'll have to get a drool cup.


I'd just note that Rust isn't that hard to use for higher-level stuff. I am working on a network search engine (capture all traffic, index, search). At first I though I'd just write the capture agents in Rust, maybe some of the PCAP-storage stuff. Then write the entire query engine in F#. More and more, I'm realising I can write a much larger portion in Rust, and leave F# for the parts where performance totally doesn't matter (mainly interfacing with the end-user). It's pretty amazing.


I have found that using Go for system administration tasks could be more productive than Python. Go static types help to discover typos quicker and even with Go 1.5 small programs compiles and start faster than Python starts a script doing the same.


Python just standardized a good bit of static typing! I haven't gotten around to playing with it though.


I'm curious as to what makes you think that Java is preferable to Go for a large webapp that "spends most of its time talking to databases or message queues".

I would have thought that the Go's concurrency model would give it an edge.


> I'm curious as to what makes you think that Java is preferable to Go for a large webapp that

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


Not that this invalidates your point, but there are two university classes being taught in Rust right now; I had the pleasure of guest lecturing at Penn's yesterday, in fact. Here's hoping to more of those in the future.

I certainly agree this is a big plus for Java.


ah great to know ! I also hope to see more in the future.

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.


I think the key word is "shitty". If you're working on a shitty app then aim for shitty languages with developers that don't care.

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.


last time i tried to do serious work with go and mssql, i ran away screaming. maybe situation isn't that dire now (this was almost a couple of years ago), but it's hard to beat java in db connectivity.

for the record, i ran to python.


I've used Go in a lot of database work as of late, and it's done a fine job for me. I've used it to connect to MS SQL, PostgreSQL, and Teradata. The Teradata connection was a little tricky, as nobody had written a Go/Teradata driver yet and I had to route it through Windows ODBC, but once I had that sorted out it worked just fine.

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.


Java has support for Go-like concurrency and much more in java.lang.concurrency packages.

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.


Here's my perception of Rust: It is a system's low level language (more like C or C++) that is very expressive. It's performance is compared to C++, so faster than Go/Python/Java.

----------------------------------------

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.


> - Built-in concurrency

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


Thanks for the explanation.

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?


It's more like "We designed the type system to take concurrency into account, and then provided various types ourselves in the standard library (like Send/Sync) to be used with them. We also provide a bunch of concurrency abstractions and tools, in the standard library, but due to the guarantees being more in the type system, others can also write their own. Some of these do rely on OS-level capabilities as well.

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.


That's very insightful. So my understanding now it that Rust provides low level "blocks" that, as a whole, is an extensible language. Thus language vs standard library doesn't really matter, since Rust = Language spec + standard library. Am I getting close to its definition?

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.


Well, using Rust without the standard library is a big use-case: stuff like device drivers, OSes, embedded, things like that. So to some users, it matters. But there's little use overly qualifying what you're talking about when you're just talking, so someone might say "Rust" to mean "Rust + std + crates.io crates" or "Just the language, no standard library", based on context. But once you get into the details, it's important to get at exactly what you mean.


> So to say that a language has concurrency built-in is, in general, misleading, correct?

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`
Obligatory link: https://software.intel.com/en-us/blogs/2007/11/30/volatile-a...


That blog post is about C's `volatile`. Java's `volatile` is for concurrency (also its `synchronized`)


After using rust a bit I would say that unless you requirements dictate being very frugal around things like memory allocation and speed etc.. I would not use rust to write said application.

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


Things that I really like:

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


Nitpick: GC is technically optional in Rust, because you can stick pretty much anything in a reference-counted box or an atomically-reference-counted box (Rc<T> or Arc<T>). It's not the default by any means though.


One day a student came to Moon and said: “I understand how to make a better garbage collector. We must keep a reference count of the pointers to each cons.”

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


Nitpick: Rust includes a GC. Box<T> is reference counted, although the reference count is always 1 until it is released by the owner, then it reaches 0. The reference counts are inferred statically for the most part.

:-P


Always inferred statically for box.


No, if you conditionally move a box, there needs to be runtime checks for whether that condition occured when in it goes out of scope. (note that reassignment of a variable effectively causes the old value to go out of scope -- this may have Implications for your loops, though I sure hope you aren't making and destroying boxes in a loop!)

In my experience, this is not however a significant concern.


Ooops yeah forgot about https://github.com/rust-lang/rfcs/blob/master/text/0320-nonz.... [To be perfectly pendantic, one could trade the drop flags for code bloat and have only a finite blow up and statically known everywhere, so its a "weak" form of dynamism.]


Yeah I guess you could have exponentially many statically compiled paths for each combination of drop flags... but then you're just encoding your drop flags in the instruction pointer :)

edit: this of course implies an easy program with 65 conditionally moved boxes that can't be encoded under your system.


It's all true.

Someday, long from now, I'd like to do a crater run with eager drop and see if anything actually breaks.


CStrings and drop guards everywhere break


Sure, much like C/C++ could have GC by embedding Lua, Spidermonkey, etc(fun fact Epic implemented their own C++ based GC for Unreal3).

It's not a forced requirement :).


Hell,

> GC is technically optional in C++, because you can stick pretty much anything in a reference-counted pointer (shared_ptr<T>).


week_ptr<T> - keeps a pointer for a week.


I really wish calendar-oriented programming had taken better hold in the 80's. It's a really elegant paradigm with great separation of concerns. Being able to shard data out into timezones with inter-timezone accesses requiring a delay equal to their clock differences completely eliminates races!

Unfortunately it was pushed out by MIT's cartography-oriented zealots, and we know how well that paradigm worked out!


I am unironically into both of these ideas.


Since C++11, C++ has a standard API for GC integration.


Or use https://github.com/manishearth/rust-gc, https://github.com/fitzgen/rajan-bacon-cc


Or Spidermonkey's GC, correct? My point was more about RAII not being the only resource management strategy.


Yeah, Servo uses SM's GC for its javascripty things, it sort of has to. Hooking into spidermonkey to get a GC for a program where you just want a GC and not Javascript is suboptimal though.

(Note that all of these GCs use RAII under the hood, but not in the simple delete-when-destructor way)


Rust is an entirely different paradigm than Go, Python or Java... It's sort of like C++ meets modern functional lanauges like Scala.


That's a very broad question. Rust does the things that I would say are table stakes for a decent programming language these days: decent type system (similar safety to Java) with type inference (similar conciseness to Python), a sensible approach to errors (errors are values as in Go, but since Rust is a non-joke language it doesn't need to special-case errors at the language level, they're just another type of value). Its unique thing is the semi-manual (but safe) memory management, but if you needed that then you would know you needed that, otherwise it's not terribly important to you.

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.


> it doesn't need to special-case errors at the language level

Could you explain this? A lack of explanation makes it seem flippant and is probably why your comment is greyed out.


Rust error-handling https://doc.rust-lang.org/book/error-handling.html - Result is just an ordinary type defined in the language. Whereas go's "if err, res" stuff is special-cased - e.g. you can't use your own custom representation of error vs not.


Tutorial's pretty quick and gets you a good idea of what they're shooting for. https://doc.rust-lang.org/book/README.html


Anyone know of any real world applications using Rust?

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!


I gave a talk at a conference this week called "Rust in Production". Some of the companies I highlighted included Dropbox, Skylight.io, and well, Firefox ;)

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.


I think "Rust in Production" should be added to the FAQ. It does not seem to fit in with https://www.rust-lang.org/faq.html#how-does-mozilla-use-rust or the following question regarding large rust projects.

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.


Website stuff related to this is coming, don't worry.


Is there currently Rust code as part of Firefox, or are you talking about the expected future integration of Servo?


See my response to your sibling.


Is Firefox using any rust in production yet?


I'm not on the platform team, but my understanding is that if you're on OS X or Linux, and you grab Firefox 45 right now, there's a _tiny tiny_ bit of Rust code in there. Windows will be in 46 or 47, IIRC?

So it begins.


It will be in Windows builds in 47: https://bugzilla.mozilla.org/show_bug.cgi?id=1248461 .

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! :)


http://bugzil.la/1243363 is where Rust code was enabled for Firefox 45 beta/release on Linux and Mac.

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.


Thanks for digging that up. I recall having the discussions where we thought we'd let it bake for a while before it shipped, but I guess it was intentional, even if a bit last-minute. :)

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.


It's a really tiny thing, but Faraday uses https://github.com/faradayio/credentials_to_env to download secure credentials from a Vault server, and write them to environment variables or files. Alternatively, you can just pass in environment variables manually and ignore Vault (for testing, etc.). This acts as glue for existing programs that don't know about Vault. This is actual production code, even if it's really minor.

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.


We just released a data pipeline runner in Rust. Starting small but we have grand ambitions: https://github.com/snowplow/factotum


Ah this is neat! I missed this somehow :)


Skylight[0] I believe uses rust to monitor rails apps.

[0] https://www.skylight.io


Congratulations. Particularly, I think the Tier 1 i686 might get Rust more adoption by Windows C/C++ crowds in commercial sector. Improvements for large files in Linux might aid adoption in backup/archive and streaming servers. Just curious, did Dropbox's feedback have anything to do with that?


The large file improvements were only needed on 32-bit platforms, and I'd assume that Dropbox's servers are all 64-bit.


Correct, they're all 64-bit linux. We might use some Rust on 32-bit soon though. So this is interesting to us.


Alright,thanks. I was just curious if a single deployment on their level led to bugfixes or new features.


The Rust team has been in constant contact with the Dropbox team (I should know, I coordinated and attended the original meeting), and I can say for certain that feedback from Dropbox has helped to prioritize and inform the stabilization of several features.


Cool, cool. I figured that would be the case. Tge idea behind the questions is kind of my exploration into the many eyes idea. It mostly covers feedback from widespread, random use. Howevet, I figured a small number of smart, industrial users stress-testing a new language/compiler might provide higher than average quality feedback than even twice as many casual developers. So my advice was to try to get such testers soon as key stuff is stable.

Was the prediction accurate in that case? Sounds like it so far.


Any word on linux-musl builds so that you can use official rust builds on alpine or void linux? Same question for FreeBSD builds.


Regarding BSDs: https://users.rust-lang.org/t/psa-rustc-cargo-can-now-be-ins...

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.


So, rustup should ask before modifying ~/.profile, this is what opam does. Also, it'd be great to have a directory listing for the rustup-setup executables, because I don't run random shell scripts piped from curl, so I had to reconstruct the URL for what the shell script would have downloaded. Anyway, I'm glad multirust functionality is getting mainlined, because it's a PITA to build many things, like for example rustup.rs, which require nightly rust features.


So, I should be able to run rustup on FreeBSD 10/11 and it will install 1.8, right? If so, excellent!


I believe so, though I haven't tried it myself, I just know of that post :)


Wait, is this a different rustup than rustup the shell script?


Yes. I might as well take the time to elaborate on the history here.

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/


Thanks for the backstory.

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.


Looks like, and I take it that there are builds for freebsd and netbsd which the bootstrapping shell script will fetch and then have the rustup.rs executable for freebsd ready. Is that correct?


Hmm, weird that there's no ~/.rustup, where all the downloaded toolchains should be stored. Wondering where they are for real...


Aah, the README is wrong, figured out it's ~/.multirust.


It's still in ~/.multirust for now, it wasn't changed yet. Beta!

You might want to join #rust-tools on mozilla's IRC for better help, I bet this is offtopic for a lot of HN.


Yeah the README has it wrong.

https://github.com/rust-lang-nursery/rustup.rs/blob/master/R...


Does anyone have any information about when/if we will see support for higher-kinded types in Rust? There is the RFC thread on Github (https://github.com/rust-lang/rfcs/issues/324), but I haven't been following the trajectory very closely, and a quick synopsis would be wonderful and appreciated.


Higher-kinded types are a far-future enhancement. There are several language-level features that I would expect to be prioritized far above HKT; off the top of my head: specialization (an early prototype implementation of this is in nightly), placement-new, type-level numerics, stabilized syntax extensions, and non-lexical borrows. Of those, all but the last is for the sake of runtime efficiency, whereas HKT is just about genericity and expressiveness (neither of which Rust extremely prioritizes, at least not relative to languages like Haskell).


I haven't quite looked but is there a timeline for when compiler plugins will be stabilized? Interested in using serde but would prefer using macros


Not an exact timeline, but it's something that's being actively worked on. There's even an RFC: https://github.com/rust-lang/rfcs/pull/1566


Does Rust still abort on OOM? I won't use it by choice while it does that.


That's the standard library, not the language. You can use whatever semantic you want if you don't use the standard library, which is very easy to do.


And since most programs in any language will use that language's standard library (since that's the point of having a standard library), Rust systems in practice will not tolerate memory exhaustion. This property renders the whole system unacceptable to me.


There is already an ecosystem of packages for OS development even, and we statically know if you use the standard library or not. Many libraries that don't require it have an option to turn it off.

I understand your skepticism, but we care about this use case and are working to make it easy.


A few days ago I posted a comment with my problems with C. Can you use Rust as a better C/cross-platform-assembly?

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


Manual SIMD intrinsics is getting there, not sure how far it has come by now: https://github.com/rust-lang/rust/pull/27169 I'm sure LLVM does a fair bit of vectorization under the hood too of course, but not sure whether better knowledge of aliasing lets it do more or whether less undefined behavior sloppyness in Rust lets it do less of it than for C++.

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.


Thanks for the links! This info is kinda hard to find if you're not in the loop.

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


Finally I'll switch to Serde JSON :) I use beta and beta is 1.9 today, with awesome features stabilized!


Which feature in 1.9 relates to Serde?


Looks like I was wrong. Sorry.


BTW, does rust come with some kind of ide support tools, e.g. a commandline tool for autocomplete?


Not natively for now, but racer can do it : https://github.com/phildawes/racer/

IDE is a current goal : https://www.rust-lang.org/ides.html


Great news!! Yet is vagrant a real contributor? Or someone messed up his git user.name?


It's someone with a name 'vagrant' in their git info, yes. Not the company.


Anything big (bigger than usual) planned for 2.0?


After 1.9 1.10 will come. There is no plan for 2.0


Yup. There's even one cool feature we already know will be in 1.10: stable bootstrapping. You'll be able to build Rust 1.10 with Rust 1.9. And Rust 1.11 will build with 1.10. And so on and so on. This should help packagers significantly.


Is there a tracking issue for this?


No, just a PR: https://github.com/rust-lang/rust/pull/32731




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: