Performance of sequential Rust programs | Hacker News Reader

Performance of sequential Rust programs

pcwalton.github.io

66 pointsasb26 comments

I think this speaks to conscientious language design combined with the use of LLVM as a backend.

Pretty excited about Rust, it's the best (virtually) no-compromise developing option for systems work.

Curious to see where it starts to actually bite people as popular use grows. I really wish they'd put more effort into community/outreach though.

/r/rust is great. Mozilla/#rust is great. I think a bit of it simply has to do with Rust's immaturity. For example, there are no real http libs client or server to speak of because the scheduler rewrite is blocking. Oh well, I get the impression that stuff is all simply a matter of time.

Pcwalton's blog is great if you're interested in more rust stuff.

I've spent some time in their IRC channel and tried to use the language at a few points. They're nice people but not really interested in helping anybody use the language that isn't an intern working on it. Or at least, that was the case at the time I was on Mozilla's IRC server.

The language isn't positioned for wider use the way Go was when it was first announced.

That's because we announced the language earlier in its lifecycle than did Go, relatively speaking. (Graydon had initial designs for quite some time before development really started, which is why you sometimes hear that the language is older, but development didn't really start until 2009-2010.)

We're definitely interested in helping people learn to use the language. Hence the tutorial, Niko's, Brian's, and my blog posts, and so on.

Of course, the manual and learning material are in dire need of improvement in many areas; please bear with us, as it's a work in progress.

I've tried learning Rust twice. Once when 0.4 was announced, and then again a few days ago because of 0.6. Both times I read the entire tutorial and manual, and poked around the standard libraries. But both times I ran in to the same problems. Both the tutorial and manual contradict each other in places, and contradict themselves in places too (e.g. I saw both &'r foo and &r/foo syntaxes in the 0.6 manual). The manual is also full of broken links (every time it referenced another section of the manual, the link didn't actually do anything). And the tutorial doesn't actually have anything for you to do as you work along it, it's basically just a rephrased manual with a bunch of tiny code snippets. The library documentation is formatted really poorly and makes it hard to figure out how you're supposed to do something. And just in general, there's no good examples of how to actually write idiomatic Rust code, or how to write a full program.

I recognize that it's a work in progress, which does excuse a lot, but these problems do act as a significant barrier to actually using the language. I'd love to actually start writing Rust programs, but when I look at it, it just feels like I'd be better off waiting until the next release and hoping it's better. Which is a real shame, because a lot of what you're trying to do with the language really appeals to me.

Contrast this with the state of the Go documentation / learning material when it was announced. I was able to dive right in to that language, figure out how to write idiomatic code in it, and produce programs.

I guess what I'm trying to say is, I wish you guys would start putting more effort into the documentation side of things.

As Patrick said, Go was announced much later in the development lifecycle. Go was developed for quite a while before it was announced. At Mozilla, we do things a little differently. All of our projects are open and public from the very first commit into the repo.

People seem very excited about Rust and want to use it right away, which is great, but things have been changing a lot, as you noticed, and will continue to do so for a while. One of the reasons things are changing is because the Rust developers take into account the opinions of random early adopters of the language. There is no idiomatic way to write Rust yet because Mozilla wants the Rust community to help figure out what idiomatic code should look like. Go, on the other hand, has lots of opinions.

There are obviously tradeoffs to each approach, and one downside of the Mozilla approach is a lot of churn and chaos sometimes. However there are a lot of benefits too, one important benefit being that the community is helping to shape the language in an open way.

I have no problem with the community helping to shape the language. But I think the difficulty in getting started with the language, due primarily to documentation problems and lack of good introductory material, is going to make it harder for people to get involved.

I know when Go was first released I immediately jumped in and started using the language. I was even the first non-google, non-@golang person to get their name in the CONTRIBUTORS list (because I wanted to modify the emacs go-mode, but still). But I feel like I can't even get started with Rust because I have no idea what I'm doing and the documentation isn't helping.

For example, right now I'm trying to whip up a really tiny program to test out the FFI. But the libc module's documentation is completely nonexistent. It's just a series of nested modules, which end up having nothing in them. I'm sure there's actually stuff in the modules, otherwise they wouldn't exist, but the documentation claims that they're empty. So I have no idea what I'm doing.

The problem with libc is twofold: first, reexports don't show up in the docs (bug on file [1]), and secondly, that every module gets a separate page (filed as [2]). You can actually see the signatures for functions if you click through enough, e.g.

http://static.rust-lang.org/doc/0.6/core/libc_funcs_posix01_...

Having to click through is annoying, though. It would be better to be able to specify that a module and all its submodules should go on one page in the docs.

Thanks for the bug report!

[1]: https://github.com/mozilla/rust/issues/3537

[2]: https://github.com/mozilla/rust/issues/5952

Makes sense. Would fix the problem where I have no idea what prelude pulls in too.

Also, part of my confusion with libc is that not all of the leaf modules actually have something in them. The first few I looked at were completely empty, so I thought the entirety of the libc documentation was empty.

As a stop gap measure, you can grep the source of the libc module[1], extremely non-optimal though.

[1]: https://github.com/mozilla/rust/blob/incoming/src/libcore/li...

Oh, also, if you see incorrect syntax or broken links in the manual, file bugs!

Okay? But when is somebody going to fix the documentation and keep it in sync with the language's development?

I've never once had a problem with Go's documentation and it started out as a relatively casual project that is more peripheral to Google's interests than Servo is to Mozilla's.

Making a language be able to get picked up by the wider programming community means somebody has to spend time on things other than the compiler. Lots of time.

I don't disagree. The documentation needs work.

That said, the compiler needs a lot of work as well, as those who have used the language for any amount of time can attest to. Everyone sees the dreaded "internal compiler error" message. Everyone encounters borrow check and code generation bugs. Everyone misses a working package management system and pretty printer. Everyone bemoans the slowness of compilation for small programs. These are things you just didn't see for Go when it was announced--because it was Google-internal then.

We intend to fix the documentation before calling it 1.0. But compilers are complex, especially for a language with a rich type system and a nontrivial static analysis built in (the borrow check). There are many things to do, from documentation to bug fixing to feature work (macros and default methods are unfinished) to tooling work.

Note, however, that the code examples in the documentation are kept up to date and enforced via the test suite. So there may be inaccuracies in the prose, but we do perform automated quality control as best we can.

Good to know. The package management is going to be particular interest to me.

I specifically will be devoting lots of time to Rust's documentation, but I've been waiting for the syntax changes to settle down. 0.6 fixed a lot of that.

They're nice people but not really interested in helping anybody use the language that isn't an intern working on it.

I definitely haven't had that experience. They have limited hours in the day, but they try their hardest to be of assistance.

I would agree with the last line, but I don't think that's a bad thing and I think the language can still be used plenty widely.

As for IRC, I was in the other day asking about trait usage - static vs dynamic. I got the 10-year-PL-designer explanation and had the ELI20 explanation from a few other people. I walked away with a rough understanding and working code. That's what I'm looking for in IRC. Quite pleased!

>Or at least, that was the case at the time I was on Mozilla's IRC server.

That. It can vary with time, mood etc. It's not like there are that many people hanging around at the channel yet, or using the language in general. Heck, it's not even beta or frozen yet!

The mailing list I found to be quite friendly.

I've received a _ton_ of help from the IRC channel, you might have caught it at a bad time.

As I just wrote on his blog, based on the GCC version he cites, it's not really GCC, it's LLVM with a GCC frontend.

(plus, if it was really 4.2, it'd be a 5+ year old version)

Not to mention, LLVM 2.9 is pretty old as well.

Plus, you know, without explaining what options were used, it's impossible to tell anything about anything.

It's really GCC 4.2, not LLVM. I used -O2 for GCC and clang and -O (which runs LLVM in -O2 mode) for Rust. Updated the post to mention the options.

Edit: Added clang 3.1, trunk 149587. Over 2.9 it has some improvements, some regressions.

Great, thanks!

Does Rust have any kind of GUI stuff yet? Last time I looked it was just Cocoa wrappers.

Are you talking about a high level toolkit? Wrappers around the native platform API is the starting point for any GUI toolkit.

Something a bit more cross platform like wxWidgets or GTK (well sorta)

Please stop using OS X as a benchmarking platform. It lacks an official package manager and you'll end up using very old software (GCC 4.2 is from 2007-2008) because it's hard to install recent versions.

Reply on news.ycombinator.com