
Announcing Rust 1.2 - steveklabnik
http://blog.rust-lang.org/2015/08/06/Rust-1.2.html
======
ThePhysicist
I am currently evaluating Rust for a project where speed is important (I am
working with graph data in the context of code analysis). Although I find Rust
very appealing I still see C++ as the better option, mostly because I fear
that Rust would lack good suppport libraries (e.g. for talking to DBs,
generating/parsing data formats such as JSON or for generating cryprographic
hashes) and that I would end up implementing many of those myself. As of
today, many Rust wrapper libraries (e.g. for BerkeleyDB) seem to be written by
a single author, which makes me wonder about their stability and maturity even
more.

I wonder if this is an irrational fear though. Has anyone here implemented a
large project with many external dependencies (DB, data serialization,
interfacing with other programming languages etc.) in Rust? If so, what were
your learnings and would you do it again?

I find that the discussion about whether a programming language is "good" or
not always focuses on the core features of that language and less on the
actual system of support libraries that are available for it and that make it
actually useful in a real-world setting.

~~~
weinzierl

        Although I find Rust very appealing I still see C++ as the better option, mostly 
        because I fear that Rust would lack good suppport libraries (e.g. for talking to 
        DBs, generating/parsing data formats such as JSON or for generating cryprographic 
        hashes) and that I would end up implementing many of those myself. As of today, 
        many Rust wrapper libraries (e.g. for BerkeleyDB) seem to be written by a single 
        author, which makes me wonder about their stability and maturity even more.
    

Rust is in its very beginning[1]. Only time can tell if it will have a rich
set of support libraries that are stable and mature.It has one big advantage
over C and C++ in this regard.

 _It has a central repository for all the support libraries._

I always found it difficult to assess the stability and maturity of libraries
for C or C++ found on the internet. Of course there are the standards, like
libpng or zlib, and you know they must be good because so many projects use
them. For more exotic tasks you are on your own. With a central repository,
you can at least estimate the popularity of a certain library. crates.io shows
a download count for example. Also many other popular languages have one

    
    
       Java     Maven
       Perl     CPAN
       TeX      CTAN
       PHP      PECL, PEAR
       Python   PyPI 
       Ruby     RubyGems 
       R        CRAN 
       Node.js  npm 
       Lua      LuaRocks 
       Haskell  Hackage
    

[1] I know that Graydon started it over 5 years ago, but from user standpoint
Rust is more a child of 2015.

[2] [https://crates.io/](https://crates.io/)

~~~
dman
Package managers have their own problems. Unless they are curated well they
lead to many libraries that all claim to do the same thing. I wont name any
specific examples, but using some of the above takes a fair amount of
judgement in how rock solid the package is.

~~~
weinzierl
I, for my part, think I'm still better off with a central repository with
problems than without one.

For Java there are commercial curated Maven repositories and I'm not aware of
anything like that for C/C++. So Cargo can be an enabler for Rust in big corp.

~~~
andrewchambers
I think a better design would be a p2p system with crates.io being a tracker
and official seeder.

~~~
threeseed
It's a nice approach in theory. Not so great in practice.

Whether we like it or not most developers are hired by a company. And for most
medium to large companies there is no way they are going to let a P2P system
go through their firewall.

Many don't even allow developers to access official repositories which is why
products like Nexus (repository proxy) exist.

~~~
andrewchambers
The standard clients don't need to seed by default. Provided there are
organizations willing to seed, they could share the costs between themselves.

------
kibwen
1.2 is great (the nascent MSVC support is especially promising), but I'm most
excited by the ongoing work in nightly to completely overhaul the compiler
middle-end. The high-level overview is that the middle-end is being refactored
to operate on its own intermediate representation instead of the raw AST,
which should open the door to a whole host of improvements in compiler speed
and code generation. It's technical debt whose bill is long overdue. :)

~~~
ewillbefull
Will the MIR/HIR stuff also help with adding features? I'm thinking of things
like non-lexical scoping/SEME regions/etc. which might be easier to implement
with it.

~~~
dbaupp
Yep, the MIR allows the compiler to understand control flow more accurately
and more precisely. Non-lexical lifetimes in particular are one of the big
features that the MIR should help enable.

------
Animats
Well, as I usually do when a new Rust comes out, I tried recompiling some
programs that used to work. So far, not so good:

    
    
        > cargo clean; cargo update; cargo build;
        Updating registry `https://github.com/rust-lang/crates.io-index`
        Compiling libc v0.1.8
        Compiling regex-syntax v0.2.1
        Compiling memchr v0.1.3
        Compiling aho-corasick v0.3.0
        Compiling regex v0.1.41
        /home/john/.cargo/registry/src/github.com-0a35038f75765ae4/regex-0.1.41/src/lib.rs:394:34: 
        394:51 error: #[feature] may not be used on the stable release channel
        /home/john/.cargo/registry/src/github.com-0a35038f75765ae4/regex-0.1.41/src/lib.rs:394     
         #![cfg_attr(feature = "pattern", feature(pattern))]
                     ^~~~~~~~~~~~~~~~~
         error: aborting due to previous error
         Could not compile `regex`.
    

Looks like Rust 1.2 broke Rust's regular expression module. Somebody isn't
running enough regression tests.

~~~
dbaupp
The `cfg_attr` explicitly means that the `feature(pattern)` (the problem here)
only gets activated when someone opts into it by activating regex's `pattern`
feature, and by activating it they're opting-in to being nightly-only, i.e.
outside the core stability guarantees of the stable releases.

Could you post your Cargo.toml?

~~~
Animats

        [package]
        name = "hello_world"
        version = "0.0.1"
        authors = [ "John Nagle <nagle@animats.com>" ]
        [[bin]]
        name = "hello_world"

~~~
Animats
I dunno. Probably Cargo had some previous state stored somewhere that 'clean'
didn't clear. I don't have time to figure out the internals of yet another
weirdo build system.

~~~
steveklabnik
Okay! That's not consistent with how Cargo is supposed to work, so if you can
share anything, please open an issue. Sorry about that.

------
ewillbefull
Nice to see bors in the contributor list!

~~~
steveklabnik
Bots are people too! /r/botsrights! :)

------
haberman
My current dream: Rust compiling to C, WebAssembly, .NET and JVM. We could
finally have a fast, powerful, memory-safe language that can run anywhere
without requiring a runtime or GC.

~~~
jason_dstillery
I don't really grok what this means - WebAssembly, .NET, and the JVM _are_
runtimes, how does Rust compiling to them lead to a future that doesn't
require a runtime?

~~~
serverholic
Rust doesn't require it's own runtime but will be able to use existing ones
eventually.

------
tacone
The improvement in build speed is just exciting. Thank you to anybody that
made it possible.

~~~
kibwen
There are still enormous improvements to be made! In a year I think we'll be
astounded at what we'd managed to put up with all this time. :)

~~~
mrec
Is there a master tracking bug for compilation speedup ideas? Just curious.

------
listic
Which projects are the most notable Rust users as of today?

~~~
kibwen
In addition to nathan7's answer, there's also terminal.com (and I'm assuming
here that we're not counting Mozilla's usage of Rust in Servo (and soon
Firefox)). There are other companies putting various pieces of Rust code
through their paces and we have outreach programs to help these companies in
their explorations (I don't like name-dropping before announcements are fully
ready, I'll be able to say more later this year).

In general though, remember what a young language Rust is (May wasn't that
long ago!) and understand that large and notable projects take time to appear.
Docker didn't appear until Go 1.0 was one year old, for example.

------
alexro
Isn't Rust the next C?

~~~
steveklabnik
That depends on what you think of as being the core of C. Or, for example,
some see Rust as the next C++, which is itself the next C, so is Rust
_transitively_ the next C?

Programming languages never die, so I don't have a personal opinion on this
point, exactly. For me, I would only write C code if I was working on a C
project, or if I couldn't get a Rust compiler for the target platform. My
starting point would be Rust, it would have to be disqualified for me to use
C. Then again, I am the most biased person possible... (and also prefer C to
C++) But regardless, C will never, ever die, so talk of Rust 'killing' or
'replacing' C is misguided, in my opinion.

~~~
tinco
I'd consider a language dead if there were no (or very little) new projects
being done in it. For example you might say COBOL is alive because many
financial institutions still run COBOL services, but you'd be hard pressed to
find someone who would advocate to start a new standalone COBOL project.

(Queue person who started a COBOL project last week..)

In that sense, I think Rust has a real shot at at least severely wounding C++
or at least opening the door for the real C++ killer (it might be that Rust is
a smidgen too strict in the mut ref department to really kill C++, I'm
encountering a lot of push back from experienced C++ devs). We're talking
about a 15 year timescale though, so that's at least 3 era's of computing.

~~~
steveklabnik

      > I'm encountering a lot of push back from experienced C++ devs
    

Yeah, this bit is really interesting. It seems fairly split, though I'm not
sure in what ratio. Some C++ devs are really into it, but others are very
opposed. When you're used to total freedom, but then the compiler yells at
you, there can be frustration...

We've also seen a _tremendous_ amount of interest from people who don't
strongly identify as a 'systems programmer' at present. RustCamp was last
weekend, and the audience is very broad. It's a classic "growing the pie"
situation: Rust may or may not take away some of C++'s audience, but it very
well just might make the pool of systems programmers significantly larger.
We'll see!

~~~
andresmanz
For me it's not really the freedom. I already said that elsewhere, but: I
don't mind when the compiler yells at me. I just don't like the compiler to
criticize my coding style by default. Initially, I liked Rust because it
reminded me of C++. But then I began reading the book and basically it was
full of statements about the coding style I prefer (and will keep) being bad.
That's an incredibly stupid reason, but it kind of keeps me away from the
language. But it's also the fact that C++ still is very widespread and has
tons of libraries.

I wouldn't say never, of course. I'm looking forward to using Rust. Just not
now.

~~~
tikue_
Every language has different idioms. In many cases, what works in C++ doesn't
work in Rust. Generally, anything the book says is bad you should take as
qualified to mean bad in the context of Rust programming, not programming at
large.

~~~
andresmanz
Sorry, I didn't make it clear enough. I was primarily referring to code
formatting. Spaces instead of tabs, for example, or not writing opening curly
braces on separate lines. These things are a matter of taste and should be
friendly recommended at best. Guidelines for idioms are important and should
occur as early as possible in the book, so that's perfectly fine.

~~~
grokys
I don't think telling you how to format your code for a particular language is
a bad thing. I am quite happy using { on a new line in C# but on the same line
in JS, using underscore_separated_method_names in C and camelCasedMethodNames
in Java. To me, once you've been round the block with more than one or two
languages you can get used to whatever style, but using the style for the
language that you're writing in is something you should try to do for other
people who read your code.

Reading Java code that uses undercore_separated_method_names or C# code that
uses camedCased immediately makes me think the author doesn't know what s/he's
doing.

------
falcolas
How long until every minor Rust release is no longer a front page event on HN?
Nothing against the language, but this doesn't really offer a whole lot in
terms of discussion; reflected by the (current) point totals: 102 points and 4
comments.

~~~
acomjean
I'm not even a rust user (tried it out a little haven't had the time..). I
really enjoy the rust posts here though.

Watching the language evolve has been interesting for me. Its an interesting
language for a variety of reasons. Those that did a lot of c/c++ programing
are probably the biggest fans.

This post wasn't the greatest, but good to see where things are going/
improvements being made.

~~~
adrusi
Normally I avoid making comments that are essentially upvotes, but I wanted to
make it clear that acomjean is not an unusual case. I also haven't really used
Rust much, but I've followed it's development since the 0.3 days when it was a
completely different language. I find the kind of design ideas that go into it
very interesting and I get especially excited by the fact that _it 's actually
a serious language now_.

I think Rust strikes a chord with a lot of people, even those with no
investment in it.

