Announcing Rust 1.0 Beta

http://blog.rust-lang.org/2015/04/03/Rust-1.0-beta.html

by steveklabnik • 11 years ago

348 97 11 years ago

steveklabnik14• 11 years ago

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• 11 years ago

Can't wait to play around with this!

rdtsc• 11 years ago

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.

didip• 11 years ago

Question for Rust peeps out there:

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

steveklabnik14• 11 years ago

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_plugh5• 11 years ago

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

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

vbezhenar2• 11 years ago

Is there plans to drop glibc dependency? Rust should be able to do system calls itself and glibc should be as optional FFI library IMO.

dkhenry• 11 years ago

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

nemo44x2• 11 years ago

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.

heydenberk• 11 years ago

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• 11 years ago

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

ZeroGravitas2• 11 years ago

I'd imagine that such a bank of tests would be helpful in tuning performance too. Though perhaps the reality of each tweak only contributing a fraction of a percent would be considered depressing compared with the standard practice of saying that a microbenchmark is now 2x or 4x faster.

ilitirit2• 11 years ago

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_• 11 years ago

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

Jweb_Guru2• 11 years ago

There is no ~str, but when there was it was largely identical to what String is now.

pcwalton3• 11 years ago

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.

mbrubeck• 11 years ago

In this example the dichotomy is between String (which is guaranteed by the type system to be valid UTF-8) and OsStr (which might be in an unknown encoding or otherwise not decodable to valid Unicode).

This is exactly when you want a systems language to require explicit conversions, rather than converting things silently and possibly losing or corrupting data.

doomrobo• 11 years ago

That would be:

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

ilitirit2• 11 years ago

No, I just want the file name.

steveklabnik14• 11 years ago

Yes, it's true. Code like this is going to be more verbose. Often, it's due to Rust being a systems language and exposing low-level details to you, combined with the type system ensuring safety. In this instance, `Path` is actually fairly complex. From the RFC: https://github.com/rust-lang/rfcs/blob/master/text/0474-path...

        > The design of a path abstraction is surprisingly hard. Paths work
        > radically differently on different platforms, so providing a
        > cross-platform abstraction is challenging. On some platforms, paths
        > are not required to be in Unicode, posing ergonomic and semantic
        > difficulties for a Rust API. These difficulties are compounded if one
        > also tries to provide efficient path manipulation that does not, for
        > example, require extraneous copying. And, of course, the API should
        > be easy and pleasant to use.

So, in this case, you have to call `file_name` to get the filename, but that returns an `Option`, since it might not be a file, it could be a directory. The `unwrap` says "crash if it's not a filename." You then have an `OsStr`, which is a string type that handles the kinds of cross-platform issues alluded to in the above paragraph. `to_str` will then attempt to turn it into a `&str`, but because `&str` must be unicode, if the conversion fails, it _also_ returns an Option, which is the last unwrap.

In systems programming, details matter. As such, our stdlib APIs try to expose those details. I expect some people will write higher-level abstractions that hide all this if you don't care as much.

Tradeoffs tradeoffs tradeoffs...

jerf• 11 years ago

"Often, it's due to Rust being a systems language and exposing low-level details to you, combined with the type system ensuring safety."

I'm not convinced it's being a "systems language" (in the sense I think you mean). The last three languages I've learned to fluency have all, in various ways, been very concerned about errors: Erlang, Haskell, and Go. Yes, they have widely varying opinions about what to do with them, but they all agree that you have to be fairly constantly worried about them. You can't sweep them under the rug; you need a strategy, and you need to deal with the resulting issues head on.

Despite their differences, what I feel like I've learned from them is that historically speaking, the vast majority of popular languages and their communities have been downright cavalier about errors. It's often in all the little details rather than a consistent, stated design goal, but the presence of various nils and nulls, APIs that will happily return empty strings for paths instead of errors, and all kinds of APIs and libraries that seem to be subconsciously written with the belief that returning an error is a failure on the part of the library and will go to what now seem to me to be absurd lengths to somehow keep klunking along in the presence of already-manifested failure. Even for languages that think they're being really good with exceptions, I find that when I go back to them, they end up using the exception support to "permit" themselves to be sloppy and hope the exceptions will pick up the pieces... and they often don't. Not because of some theoretical weakness, but because allowing developers to think they don't have to think about the error cases means precisely that they don't!

People are used to errors not poking them in the face until deploy time. It seems to me there's a strong, broad motion towards developing languages that will in one way or another force you to deal with them at compile time. It's a culture shock for people, but, I'll tell you this, get really good at Rust or any of these other languages and go back to any of those other languages, and you will find your code changes in those other languages to suddenly look a lot more like your Rust does anyhow, which means this putative disadvantage of Rust evaporates anyhow. Once you see how sloppy you were being, it's hard to go back in good conscience.

Jweb_Guru2• 11 years ago

If you were willing to allow for potential escape characters and acknowledge (to the user) the fact that the path might not have a file name, you could write:

    println!("file name: {:?}", path.file_name());

or just for escape characters, but only if the file name existed:

    if let Some(name) = path.file_name() {
        println!("file name: {:?}", name);
    }

Note that the unwrap() isn't boilerplate, in either case: if you are using `unwrap()` you are implicitly saying that you know for a fact that the file name is present (the first time) and a valid UTF-8 string (the second time), which isn't guaranteed in the general case on all platforms. If you wanted to write this more robustly, and these weren't guaranteed, you would need to explicitly take care of those cases.

I/O has lots of tricky error cases, and Rust usually requires you to acknowledge that. You can avoid dealing with those cases with unwrap(), or you can explicitly handle them. Personally, I much prefer this to being surprised only when the weird error case unexpectedly turns up because I never considered the situation in question, and that's generally how Rust handles things, but it depends on the task. It may make Rust less appropriate for quick scripting tasks, for example, where the domain is well-defined and the script is not likely to be reused (but I find that those scripts have an annoying way of getting reused anyway).

drchickensalad• 11 years ago

However, rust would be relatively well-suited for a "dirty quick scripting task". You could make a more traditional wrapper for the operations you like to use that assumes these rare edge cases don't happen, and panic otherwise.

This is sort of rust's philosophy; being explicit. Rust has no problem with failing, it just has a problem with failing without you telling it to. If you write a wrapper that implies you are willing to fail on these cases, then you're being explicit by choosing to use these functions instead :)

phaylon• 11 years ago

I would say it is familiarity, but in another sense. You can use something like

    path.file_name().and_then(|f| f.to_str()).unwrap()

but that really doesn't buy you much.

Where familiarity comes in I believe is in what that line communicates to me: There might not be a file name (like having '/' as path), and that getting a string slice out of it might fail (the kind of string the platform uses for paths might not be UTF-8 compatible).

Plus, the unwrap()s tell me that whoever wrote the code considered it an assertion failure if one of those is happening.

I read a lot more Rust than I write, and it really helps that the code communicates a lot. And with knowing about OsString/OsStr beforehand, I only had to lookup when file_name() returns None, the rest is rather implicit by convention, or familiarity.

tikue_• 11 years ago

I wish `and_then` were named `flat_map` so badly.

Manishearth3• 11 years ago

To add to the other comments, Rust prefers to make error cases explicit. We have memory safety. You can opt out of it, but you have to opt out explicitly. We have exhaustive match. You can use a wildcard, but you need to explicitly do so. We have nullables and Results. You need to explicitly acknowledge the error/null case, or use `unwrap()` to say that you don't mind a panic at this point.

This leads to verbosity at times, but usually its a good verbosity.

mrec• 11 years ago

I'm sure I'm not the first (or the hundredth) to say this, but `unwrap` has always struck me as a horribly innocuous spelling of "yes, feel free to crash here".

I presume there is (or could be) a standard lint to prevent this getting into production code, but it still feels kind of icky.

masklinn2• 11 years ago

surely something like should be easier?

That would be nice, but as others hinted that wouldn't actually work:

* there are paths without a file_name (`/`) so it returns an Option to make that evident

* to_str attempts to convert the OS-dependent thing to a Rust string. Rust strings are valid unicode, but many filesystems don't have such strict requirements[0]. Again Rust returns an Option to makes that evident although there's a "to_string_lossy" method which will simply replace invalid sequences with U+FFFD if you don't really care

The Rust philosophy is generally to expose these issues upfront and force the developer to consider them (and either handle or explicitly ignore them). It is indubitably less convenient than e.g. Python 3's `PurePath(app_path).name` returning an str, but you'll have had to decide what happens in case of failure.

Paths are really a good example of something which looks simple, should be simple, and is actually anything but simple for historical and technical reasons, especially in a cross-platform context.

[0]

* Unix paths are the most troublesome: they're arbitrary bags of (non-NUL) bytes, they don't have to be in a known encoding, they don't have to be in any encoding.

* Windows paths are not guaranteed to be Unicode either: they're UTF-16 code units aka UCS2 + surrogates, and the surrogates may be unpaired, leading to invalid Unicode.

* OSX paths are guaranteed to be valid Unicode.

WallWextra• 11 years ago

Also, OSX applies unicode normalization to the filenames, which can cause some interoperability problems with unix, e.g. you try to copy files forth and back between the systems and end up with two copies of a file, with identical-looking filenames that differ in their unicode normal form.

enjolras• 11 years ago

Just my 2cs, but the complexity of this code is here to remind you there are a lot of cases you have to take into account :

    let path = Path::new(&app_path);
    if let Some(ostr) = path.file_name() {
       if let Some(str) = ostr.to_str() {
           println!("file name : {}", str);
       } else {
          println!("WARNING : file name is not a valid unicode sequence ! (file name : {:?}", ostr);
       }
    } else {
      println!("Path is either a root directory or a dot entry, it has no filename");
    }

rat873• 11 years ago

I think unwrap calls are mainly meant for quick and dirty stuff and if you find yourself doing it it may be the wrong solution.

PopsiclePete2• 11 years ago

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?

steveklabnik14• 11 years ago

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. :)

PopsiclePete2• 11 years ago

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/ which says "don't use me"

callahad5• 11 years ago

Looks like libstd/lib.rs still points to old_io, which shows up on http://doc.rust-lang.org/1.0.0-beta/std/

Same with libcollections/fmt.rs defining the write! macro as taking an old_io::Writer

There's also a bunch of old_io in http://doc.rust-lang.org/book/concurrency.html

nemo44x2• 11 years ago

The doc's, and more specifically the tutorials, can be a bit stale. If you're referencing the one I think you are (building the number guessing game) it's old. I'm sure it will be updated eventually. [1]

One of the hardest things about learning Rust right now is that because it is not 1.0, lots of the tutorials, sample code and 3rd-party documentation is outdated - or parts of it are.

Learning Rust "the right way" will certainly get easier after 1.0 is finally out and reliable/stable the tutorials, code bases and doc's will follow.

[1] I just checked and it is in fact updated.

kibwen3• 11 years ago

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

smt885• 11 years ago

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• 11 years ago

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.

kibwen3• 11 years ago

I should first disclaim that I'm not a member of the Rust core team, but I have been closely following and contributing to the language since 2011 and so have rather extensive insight into the arc of its evolution.

That said, my personal opinion is that usability is absolutely a primary focus of Rust. The notion of "regions" (renamed to "lifetimes" in Rust to be more user-friendly) has existed in academic literature for a while, but Rust has spent an enormous amount of effort and tried a wide variety of approaches in its quest to make this concept as accessible as possible to the everyday programmer. In other words, Rust is a research project focused on advancing the usability of safe and zero-overhead memory management.

I wouldn't say it is the primary focus, because first achieving the task of safe and zero-overhead memory management is itself a major undertaking.

Getting feedback on usability hasn't generally been achieved by formal surveys, but instead generally by brainstorming possible changes to the language and taking part in the resulting discussion. These discussions have happened in a variety of forums over the years so I can't point you to any comprehensive collection of them, but very often the ideas themselves are initially presented on the blog of Niko Matsakis, who is currently Rust's technical lead ( http://smallcultfollowing.com/babysteps/blog/categories/rust... , which is a fascinating read for those looking to understand the language's volatile history). It also involves being open to proposals from people using the language in the community, which eventually turned into the current RFC process ( https://github.com/rust-lang/rfcs ) and which is a bit like Python's PEP process.

  > Usability involves more than syntax --package
  > management, interoperability, docs, and error messages.

Rust's first stab at a package manager (the original namesake for the current Cargo) was in 2011, and we had at least two others in between. The fact that Mozilla was eventually willing to contract out development of the current package manager to domain experts (the Bundler developers) should show how much we care about having a good solution to this problem early-on. It has also been a goal from the beginning to have a rock-solid and very transparent means of interoperating with C, and being able to expose Rust libraries as C libraries was also something that was desired from the outset even if it took a while for the design and implementation to materialize. Having good error messages has always been taken very seriously, and I'm happy to see that people praise us very often for the niceness of our compiler messages (though we can still be doing better in many places). As for docs, Mozilla's been contracting Steve Klabnik for over a year now to not only write a comprehensive tutorial for Rust (now a book: http://doc.rust-lang.org/nightly/book/ ), but also to write up documentation and usage examples for every single type and function in the standard library.

sirclueless• 11 years ago

    I'm genuinely curious because, as far as I know, none of the
    major languages were designed to be usable...

I think that's a little narrow-minded. Of course languages are designed to be usable. "Usable" is almost meaningless on its own, as every language is intended for use by developers to solve problems (toy languages notwithstanding).

As for your specific goals, "package management, interoperability, docs, and error messages," I think there are in fact major languages designed with very specific goals in those areas. Node.js for example was designed to leverage the immense popularity and familiarity with JavaScript, and it has a clear story for package management that has enabled an enormous ecosystem. Go is a language that from the get-go was designed with a coherent story of how to build large and maintainable systems, encompassing package management and the module system, language features chosen for their simplicity such as interfaces and the lack of generics, and a canonical source formatting tool to attempt to make the whole ecosystem more readable and understandable.

Rust of course has its own answers for usability. They too have a package system that can enable a thriving ecosystem. Their approach to memory management is a naked attempt to make their language "usable," an attempt to make programming more user-friendly language in contexts where interpreted languages, bytecode and even garbage collection are untenable. Their docs are coming along nicely, their error messages perhaps less so.

To say that no major languages are designed for usability is laughable. In fact, I would say that every major language since and including x86 machine code has been designed with usability concerns front and center. The more recent wave of languages especially -- practically no one is trying to beat C and C++ on technical capabilities. They are trying to beat them on ergonomics.

grigio• 11 years ago

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

steveklabnik14• 11 years ago

https://github.com/Homebrew/homebrew/pull/38346 should interest you

callahad5• 11 years ago

Sub in the version and sha256 and you should be good to go: https://github.com/Homebrew/homebrew/pull/38346/files

callahad5• 11 years ago

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.

tomjen3• 11 years ago

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.

Announcing Rust 1.0 Beta

Related Stories