
Announcing Rust 1.0 Beta - steveklabnik
http://blog.rust-lang.org/2015/04/03/Rust-1.0-beta.html
======
steveklabnik
Two big things:

    
    
        > the beta release represents an accurate preview of what Rust 1.0 will include.
    

and

    
    
        > We don’t plan on making functional changes to stable content,
        > though naturally we may make minor corrections or additions to the
        > library APIs if shortcomings or problems are uncovered (but the bar
        > for such changes is relatively high).
    

This is the first release we've promised this kind of stability. The team and
community has been doing an incredible amount of work lately to make this
happen. We really hope you'll like what we've been up to, but Rust isn't for
everyone, so no worries if it's not for you. Constructive criticism always
welcome. <3

As of today, my job gets harder: "things are always changing" is no longer an
excuse for missing docs. The six weeks until release is largely about polish,
and I have some pretty big plans...

~~~
Jemaclus
Can't wait to play around with this!

------
kibwen
Six weeks to 1.0-stable! And it's going to be a hell of a ride, since there's
still tons of polish to do with respect to tooling and documentation and
bugfixes. In other words, no time to celebrate. :P

If you'd like to help out, one of the best things that new users can do is
simply to write a toy project or library in Rust and record their experience.
If you crash the compiler somehow, file a bug! If you're confused by a poorly-
worded error message, that's a bug too! If our docs are lacking, heck yes that
is also a bug! If we're missing some crucial API on the stable branch, let us
know so that we can prioritize which APIs to stabilize! We care about every
aspect of the experience of developing Rust, and though our resources are
finite we'll do our best to address the most common pain points first.

[https://github.com/rust-lang/rust/issues](https://github.com/rust-
lang/rust/issues)

~~~
smt88
So would you say that usability has been a primary focus of Rust from the
beginning? Is it _the_ primary focus?

If so, what kind of research did you do to make Rust usable? Any surveys or
anything like that?

I'm genuinely curious because, as far as I know, none of the major languages
were designed to be usable (which is not the same as "concise" or "easy").
Some of them have made huge strides in usability, but (understandably) none of
them started that way.

Usability involves more than syntax --package management, interoperability,
docs, and error messages. Since you mentioned those things, it made me wonder
whether Rust were designed in a more user-focused way.

~~~
leeoniya
they've definitely had feedback from all the crate creators and actual daily
work through - at minimum - Servo's implementation.

the _primary_ focus has always been systems-language speed and memory safety
without a gc.

~~~
andrewflnr
Actually the no-GC thing is pretty recent. Memory safety was the big deal, and
IIRC they didn't think it could be done without a GC until sometime in the
last couple years.

~~~
kibwen
Ancient Rust accounted for the existence of garbage collection, but still
tried to prefer zero-overhead memory management via linear types and move
semantics. You are correct that it wasn't evident until much later that it
would be possible to get by without GC entirely.

------
heydenberk
I'm impressed with how thoughtful the entire Rust development cycle has been.
They've managed not just to strike a balance between stability and language
redesign, but to approach to API and syntax standardization in a way that made
tracking the changes relatively painless. Some of this is done in the language
itself, with opt-in statements and stability annotations in the API, but the
tooling around compatibility in the ecosystem is quite useful as well. Now
they're going to doing CI on their own nightlies against packages in the
ecosystem:

> To help ensure that we don’t accidentally introduce breakage as we add new
> features, we’ve also been working on an exciting new CI infrastructure to
> allow us to monitor which packages are building with the Nightly builds and
> detect regressions across the entire Rust ecosystem, not just our own test
> base.

~~~
idunning
CI against package ecosystems is a really great idea. We do it for Julia too
[1], and it can identify some really subtle issues that would otherwise take
longer to become apparent.

[http://pkg.julialang.org/pulse.html](http://pkg.julialang.org/pulse.html)

------
rdtsc
Great work everyone involved!

Rust is very exciting.

It has gotten many things right -- a really good approach to safety, didn't
sacrifice performance, powerful well thought out type system. I think we might
finally see the next generation "systems language". We've heard promises
before but hopefully this is finally it.

------
ilitirit
I like Rust, and I'm probably missing something, but do I feel that some
things should be easier. At times the language (or standard library, I
suppose) feels a bit unwieldy. For example, trying to coerce a string from
certain types:

    
    
        let path = Path::new(&app_path)
        println!("file name: {}", path.file_name().unwrap().to_str().unwrap());
    

Hopefully this is just a case of unfamiliarity, but surely something like
should be easier?

~~~
Mr_T_
The 'String', '~str' dichotomy is really unfortunate.

~~~
pcwalton
Presumably you mean String/&str? (~str hasn't existed for a long time.)

On the contrary, the lack of the string/string-view distinction is widely
considered a flaw in the C++ standard libraries. C++14 introduces
std::string_view to correct it. Rust's String/str distinction is just the same
as C++14's std::string/std::string_view.

~~~
frowaway001
Apart from the Rust's usual rule to invent some abbreviations, but only apply
them half the time.

Then "types start with an uppercase letter" except when the language creators
break their own rule.

Then the fun "sometimes we use () and sometimes we use [] to do practically
the same thing".

Then the various insanities with ::.

Then Generics. How many examples of languages which tried to use <> for
Generics do we actually need before people learn the lesson?

I really wished some people took Rust, and wrote a new frontend to get rid of
all the pointless inconsistencies and other "C did, so it has to be good"-isms
(like_all_this_underscore_stuff or the ridiculous abbreviations), because many
ideas of Rust are not only good but brilliant and deserve to be put into
languages which don't belong to the purely-academic category.

I really wish Rust to succeed, but can we stop this approach of "3 steps
forward and 2 steps backward" to language design?

~~~
pcwalton
> Apart from the Rust's usual rule to invent some abbreviations, but only
> apply them half the time.

Do you have an example?

> Then "types start with an uppercase letter" except when the language
> creators break their own rule.

They always start with a capital letter, except for built-in types or FFI
bindings to libraries such as libc where the original types used a lowercase
letter. This convention is exactly the same as Java.

> Then the fun "sometimes we use () and sometimes we use [] to do practically
> the same thing".

I've never heard this before. Do you have an example? () is used for function
calls, grouping, and tuples, while [] is used for array literals and array
indexing.

> Then the various insanities with ::.

The double-colon is very useful so that you can tell the difference between
module lookup and field projection/method calling. Early Rust used . for
module lookup, and it was confusing to tell at a glance whether a function was
being called or a method was being invoked.

> Then Generics. How many examples of languages which tried to use <> for
> Generics do we actually need before people learn the lesson?

Using square brackets like Scala wouldn't actually help with the ambiguity,
because it would be ambiguous with array indexing. The only syntax I've seen
that actually solves the ambiguity is D's `!()`, which was deemed too
unfamiliar. Angle brackets were chosen because they are familiar and aren't
really any worse than the other mainstream options.

> I really wished some people took Rust, and wrote a new frontend to get rid
> of all the pointless inconsistencies and other "C did, so it has to be
> good"-isms (like_all_this_underscore_stuff or the ridiculous abbreviations)

The underscore naming convention was actually taken from Python's PEP 8. Rust
doesn't really have any more abbreviations than most other languages at this
point.

~~~
callahad
> > Then the fun "sometimes we use () and sometimes we use [] to do
> practically the same thing".

> I've never heard this before. Do you have an example? () is used for
> function calls, grouping, and tuples, while [] is used for array literals
> and array indexing.

Maybe referring to the ability to use either type of brace with macros?

~~~
pcwalton
Yeah, you can use any type of delimiter with macros, but I think that's an
important feature, especially since macros can expand to declarations. Early
versions of Rust required parentheses for all macro invocations, and that
looked really ugly for anything that looked like a block. Delimiter
interchangeability is a feature from Racket that works really well when it
comes to macros and I'd hate to give it up.

~~~
blaenk
Agreed. They allow you to naturally create vectors with the bracket delimiter
`vec![1, 2, 3]`, create spawn-like macros with the brace delimiter `spawn {
code }`, and in the normal case just use parentheses `println!("testing")`

------
PopsiclePete
Good job, guys! This is an exciting language. Really happy about the "native"
language revival going on lately.

I'm reading the docs, and they say that for I/O, use the 'old_io' module,
which is...deprecated?

If I were to start doing _any_ I/O in Rust beta, would that code be
essentially throw-away as soon as the 'new' io module lands?

~~~
steveklabnik
They should absolutely not say to use `old_io`, that must have slipped
through. New IO has fully landed, you can't even use `old_io` in the beta.
Which page? I'll fix it right now. :)

~~~
PopsiclePete
[http://doc.rust-lang.org/nightly/std/index.html](http://doc.rust-
lang.org/nightly/std/index.html)

"Common types of I/O, including files, TCP, UDP, pipes, Unix domain sockets,
timers, and process spawning, are defined in the old_io module."

Following the "old_io" link leads me to [http://doc.rust-
lang.org/nightly/std/old_io/](http://doc.rust-lang.org/nightly/std/old_io/)
which says "don't use me"

~~~
steveklabnik
Ah, thank you! We used to mention it from io's page, and I removed that, but
this one slipped. [https://github.com/rust-
lang/rust/pull/24022](https://github.com/rust-lang/rust/pull/24022)

------
didip
Question for Rust peeps out there:

Is there a documentation on how to build single binary executable for Rust?

~~~
steveklabnik
I'm assuming you're referring to static linking.

Right now, we depend on glibc, and it cannot be statically linked. By default,
Rust applications statically link everything but glibc already.

At least one core team member is strongly advocating for musl support for
truly standalone binaries in the 1.1 timeframe, but nothing is likely to
change for 1.0, and it's too early to decide on 1.1 features yet :)

~~~
xyzzy_plugh

      > Right now, we depend on glibc, and it cannot be statically linked.
    

Could you expand on this? Why can it not be statically linked?

~~~
spystath
Name resolution libraries are loaded dynamically [1,2], so glibc can't be
linked statically if you want NSS to work. I gather there might be a way to
explicitly link to a specific resolution library but this is practically
unsupported/poorly documented.

[1]:
[https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked...](https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F)

[2]: [http://stackoverflow.com/questions/3430400/linux-static-
link...](http://stackoverflow.com/questions/3430400/linux-static-linking-is-
dead)

~~~
xyzzy_plugh
I understand this limitation. I can currently get around this by using
--enable-static-nss.

Does rust currently expose any way to do this? Could I perform linking myself
as a workaround?

~~~
steveklabnik
> Could I perform linking myself as a workaround?

You can but it requires lots of black magic, and certainly a nightly rather
than beta Rust ;)

[http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...](http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-
static-linux-binary-in-rust.html) is an old blog post that can get you
started.

~~~
xyzzy_plugh
Wonderful -- thanks Steve! Best of luck on the upcoming release.

------
dkhenry
Finally. I had been holding off on implementing things in rust because of the
time spent getting libraries up to date with the nightlies. This is huge for
the rust ecosystem

~~~
nemo44x
Indeed. So many times over the last few months things just suddenly broke. I
understand and all but it will be nice to see some stability.

I really feel the community, which is already awesome, will start to build new
things at a rapid pace.

------
tomjen3
I am somewhat underwhelmed by this because I can't really come up with a
problem that can't be solved by C++, Java, Python or Go (or some combination
hereof) which could be solved by another low-level language without garbage
collection.

------
grigio
❯❯❯ brew install rust Warning: rust-1.0.0-alpha.2 already installed

:(

~~~
callahad
Sub in the version and sha256 and you should be good to go:
[https://github.com/Homebrew/homebrew/pull/38346/files](https://github.com/Homebrew/homebrew/pull/38346/files)

~~~
callahad
Actually, this isn't enough. You also want to set --release-channel=beta,
otherwise you effectively get a nightly build of the beta tarball (unstable
features available) instead of a proper beta channel build of that tarball.

