"I think that Mozilla's Rust is aiming squarely at C++ developers, whereas Go is more of a Java replacement."

I basically agree with this as a Rust developer (although I'm not sure about Go being in Java's niche; I think of it more as in node.js's niche -- highly scalable web apps). Early on, I think both Rust and Go were thought to be targeting the same segment, but it turned out that we really weren't. Personally, I'm completely fine with that; different language designs are appropriate for different roles. The huge amount of work that we've done to make non-allocating and manually-memory-managed code easy, predictable, and type-safe is totally overkill for Go's niche, for example, while for games and web browsers this sort of thing is essential.

The funny thing is Go and Rust compete with C++, but in different niches. C++ manages to cover a lot of ground from high-level to low-level programming.

With C++11 it now has a foot in the concurrency niche. The question is, whether C++ can keep its niches or if lots of different languages will chew away its market share on various levels.

As someone who's tried (and failed) to learn Rust in the past:

I'm going to elide any commentary about the syntax for now, as I know why it is the way it is (the type system/annotations). I'm basically just going to expound on one thing for the sake of emphasis.

For the love of god make Rust more accessible. I don't mean dumbing down the type system or abandoning regions (I really hope that works out). I mean the frickin' documentation. Digging through the core libs to figure out how to dp fairly common case stuff is obscene.

Part of the reason I like to tinker with Go in my spare time is that it's extremely hygienic, clean, cheap, and cheerful.

Look at the way the "go" binary works, it does everything. It does builds, automatic formatting of code, the works. And it just "works".

On top of that, I'd consider getting somebody more knowledgeable about Rust and get them to team up / pair-document with somebody who is a goddamn dumbass like me and start building tutorials/documentation together.

I can't imagine the language's syntax and features are so nascent that tutorials and docs for core functionality/libs would be out of the question, you're already prototyping that web browser engine.

Documentation is a UX problem, like syntax. Syntax alone crippled Erlang, please don't let obscurity harm a language I am very excited about.

If there's any way I can help (maybe a trail of bread crumbs/notes from me as I try to learn it?), let me know in this thread or via email.

Yes, the docs are awful at the moment. It's mostly a question of making sure things are stable before we commit to writing a lot of docs; we absolutely need better ones. The standard library tends to use the bleeding-edge features more than user Rust code (as it contains implementations of core traits and whatnot), so its churn is high. Despite what others have suggested, I don't think it needs a total rewrite, but various names should change.

A "go"-like binary is on the roadmap; it's mostly a question of refactoring. We have a pretty printer, a doc generator, a package manager, and a compiler (all in various stages of completeness); the trick is to just bundle them into one nice package.

A trail of notes would definitely be helpful, to see what the initial hurdles are for beginners.

From what I've seen the biggest problem is that 0.3's syntax is totally different from the unreleased 0.4 (due to be released next week). Most people, understandably, build from the packaged 0.3 and none of the examples in the documentation work. 0.4 contains the syntax we're committing to; most of the changes from then on should be backwards-compatible with it (unless you use the deprecated stuff, which we're adding warnings for).

(due to be released next week).

I will be eagerly looking forward to that!! Is the 0.4 version a step ahead of the past alphas? Is it finally becomming a beta?

My mistake, it's actually 2 weeks ("mid-September" is the target date). Still close. It's still an alpha, but there are huge changes, and most importantly, syntax becomes "slushy" after 0.4 (not frozen, but massive changes have a high bar to clear).

(Disclaimer: occasional Rust contributor)

I agree, Rust's documentation is really awful at the moment. I mean, there's a reason for it: the syntax and semantics are evolving so fast that any tutorial written right now will be hopelessly out of date in two weeks (note that the official tutorial has been updated regularly, but you can't even tell!), and much of the current stdlib is comprised of quick hacks based on obsolete language features and may very well get near-entirely rewritten before 1.0. Of course, that's no consolation for people who don't consistently lurk in the dev channels.

There's some hope, though. The next release (0.4, due in perhaps a month) has been tentatively designated as the "syntax freeze" release, so at the very least things should cool down after that point (fingers crossed). But until then, I wouldn't advise newcomers to get anywhere near Rust, for fear of the constant breaking changes that are leading up to the syntax freeze.

I would be happy to maintain a newbie's guide, syntax changes and all (I've read the meeting notes, I know what you're talking about) if somebody can help me learn enough Rust to know what I'm talking about.

Edit: Fuck it, I'll make a website.

If you do, please post it to the mailing list!

https://mail.mozilla.org/listinfo/rust-dev

Sub waiting for mod approval.

Rust is still a nebula.... I expect a beginner freindly tutorial after some more stability in syntax. Now, pc will have a better answer for the availabilty beginner's tutorial... Good Documentation and Tutorial is factually a must.... Having said that, I am enjoying Rust, and I will have it as my primary production language for real software in future.(By next year, as Greydon say, when it is a bit more stable. Till then its just acedemic coding)

And Patrick(reminding), People are asking for a good beginer's tutorial...

+1. I recently tried to get a little bit of file I/O going and it was a PITA.

I'm very interested to know more about your use of racket in production. Could you share your experience?

Well, 'production' may be too grand a term. My programs are usually on the order of a few hundred lines or less.

I'm a geneticist whose (work) code is centered around data processing. I previously used Perl for just about everything (although I've used Python & Ruby also), but started to broaden my programming horizons recently, and after a grand tour of what was on offer I settled on Racket as my language of choice for the more complex end of the scripts I was writing. I'm finding it easier to maintain (and especially refactor) complex scripts in Racket than I did in Perl (or Python or Ruby), and the increase in performance is substantial when processing huge data-sets. One current weakness of Racket here is the relative lack of specific libraries for bioinformatics, but most of my code doesn't need any anyway and when it does I revert to Perl.

I'm also excited about investigating other areas of the language, especially Typed Racket, as static typing is something I haven't really utilized so far.

In general, the more I learn about Racket the more I admire the quality of design that has gone into it; everything seems to be extremely well thought out, not just from a theoretical perspective, but from a practical one too.

>Furthermore, although Python is a pretty good all-round language, it doesn't really excel at anything in particular, unlike for example Perl which continues to maintain a strong niche in the areas of text processing and system administration, despite its popularity having fallen away in some of the other areas it was formerly strong in.

Well, it does excel in scientific computing. Biologists, astronomers and such use it a lot, and it has lots of advanced math/stats/physics etc libs, with fast C implementations underneath.

Run Python under strace sometime. Laugh as it attempts to open thousands of non-existent files just to start up. Cry when you imagine that happening on a thousand-node scientific computing cluster with an NFS root. IIRC we saw something on the order of 10-20 minutes to get Python started on every node of a Blue Gene allocation.

Ditto for Perl because of BioPerl (used in the Human Genome Project) & PDL (which IIRC was being used somewhere at NASA).

links: http://en.wikipedia.org/wiki/BioPerl | http://pdl.perl.org/

I believe Perl in bioinformatics was a combination of three or four factors. At that time, sequence analysis was mostly equivalent to string processing and executing command-line programs. Perl was a natural fit. Bioinformatics work used Suns running Sybase, so the researchers knew the Unix way of doing things, which is what perl builds on. This was the early days of the web, and bioinformatics people were very much into data sharing. They used perl to write CGI programs (both cgi-lib.pl and CGI.pm were written by bioinformatics people), so they had one language which they could use for sequence research, for system administration, and for data sharing.

Other languages evolved through a different path. Chemistry, for example, tends to be more Python related. (I develop software for that field.) I think it's because the chemical graph data structure is harder to write naturally in Perl. Gene expression analysis uses a lot of R.