
State of Rust 0.11.0 - cmrx64
http://blog.octayn.net/blog/2014/07/15/state-of-rust-0.11.0/
======
rdtsc
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.

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

~~~
sanxiyn
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/...](https://github.com/rust-lang/llvm/blob/rust-
llvm-2014-06-28/lib/Transforms/Scalar/NullCheckElimination.cpp)

~~~
legulere
There's a small typo in there: argumetns -> arguments

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

~~~
dbaupp
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](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).

~~~
kasey_junk
That is part of the problem. The bigger part of the problem is comparing
String's with constants. It simply doesn't work easily.

Also, start trying to do pattern matching on Vec<String> vs Vec<str> (and the
wide variety of static, ref, etc versions there in) and you end up spending a
lot of effort to do what is very basic in most languages that support generic
pattern matching.

Try a simple use case, parse a command line argument array via pattern
matching in a Rust program.

~~~
dbaupp
Comparing a constant:

    
    
      string.as_slice() == "foo"
    

"Parsing" command line args (it's not as slick as it could be, but it's not
entirely horrible... for me as an experienced Rust user anyway):

    
    
      match std::os::args().as_slice() {
          [] => println!("need more arguments"),
          [ref x, ..] if x.as_slice() == "-h" => print_help(),
          [ref a, ref b] if a.as_slice() == "-f" => write_to_file(b.as_slice())
          args @ _ => println!("unrecognised arguments: {}", args)
      }
    

Of course, using a proper parser like getopts or docopt.rs would be better:

\- [http://doc.rust-lang.org/master/getopts/](http://doc.rust-
lang.org/master/getopts/) \-
[https://github.com/BurntSushi/docopt.rs](https://github.com/BurntSushi/docopt.rs)

I think it gets smoother with practice (as in, with practice you're able to
know intuitively when you need .as_slice and when a `ref` is required etc.),
but yes, improving the ergonomics will be nice. Dynamically sized types will
allow for String to be treated implicitly as a &str in many cases, so, e.g.,
my_string.trim() will work (it currently requires
`my_string.as_slice().trim()`). And there is some loose talk about overloading
pattern matching via the same mechanism, which would allow proper pattern
matching on String with literals `"..."`.

 _> support generic pattern matching._

There's some subtlety here, e.g. Haskell doesn't support pattern matching on
Data.Vector.Vector or Data.Text.Text (which are some of the closest
equivalents to &[T], Vec<T> and String).

~~~
kasey_junk
A) I understand how to make Rust do what I want with strings. B) Even with
your examples, I think you've glossed over some of the even trivial use cases
for dealing with Vec<String> vs Vec<~str> (or whatever the current
nomenclature is). C) Even with your great comments you've pointed out that
String manipulation in Rust is not "natural". Which is something that is a
very high priority for me.

That said, easy string manipulation is a high priority feature for me. Non-
private data access is a high priority feature for the original commenter. I
worry that too many of us have expectations for Rust that are unlikely to be
fulfilled.

That's not to say that the Rust team has set too high of barriers, only that
we have elevated them to something they aren't. I'm less concerned with what
the Rust team is delivering (which so far has been great) than with what
people seem to be expecting (which is nothing less than a C++ replacement in
all contexts).

~~~
kzrdude
The problem is that the string story is on two sides of a barrier erected in
Rust very much by intention: _To make memory allocation explicit, and to
enable allocation-free operations as far as possible_

This is why Rust will have you juggle String (a string with allocation) and
&str (a "string slice"; a view into an allocation elsewhere) all the time.

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

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

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

~~~
steveklabnik
You're welcome. <3.

0.11 was the first edition I _completely_ re-read all the text and fixed
things, and I still had something like ~10 errors. Editing your own writing is
hard.

------
sriku
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/](http://ironframework.io/)

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

edit: This ([http://doc.rust-lang.org/native/io/](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
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.

~~~
sriku
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](https://github.com/rust-
lang/rust/issues/11165)

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

------
jbooth
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?

~~~
dbaupp
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](https://github.com/rust-
lang/rust/issues/10530)

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

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

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

