State of Rust 0.11.0

http://blog.octayn.net/blog/2014/07/15/state-of-rust-0.11.0/

by cmrx64 • 12 years ago

170 103 12 years ago

blog.octayn.net

broodbucket2• 12 years ago

If you want to check out Rust and are having trouble because the docs aren't close to done yet, Rust for Rubyists (rustforrubyists.com) just came out with an update supporting 0.11. If you're using the nightlies, the only thing in that book that isn't consistent (that I've found so far) is that the .to_str() method is now .to_string().

DAddYE• 12 years ago

I suggest also this: http://rustbyexample.com

It's an awesome resource and updated on a daily basis.

steveklabnik5• 12 years ago

Hopefully, my re-write of the guide will fully eclipse Rust for Rubyists soon. :)

broodbucket2• 12 years ago

I really appreciate you still updating Rust for Rubyists even though you're working on the official guide.

nobotty• 12 years ago

I'll be more interested when they've found a way to work with native binaries on windows, and handle creating/using binaries that take full advantage of the PE's import/export functionality. In reality it's not cross-platform if it doesn't support the almost guaranteed necessary features of the platform -- utilizing compiled dynamic libraries.

cmrx643• 12 years ago

Open an issue. There is really only one contributor who works on Windows support. We need more people telling us what we are doing wrong on Windows.

rdtsc2• 12 years ago

That is very exciting. I like the direction the project is going.

But, one thing worries me -- performance. Anyone know a list or tracker of benchmarks to see how it roughly compares.

Or is it too ealry too talk about it? Am I pointing to the elephant in the room? I am ok with saying "we are not there to talk about it, stop stirring the pot". I understand that.

But looking at the future, if Rust is to compete with C++, it needs to perform close to it. Not necessarily in the "safer"/default mode, but it needs to have an unsafe, turn-off-all-checks-run as fast as you can mode.

C++11/C++14 improved C++ many enjoy and like using it. Many that don't are probably using it for performance reasons. That is a niche Rust will have to compete in.

cmrx643• 12 years ago

Rust's performance is competitive with clang and improving, even in the "safer" mode. We have benchmarks in many of the libraries (search for #[bench]) and some in src/test/bench. We're on the benchmarking game, but that is really just a game, not indicative of anything besides how much time someone has spent microoptimizing a specific program. Someone is working on a custom LLVM pass that will remove essentially every null check that Rust adds. On top of that, there are still a few more changes on the way that aren't easy, but should give a nice perf improvement.

rdtsc2• 12 years ago

but that is really just a game,

Very much so, agreed. It is a PR game most of all. It is unfortunate. But it is probably a game that needs to be played. I know microbenchmarks are bogus, but I still click and look at them.

sanxiyn• 12 years ago

Here is a link to the source code of the initial version of the custom LLVM pass to eliminate null checks. Hopefully this will be upstreamed to LLVM in the future.

https://github.com/rust-lang/llvm/blob/rust-llvm-2014-06-28/...

semisight• 12 years ago

There technically is an "unsafe" mode, but not in the way you're thinking. You can drop down to C level by writing code in unsafe blocks and using methods prefixed with "unsafe." This will stop the compiler from doing things like inserting bounds checking and should perform fairly close to Clang.

Generally though, rust strives for the same ideal as C++: you only get what you pay for. You can carve out the subsection of the language you need through things like feature gating without too much trouble right now (and the standard library is still improving in this regard).

diaz• 12 years ago

Just a quick reply to link to this answer on reddit with the question:

Does 'unsafe' disable array bound checking? http://www.reddit.com/r/rust/comments/2aqqxa/does_unsafe_dis...

djur• 12 years ago

As I understand it, the goal is for Rust to perform as well or better than C++ without the need for an unsafe mode. From the long discussions I've seen on the Rust mailing list, I think the likelihood of a "disable all checks" mode is nil.

BlackMonday• 12 years ago

Yes, idiomatic C++ which uses the safety features that C++ has to offer, as far as I understand. Not the raw performance that C++ can give you. Just wanted to point that out.

Source: http://pcwalton.blogspot.de/2010/12/c-design-goals-in-contex...

dbaupp11• 12 years ago

Not necessarily in the "safer"/default mode, but it needs to have an unsafe, turn-off-all-checks-run as fast as you can mode.

By design, Rust allows you to opt-in to this mode locally via `unsafe { ... }`; this allows you to be 100% safe through the vast majority of the code base, but then eek out the very last drop of performance in core routines where there's no safe alternative. Then only those regions need to be checked for memory safety vulnerabilities rather than the whole codebase.

Although, many things can be written in safe code and still be performant: iterators provide safe and highly efficient sequential access to vectors and arrays (right now they optimise to the same code as the equivalent C/C++, other a bug in LLVM where it's not recognising that some pointers are guaranteed to be nonnull).

masklinn3• 12 years ago

By design, Rust allows you to opt-in to this mode locally via `unsafe { ... }`;

It should be noted that contrary to e.g. Swift's -Ofast, Rust's unsafe {} does not change language semantics. It allows operations marked as unsafe (non-bounds-checked array accesses, raw pointer and pointer munging, etc…) but operations usable outside unsafe {} have the exact same semantics inside.

valarauca1• 12 years ago

Currently Rust's perfmance is about that of Java's. Which is and isn't in contention with C++. Something's yes, some no. Rust beats C++ in a few areas on average (tree look ups for example) but that's about it.

It's not to early for it to be a concern. It should be a concern in system languages aiming to compete with lanagues like C/C++/Fortran. But I feel rust isn't in a terrible competition for being at least 15 years late to the party.

cmrx643• 12 years ago

Do you have specific benchmarks to back up this claim? I think it's completely unfounded. Every test we've done against C and C++, we're competitive. Exception is the performance of the IO/task runtime, which still needs work, but is unrelated to the language.

steveklabnik5• 12 years ago

it needs to have an unsafe, turn-off-all-checks-run as fast as you can mode

This will never happen, as it is contrary to the goals of the project. As mentioned by others, locally, you can ignore some checks, but there won't be a compiler flag to turn them off.

In some ways, it's too early to talk about it, and in some ways, it's not. It's not too early to talk about decisions which would place a certain upper bound on performance, but it's kinda too early to do some kinds of direct comparisons. The team has not really been working on performance generally, as the focus is to get the language semantics correctly. There's lots of places, for example, where rustc generates subpar LLVM IR, and it's a matter of someone writing a patch.

andrewchambers• 12 years ago

Well, Rust uses llvm, so unless rustc is generating really poor intermediate code, its performance will be the same as clang C/C++.

Jweb_Guru2• 12 years ago

That isn't quite true. Swift will be using LLVM as a code generator, but because it will use ARC (a form of garbage collection), it will still end up slower than C++ in many benchmarks. That's not the only example, of course--while LLVM helps immensely, it's not a miracle worker and the original language semantics do make a difference.

coldtea6• 12 years ago

But, one thing worries me -- performance. Anyone know a list or tracker of benchmarks to see how it roughly compares. Or is it too ealry too talk about it? Am I pointing to the elephant in the room?

I'd say it's too early.

First, Rust is a compiled, statically typed languaged using LLVM, including stuff such as non aliasing guarantess over C, and designed to be secure AND fast. It's not like it's some scripting language.

Second, you should benchmark your program first. Worrying about a language's "performance" in abstract is more premature than even Knuth anticipated.

nirvdrum2• 12 years ago

A fast language runtime helps all programs. If it's slow, there's precious little you can do about it. And the design of the language may end up such that certain aspects are just always going to be slow. So, I very much disagree with the notion that this a premature optimization (and I'm starting to think that phrase needs to just go away). You seem to allude to as much by delineating between compiled and scripting languages.

DCKing2• 12 years ago

It's the job of the compiler to optimize out things it knows are secure. If an array lookup is known to be secure at compile time, then LLVM already optimizes out bounds checking without the need of a fast mode [1].

If there is not enough evidence available to the compiler that a particular array lookup is not safe, then that evidence is also not available to the programmer. Therefore, one would have to write a manual bounds check anyway. Double bounds checking, one by the compiler and one by the compiler, can also be optimized out.

Maybe Rust is not capable of completely covering all optimization cases right now, but I don't think there's a need for a turn-off-all-checks mode.

Does anybody have any material about how a turn-off-all-checks-mode improved performance for another language? I'm curious about what the difference is.

[1] https://github.com/rust-lang/rust/issues/9024

gsg• 12 years ago

If there is not enough evidence available to the compiler that a particular array lookup is not safe, then that evidence is also not available to the programmer.

That's quite wrong. Humans are capable of deductions that compilers, which must necessarily use conservative, constructive methods, can't dream of. They can also have information that isn't available to a compiler even in principle, although this is less likely to apply to eliminating bounds checking.

jbooth2• 12 years ago

Is there a capability or plans to be able to export a header file from Rust code that C code (or Python, Go, whatever) could reference? I couldn't find anything when searching for it but it seems that it'd be possible since Rust doesn't have a runtime, right?

dbaupp11• 12 years ago

Yes, you can expose C symbols from a Rust library:

  #[no_mangle]
  pub extern fn rustlib_increment(x: i32) -> i32 { x + 1 }

#10350 covers actually printing a .h file from Rust code. https://github.com/rust-lang/rust/issues/10530

jbooth2• 12 years ago

Awesome. I think the ability to write a nice .h file, in particular, will really be the killer feature for Rust as "better systems language". Exporting headers and symbols for higher level languages in a format that's universally understood.

masklinn3• 12 years ago

Rust doesn't have a runtime, right?

Rust does have a runtime (used for tasks and GC'd types amongst others), the runtime can be disabled and the standard library is being split between "requires runtime" and "does not require runtime" (with as much as possible being moved to the latter).

It's incorrect to say that Rust does not have a runtime, but it's correct to say that runtime-less Rust is very much a first-class concern for the project.

PS: note that C does have a runtime as well, if a very minimal one.

jblow2• 12 years ago

I want a language I would enjoy programming in. Rust seems to have a lot of what I want (GC not mandatory, perf, etc, etc) BUT private-by-default is a terrible idea. I started writing a Rust program and I was just typing pub pub pub all over the place. Ugly. That plus the excessive markup the language requires for safety are enough to put me off it.

Video game programmers desperately need a new language to replace C++, but I think this is not it, because the amount of friction added for safety reasons feels very high.

I'll keep an eye on the language as it evolves, though.

kasey_junk4• 12 years ago

I think your response is on point because Rust also seems to be a lot of what I want (GC not mandatory, perf, etc, etc, plus pattern matching). Private by default is literally a huge positive for me. But the terribleness of Rust strings is enough to put me right off of it.

I'm worried that all of us are waiting for something to replace C++ that can't happen.

dbaupp11• 12 years ago

When you say "terrible", are you complaining about having to write `.as_slice()` and `.to_string()` all the time?

For context for others who may not have a lot of Rust experience, Rust has two string types, the heap allocated `String` and the 'string slice' `&str`, which is a view of some string data anywhere in memory (possibly on the heap, possibly not). A little more info about these types: http://stackoverflow.com/a/24159933/1256624

At the moment, conversions between them are via explicit method calls, which can result in verbose code when handling them. An explicit conversion is required even for the super-cheap `String` -> `&str` conversion (which is just repackaging the 3 words (length, capacity, pointer) of String into the 2 words (length, pointer) of the &str).

coldtea6• 12 years ago

What "terribleness"?

kibwen3• 12 years ago

Given your conclusion there, in what ways do you wish Rust strings were similar to C++ strings?

pjmlp7• 12 years ago

I'm worried that all of us are waiting for something to replace C++ that can't happen.

From the early days of computing, history proves systems programming languages only get replaced when OS vendors push another language on their official tooling.

Apple is now pushing Swift and Microsoft, at very least, dumping C.

So will Mozilla push Rust as part of Firefox OS? If not, which OS vendor will pick it up?

Note this applies also to other "wannabe C++" replacements.

megrimlock3• 12 years ago

The history of gamedev (in particular) eschewing C++ for years until the consensus flipped gives me hope that something similar might happen here. The strings thing may take a similar path to so many aspects of C++ -- where it took years of folks like Scott Meyers and Josuttis and Herb Sutter and Alexandrescu talking through the details and rationale before enough people grew to like the decisions C++ made. Think of how many C++ programmers had to get their head around (say) RAII -- it probably first seemed horribly odd and weird, and now it's seen as a fundamental reason why it's a great language.

kibwen3• 12 years ago

The intent of private-by-default is to better control the API that a compilation unit presents. Rust allows you to inline functions across compilation units, which is incredible for optimization but inflates binaries with AST metadata (and as a result, inflates compilation times) if you attempt to make public every function under the sun. Rust also intends to have an ironclad versioning story, which means that API breakage will be taken tremendously seriously. With public-by-default, it's far too easy to accidentally break your API by modifying something that was not intended to be exposed in the first place. It's the antithesis of reliable software.

You're of course welcome to think that private-by-default is a terrible idea, but let's be aware that features are not adopted without reason. Programming language discourse (in general, not just related to Rust) is all too often dominated by people who seem to think that particular combinations of features are chosen at random out of a hat.

alextgordon• 12 years ago

IMO the problem is not private-by-default but small modules and the confusion of scope with packages. (I should say that my Rust experience is non-existent so correct me if my intuition on its semantics is wrong).

It's reasonable that individual Rust files have their own scope. But it is a nonsense to imbue a namespace with an API or versioning story. Programmers do not think that way.

What has an API? A package. Something big enough that you can submit it to a package manager.

Therefore, private symbols in a package should be public to that package. That doesn't mean they should be in scope, but they should be available to be imported by other files in the package.

Public/private would then only be relevant at the boundary between packages.

There's a good reason to do this: it encourages modular design. A small-module language like Python uses modules so much that they miss the opportunity to take on a life of its own.

For instance, Django is split into hundreds of tiny "modules". But no one of them is big enough to be meaningful without the others. There is no singular "Django templates" module, nor a "Django ORM" module. In that sense it is monolithic via over-modularization.

dbaupp11• 12 years ago

Yeah, other game developers have requested that the safety guarantees be relaxed, because they don't particularly need it and relaxing them would allow for "nicer" code.

This probably just means that Rust isn't appropriate for that domain at the moment. The focus is strongly on memory safety, as that's what security-critical applications need: compromising this may weaken the ability for Rust to overcome C++'s inertia in the space of web browsers and operating systems (etc.), because zero-overhead memory safety enforced by the compiler (not just by convention) is the big draw-card.

Maybe in a world of web-connected multiplayer games handling logins and payments, security will become more attractive; or maybe the fewer memory corruption (etc.) bugs will eventually win the gamedev community over. (I know some gamedevs have been surprised that they have somehow managed to have very few bugs in their Rust code: http://www.reddit.com/r/rust/comments/28mlba/what_is_your_bu... )

uwe_dushan• 12 years ago

I've been watching Rust for a while from the game development perspective and as much as I want it to be, I don't think it's a great fit for that domain. Still rooting for Rust because we really have a lot of work on the security front but I've been having a great deal of fun programming in Nimrod (http://nimrod-lang.org/). It's a bit of a one man show but there's a lot to like.

tete2• 12 years ago

I really like both of them too. I really like Nimrod. The smaller community and (at least when I last checked) bad documentation especially for async stuff made me worry a bit.

However we should remember both languages are basically pre-release. They are not finished. That will take a while. After that it can take a while for a nice eco system and a common coding style to emerge. Not in the sense of hard rules, but when a community emerges around a language it's a bit like they develop a common accent and vocabulary. From that on other stuff develops, thickening the eco system fixing bugs, developing stable libraries. All of these things take and a lot of it is done by the first people getting into the language, even before it is released.

However I think it will still take a while of people trying to do something completely new with both languages to find and get rid of rough edges, while learning to use the language.

Look at Go for example. They enforce thing with fmt, etc. and it has been in use for a while now, but despite being used in production by many companies the ecosystem is still developing rapidly, there are still known problems to be fixed in future releases, there are still completely new things done with Go, the community didn't really "settle" (of course never happens completely, else there would be stagnation) about certain things, there is (IMO) still no really good IDE, there is still a lot to be made and most importantly there are no "Gurus" yet. Okay, maybe you wouldn't call them gurus, but there is still a hype phase. And if you look back to slightly older languages. Node.js still has a lot of those problems too, but the hype is slowly going away (other than on fronts, like Meteor, etc.), making many things way more rational. This means certain people move away from it, but others are just starting to actually consider it, because things are in place.

You can also look way back. C and C++ have a huge eco system, Perl has a module system where each library you make publicly available on CPAN is tested across a lot of versions, against tons of platforms. Well, you might think about the language in one way or the other, but that are the kind of projects that you really want if you think about using a language in production/enterprise.

In the startup world things are a bit different, cause you often are okay to take certain risks in exchange for development speed for example. Of course that really depends on what you are doing, but I guess it is hard to deny that a lot of (successful and not so successful) startups base upon very new, cutting or even bleeding edge technologies, while older or enterprise companies tend to be way more conservative about that.

tete2• 12 years ago

I hope that doesn't sound bad, but the defaults in Rust are a really good thing in my opinion, cause it kinda pushes you into having better programming styles. In theory this could be done by a lot of experience self discipline, but in reality that can be hard hard to get, especially in a team.

pcwalton2• 12 years ago

I think the problem is not private-by-default, but the repetition of "pub". We tried public-by-default and it led to a situation where it was very hard to make a stable API for your modules (which we need to avoid breakage of existing code). It could be solved with a "pub { ... }" block (which I'm pretty sure you could write today with a macro if you wanted to). Personally, I prefer repetition of "pub", as it forces me to think about what API I want to present to consumers of my library, but I can see how it can be annoying, especially if your modules are purely for internal use and you aren't concerned about API stability as much.

Regarding safety annotations, there is a WIP effort to eliminate 80%-90% of the lifetime annotations used in practice. There are also a couple of proposals to change the syntax of lifetime annotations to be less noisy.

jblow2• 12 years ago

I certainly welcome the attempts to reduce annotations and will look again at the language in a while.

It is interesting that the design priorities are so library-centric. I agree that library quality is important, but think about this: For every library that someone writes, N people are going to use that library in leaf programs, where if the library is useful N is much much greater than 1. So by definition the vast majority of code is not library code.

In video games we write programs that are between 200k and 2M lines, say. That is big enough that you do want to think about what API you are presenting from part of that program to another, but stability of that (internal) API is almost never a concern, and in fact this is one of the big boons of statically-typed languages: you can change a function and you instantly get errors at all the calling sites, allowing you to be sure you updated them (except in some bad ambiguous situations).

This fluid ability to change how parts of your program talk to each other is very important in large programs. It is one of the major ways you avoid code rot. The more friction is introduced into this process, the lower the ceiling on how large and complex a program you can build.

The other thing about games is that the problems are inherently very interconnected. Yes, we kind of partition things into different modules, but these modules all want to talk to each other very heavily (partly for inherent problem space reasons, partly for performance reasons). So again, friction introduced here hurts us more than it hurts most people.

I understand that private-by-default seems like the right idea because it supports a certain paradigm of programming that is generally considered the right thing (encapsulate your implementation details, modularize as much as possible, etc). But what I have found, in my field at least, is that this is less true than many people think. Yes, it's important to keep things clean, but fluid ability to change code is very important, and overmodularization hurts this. I think that some day this will become more widely understood, the same way that today most good programmers understand that OOP is not some kind of One True Panacea the way folks in the 90s seemed to think.

Good ideas can be carried too far and I think for my field private-by-default is way too far. Having to put 'pub' on every member of every struct and on well more than half my functions is kind of bananas.

(As someone who does not buy into the paradigm of OOP, I want to write functions that operate on data. In C++ sometimes I encapsulate these functions as struct members but this is just an aid to understanding when it is convenient; most functions are declared at file scope. In order to have a functions-operating-on-data mentality in Rust, I guess I need to put a pub in front of every member of every struct, which feels very distasteful; it feels like the language is pushing me toward paradigms that many in my field have tried and subsequently rejected after decades of pain.)

Well, this certainly went a few places, but that is where I am on these issues.

scott_s• 12 years ago

I think this has more to do with your own personal style of programming, rather than the domain you program in.

tempodox• 12 years ago

This is welcome news.

Also, I wasn't sure that Vec<T> was actually ~[T], I couldn't find that in the docs. Thanks for spelling it out.

I see Rust as a language that could become the “next C” (only better), and I'm excited watching it evolve.

sriku3• 12 years ago

Newbie taking a serious look at Rust here.

Any notes about non-blocking I/O in rust? Iron [1] is mentioned, but am not sure how I/O is handled in Iron yet .. or how it would be written to be non-blocking [2]. I hear "read the source luke" echoing in the chambers of HN and will do that, but some higher level info would be nice.

[1] http://ironframework.io/

[2] http://www.reddit.com/r/rust/comments/1v2ptr/is_nonblocking_...

edit: This (http://doc.rust-lang.org/native/io/) seems to suggest that the norm is non-blocking I/O which is automatically handled by the scheduler.

ben0x539• 12 years ago

If you explicitly use the "green" runtime that ships with rust instead of the "native" runtime, you get green threads where the built-in blocking IO only blocks the green thread but lets the OS-level thread carry on executing other green threads.

Internally that is built on top of libuv for async IO, but as far as I know, Rust currently doesn't expose any interface for manually doing async or nonblocking IO.

sriku3• 12 years ago

Thanks for this clarification.

sriku3• 12 years ago

It seems this issue was only recently closed (May 9) [1] .. and it seems a websocket library with full duplex support is still in the works.

[1] https://github.com/rust-lang/rust/issues/11165

State of Rust 0.11.0

Related Stories