Rust 1.1 Stable, the Community Subteam, and RustCamp

http://blog.rust-lang.org/2015/06/25/Rust-1.1.html

by steveklabnik • 11 years ago

287 140 11 years ago

kibwen14• 11 years ago

The 1.1 release came out a day earlier than I expected, I suppose we're releasing on Thursdays now. :P Note that 1.1 is a relatively small release, since, due to launching the train release model, it was in development for just three weeks prior to 1.0 (rather than the usual six weeks that all subsequent releases will have spent in development), and during that time we were all understandably in a tizzy preparing for a post-stability world. :)

However, despite that short and distracted development window, we still managed to squeeze out compiler performance improvements that should result in 30% faster compiles for crates in the wild. You can expect even more progress on the compilation speed front for 1.2, due to be released August 6, along with a slew of stabilized and much-demanded stdlib APIs.

Let me also mention that tickets have just gone on sale for the first official Rust conference, a small one-day event in Berkeley: http://rustcamp.com/ We'll be using the experience from this proto-conference as a guide for larger events in the future, so even if you can't go we'd love to get your feedback as to what you'd like to see from a Rust conference.

kbenson• 11 years ago

If I wasn't going to be on vacation during that conference, I would be strongly tempted to go, and I haven't written a line of rust. I get excited about every rust submission I see on HN though, and greedily gobble up as much information as I can. I can't help it, Rust just excites me.

So, whatever you guys are doing, WRT marketing, you are doing something right.

kibwen14• 11 years ago

Sorry, it took us a while to find a venue and pull together initial sponsorship funding (ultimately provided by Jane Street, Skylight, and Mozilla), which resulted in us only announcing the date of the conference about a month ago. Next year we should be able to announce much further in advance, so maybe you'll be able to schedule your vacation around it. :)

mlitchard2• 11 years ago

What I like about rust is how I think it will go together really well with a language like idris. The idea is, whatever rust cannot guarantee an idris-to-rust transpiler can. People should have a much easier time making solid low-level code in the future.

arielby4• 11 years ago

1.2 (which was stabilized today) is also a mostly-quality release (`const fn` and associated constants landed behind a feature gate, but are still not-really-done).

kibwen14• 11 years ago

Indeed, the 1.2 development cycle was relatively sleepy as the preceding six months were spent in crunch mode preparing for 1.0, and everyone was eager for a bit of summer vacation. :) A lot of this cycle has also been spent prioritizing for future language development and organizing the new subteams. But I'd still say that 1.2 managed to get a lot done, since there's just so much low hanging fruit wrt stdlib APIs to stabilize.

alexnewman• 11 years ago

OOh and there's a rust podcast out as well. You can find it in the new section of hacker news.

kiliancs• 11 years ago

Just providing the direct link http://rustyrad.io/

pohl• 11 years ago

Thanks for the heads-up. Here's the link to the story:

https://news.ycombinator.com/item?id=9779676

mwcampbell• 11 years ago

What exactly does MSVC support entail? For example, will one be able to debug Rust programs with WinDbg or the Visual Studio debugger? IIUC, that would require LLVM to output PDB files.

steveklabnik16• 11 years ago

https://github.com/rust-lang/rust/pull/25350 was the PR with the initial support.

    > The tl;dr; of this change is that there is a new target of the compiler,
    > x86_64-pc-windows-msvc, which will not interact with the MinGW toolchain at
    > all and will instead use link.exe to assemble output artifacts.

We're very interested in improving support so that you can use VS's features fully. These are just first steps.

brson2• 11 years ago

MSVC support primarily means that Rust programs link with the MSVC toolchain, and use structured exception handling for unwinding. There are no GNU components involved and no need to install MinGW.

alexcrichton• 11 years ago

In addition to not interacting with the GNU toolchain at all (through MinGW), MSVC support will indeed enable native Windows debug info (as you mentioned) so native tools can be used to debug Rust code. Note that this isn't 100% implemented yet, but it's coming soon! Additionally you'll get interoperation with MSVC-compiled libraries. Libraries compiled with MinGW don't interoperate well with MSVC (and vice versa), so this enables Rust code to link against an MSVC-compiled native library.

kibwen14• 11 years ago

(HN readers, note that alexcrichton is the one spearheading the MSVC effort.)

jnbiche• 11 years ago

Will MinGW still be supported, or will that be dropped?

alricb• 11 years ago

Have there been documentation improvements? For instance http://doc.rust-lang.org/nightly/std/str/ is still quite obscure: it talks about the traits returned by certain methods, but there isn't an obvious way to get to the documentation for those methods, if you'd like to know how .lines() is different from .lines_any(), for example. Compare with https://docs.python.org/3/library/stdtypes.html#str where all the methods are listed, along with what they do.

steveklabnik16• 11 years ago

There have been a number of doc fixes, but they've largely been polish more than brand new things. I've had about ~50 PRs in this release myself, after a quick look, and we had a bunch of community stuff as well.

The specific issue you're talking about is due to using Markdown rather than ReST, basically. We didn't manually link those methods, but probably could.

In general, the API docs could use a lot of work. There's always so much more to do.

gmjosack• 11 years ago

You probably want this page for str:

http://doc.rust-lang.org/nightly/std/primitive.str.html

It's unfortunate that most of the links navigate you to the less useful doc.

bpicolo2• 11 years ago

I'm getting bizarre rendering errors in chrome for whatever character prefixes "self" in all those (I assume &?)

eoi• 11 years ago

I'd like to mention that I've been happy with the docs, once I learned to find them.

To take the given example, I would start at http://doc.rust-lang.org/std/ and hit `s` to start a search. Searching for `str::lines` gives http://doc.rust-lang.org/std/primitive.str.html#method.lines as the second result, which has the two methods conveniently next to each other, succinctly explains them, and shows an example of using each one.

I've had good luck with docs for the few third party libraries I've tried so far too. The recommended doc generation creates pages in the same format as the std docs, so as you get comfortable navigating them you get comfortable navigating many third party docs as well.

gamegoblin• 11 years ago

I hope the Rust team also starts prioritizing compiler crashes.

I started using Rust exclusively for hobby projects after the 1.0 release, to force myself to learn the language, but I found myself running into compiler panics on nearly a daily basis.

Admittedly, the code the compiler tended to crash on was very macro-heavy, but a goal of rust is safe macros. (And even if the macro-expanded code was invalid, the compiler should just report an error, not crash).

There are currently 207 open issues regarding ICE (Internal Compiler Error): https://github.com/rust-lang/rust/labels/I-ICE

steveklabnik16• 11 years ago

It's not perfect, but https://github.com/rust-lang/rust/issues?page=1&q=is%3Aissue... seems to indicate that we closed 81 issues tagged ICE between 1.0 and now. Not all of those made it into 1.1, bunches are in 1.2, and some of them are duplicates...

If you're running into ICEs or any other bug, please either open up a ticket or :+1: the ticket that exists. It helps to know which things are biting people more often.

arielby4• 11 years ago

1.2 is much less ICE-ey than 1.0 (the annoying "capacity overflow" macro ICE is no longer an ICE - it still prints "internal compiler error: unprintable span" but doesn't crash).

kibwen14• 11 years ago

It's definitely something to work on, but note that the Rust compiler tries hard to eagerly crash rather than possibly generate broken code. I'm very pleased at how few codegen-related bugs have been found since 1.0.

Jenny19752• 11 years ago

I've seen this complaint about the Rust compiler a number of times now, here and at other sites. Isn't one of the main selling points of Rust that it's supposed to make it much harder to write code that crashes? It is my understanding that the Rust compiler is mostly written in Rust. While maybe these ICEs aren't traditional segfaults that can be exploited, they're still unexpected crashes none the less! The software stops working without warning. If the best Rust experts around have so much trouble avoiding those kinds of crashes, then how is an average Rust user, or even a complete beginner like me, supposed to write Rust code that's any less susceptible to crashing?

steveklabnik16• 11 years ago

TL;DR: don't underestimate the power of technical debt.

Longer answer: The Rust compiler was written in Rust before the Rust language was even what it was today. As one particular example, the AST used to be garbage collected! And when you have a codebase that's 320,000 lines long, you don't update the entire codebase to the latest idiom, because if you did, you'd never actually ship the language.

Basically no other Rust program will ever have to contend with this kind of situation. As such, while I can sympathize with this line of argument, I don't think it's representative.

EDIT: I previously had 750,000 but it's actually 323,326 LOC as of right now. Whoops!

jroesch2• 11 years ago

Steve has hit this on the head, there are lots of places where we are using older abstractions that we have had to slowly refactor out of the compiler and like all other software development this won't be instantaneous. We definitely have some less then optimal code in the compiler from a design standpoint.

I think it is also important to recognize that all compilers have this problem and they all stabilize over time. It is an issue orthogonal of safety. These aren't segmentation faults or some kind of memory error but the compiler signaling an internal invariant was violated.

This can happen easily because we are writing a very large program that reads user input, interprets it, and tries to emit a program.

This can happen in multiple situations. One example is the compiler may have a logic bug that violates an internal invariant resulting in an ICE (instead of emitting incorrect code).

Other times it is as simple as the code we have been given is invalid and the error wasn't properly handled, and you end up seeing it in a non-user friendly way (as an ICE).

We are working hard to move the compiler to a more modern, robust design as soon as possible but even with a great design it will be an iterative process that we continue to do over the lifetime of the language, just like everyone else.

n_ham• 11 years ago

ICEs are not crashes due to memory unsafety, they are logical errors in the compiler code.

For example, here's about the worst rustc crash I've found: https://github.com/rust-lang/rust/issues/21946. It doesn't even give you an ICE, it terminates with a stack overflow.

So no, Rust cannot magically fix logic errors in large, complicated codebases, but that's not something that a complete beginner needs to worry about thankfully.

arielby4• 11 years ago

Most crashes are in type inference, associated types handling, and error recovery, which are very complicated things, especially in combination. We also basically rushed features in for 1.0.0 (1.1/1.2 should be much better in terms of these).

Aatch3• 11 years ago

Just to note that by far and away, the most common cause of an ICE is a missing error message. Others are related to unstable features, which isn't particularly fair, since they're unstable for a reason. The remainder tend to be caused by odd combinations of features we didn't think of (which more often than not tend to be constructions with simple, working equivalents), often they become a question of "do we want to support this or not".

Trust me, there are far worse things lurking in the compiler than a few improperly-handled error cases.

jrapdx3• 11 years ago

I'm glad to see Rust's progress. I'm still very interested in Rust, and incrementally learning the language. I do appreciate the documentation, IMO the developers have done a tremendous job in that respect.

One question though. When is Cargo going to be available on FreeBSD (and other BSD's)? I think these platforms are significant in the server space where Rust would be highly relevant. Having Rust usable there would likely augment uptake of the language.

steveklabnik16• 11 years ago

There are community builds to several of the BSDs, but we don't have CI running at the moment. We're working on ways to possibly provide infrastructure for community members to hook into to help make sure that the build is always green...

brson2• 11 years ago

I've heard progress on this front recently (it's mostly about the automation infrastructure), and I might expect official nightlies of both rustc and cargo for FreeBSD by the end of summer.

Don't hold me to that.

throw9827344• 11 years ago

Given Steve Klabnik's recent actions to suppress people who hold political opinions he does not like, I have a considerable amount of trepidation knowing he has a leadership position in the community sub-team.

worklogin2• 11 years ago

You'll get downvoted when you make seemingly opinionated statements with no context.

throw9827344• 11 years ago

Downvotes don't bother me. Being ostracized from the Rust community would, however, hence the throwaway.

kibwen14• 11 years ago

Would you like to cite a source?

throw9827344• 11 years ago

https://gist.github.com/steveklabnik/7cd3267a631c4847c34d

amongst more

It is especially troubling to have a community leader who equates speech with violence, even "hate" speech, which in that gist is clearly demonstrated to be completely subjective.

Certhas• 11 years ago

Freedom of expression does not entitle you to freedom from consequences of your expressions.

My freedom to dress as I want does not mean it is reasonable to demand to be treated equally when I am wearing a garbage bag to a meeting.

My freedom to not shower does not mean it is reasonable to demand to be treated equally when I stink up the place. Instead it is entirely reasonable to ask me to leave.

If a community manager asks people who express toxic opinions to leave, that is entirely reasonable. It's their job in fact. And make no mistake, the opinions of others you have linked to as being "suppressed" are toxic, so much so that in many countries [1] they would be considered illegal.

[1] And I am talking about countries that rank significantly higher than the US on the press freedom index:

https://en.wikipedia.org/wiki/Press_Freedom_Index#Rankings_a...

And outscore the US on the freedom house report on both civil liberties and political rights:

https://freedomhouse.org/report/freedom-world/2015/germany#....

https://freedomhouse.org/report/freedom-world/2015/united-st...

So please save your "Europeans don't care about freedom of expression" tropes.

worklogin2• 11 years ago

So I assume 1.x.x won't break features from 1.0? Is Rust using proper semantic versioning?

barosl• 11 years ago

Basically, no, it won't. Rust still reserves some rights to break the existing code if the found issue is considered to be "severe" (e.g. type system soundness issues), but those cases should be extremely low. In most cases workarounds will be introduced rather than breaking changes. More details at https://github.com/rust-lang/rfcs/blob/master/text/1122-lang...

Also note that the Rust team tests all the crates before making a (minor) breaking change to see the impact of the breakage to the ecosystem. (possibly "popular crates only", when the ecosystem grows huge in the future)

MetaCosm5• 11 years ago

Rust core team has taken the approach of breakage without major version increments being acceptable as long as they deem the breakage "minor" (based on crates.io and companies they have close relationships to).

kibwen14• 11 years ago

Qualifying with "close relationships to" is misleading, as every company using Rust is welcome to sign up to receive new versions of the compiler to run against their codebases to test for regressions. See the email address in my profile if you'd like to add your company to our list!

pcwalton2• 11 years ago

I don't want to relitigate this issue again, but that's not an accurate description of the policy. If you tell us that one of the changes in a point release broke your code, then appropriate action will be taken, regardless of who you are. No organization is given special privileges regarding breaking changes based on "close relationships" to the developers.

It is true that Rust, like all actively-maintained languages, can make changes that are theoretically breaking if all evidence strongly suggests that no code is actually going to break.

exacube2• 11 years ago

I'm happy things are moving along, but I would still like to see the documentation be more polished. I still don't know how to write a task queue (ie queue of closures) that executors can concurrently read and run from.

I don't feel like the docs empower me enough to write multi threaded code comfortably without the borrow checker spitting at me. Is it just me, or does anyone else feel this way?

steveklabnik16• 11 years ago

When you start documenting a language from scratch, you have to start at the beginning. A language is a huge project as well. The current book is about ~250 pages when rendered as a PDF. I've finally gotten to the point where the basics of almost everything have been documented, and am starting to move on to more intermediate style things.

In addition, we've only had a stable Rust for six weeks: there just hasn't been enough time to write more advanced things. Nobody wants to invest in stuff while things are still changing. As an example of this, I know there's an O'Reilly book coming out in the fall which covers advanced topics exclusively.

A basic task pool isn't too many lines of code: https://github.com/rust-lang/threadpool/blob/master/src/lib.... Hopefully that can help for that case, though obviously, this isn't just a comment about threadpools :)

andy_ppp• 11 years ago

I really love that you can (have?) put tests in the same file as the threadpool implementation. I think I will start doing this myself...

exacube2• 11 years ago

Thank you, you're doing a great job!!

Perceptes• 11 years ago

I don't want to make you rewrite this if you've already answered this elsewhere, but...

Could you provide some pointers about how to begin with contributing to the Rust documentation? What are the areas that need the most help or have received the most complaints/confused reactions? I actually like writing docs but I'm not sure where I'd begin. (And of course not super confident in my understanding of Rust in the first place since I'm still learning it myself. But I know a lot more than someone looking at it for the first time.)

kybernetikos• 11 years ago

I love the rust docs, but I do agree that the intermediate/advanced stuff is missing. I won't feel like I truly understand until I can implement a bunch of different datastructures, and it turns out that that is exactly the kind of code that throws up lifetime issues that as a beginning rust programmer I'm not really prepared to deal with.

I'd love a 'learn to write rust with datastructures' style intermediate tutorial.

JeffKilborn6• 11 years ago

While I find Rust interesting, how exactly will Rust deal with a 900lb gorilla that's about to get released from a cage?

Opensource Swift is only few months away and it already has a much bigger user base and is backed by the biggest company in tech. Rust & Swift share many common traits and kinda look alike as well.

Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do and is also positioned as a systems programming language? And Swift will also be a full-stack programming language and you will be able to program apps and backends with it.

I feel like Rust is about to get killed. And killed quickly.

andresmanz• 11 years ago

Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do and is also positioned as a systems programming language?

Well, honestly, that's just what I thought about C/C++ in comparison to some 'newer' programming languages like Go, Rust (and also Swift, maybe? I don't know enough about Swift yet).

Personally, I would only use Swift if there was an easy way to write cross-platform (mobile) software with it. It's as simple as that.

kibwen14• 11 years ago

Swift is an applications programming language where the runtime is non-optional (at least AFAICT) and memory is managed dynamically. It will be competing with .Net and Java, not with C and C++ (though, as ever, there are surely plenty of C++ projects that don't actually need C++'s level of control and could benefit from a rewrite in Swift).

Swift isn't going to penetrate to the bottom of the stack with pervasive reference counting. You'd either have to start managing memory manually (as per C) or implement a borrow checker (as per Rust), and even then your entire ecosystem is still going to use reference counting pervasively due to the language's defaults. One of the benefits of Rust defaulting to linear types and borrowed references is that it creates an entire package ecosystem where dynamic memory management is the exception, not the rule.

For the record, I think Swift is super fantastic as a language and I'm thrilled that it's going open-source. I think the two languages will work swimmingly together. :)

JeffKilborn6• 11 years ago

Swift is an applications programming language where the runtime is non-optional (at least AFAICT) and memory is managed dynamically.

No, it's optional if you don't need to interact with Obj-C frameworks (ie. Cocoa). And memory is not managed dynamically. Swift uses ARC.

Like I said, I just don't see Rust sticking around for long. Swift will suck all the developers out of it since you'll be able to actually get a job programming in Swift.

microtonal2• 11 years ago

It will be competing with .Net and Java, not with C and C++

I would formulate this a bit milder: many desktop applications are written in C++ and many system applications (e.g. UNIX command-line tools) could be written in Swift or Go. So, there are certainly areas where C++, Rust, Go, and Swift are or will be in competition.

Of course, if you require strong safety guarantees and the absence of a garbage collector, Rust is probably the only modern option.

comex• 11 years ago

Rust will deal with it by being swifter than Swift. Significantly so: Rust's unique feature is safety without requiring reference counting or GC for all pointers, which makes it a viable replacement for C and C++ in many situations where other languages would be considered unacceptable, and close enough to viable in others that future versions of Rust have a decent chance of making up the difference. Plenty of applications don't need that, and I look forward to competition between Rust and Swift in those arenas. But the enduring popularity of C++ in the face of the many newer, safer languages out there is testament that Rust's performance advantage is likely to be attractive to a lot of people.

JeffKilborn6• 11 years ago

Rust will deal with it by being swifter than Swift.

By how much? Will extra language codebase justify the speed increase (if any)?

Say you're developing some mobile app, why wouldn't you want to use a single unified codebase for front & backends instead of splitting it across Rust and Swift?

Manishearth9• 11 years ago

"systems programming" is a vague term which means different things for different people. Swift isn't systems by the definition used for Rust and C++.

Go has to contend with Swift. Rust does not.

(Also, there are concerns about Swift's usefulness on non-apple platforms if the libs aren't completely open source.)

JeffKilborn6• 11 years ago

Go has to contend with Swift. Rust does not.

During the WWDC 2015 opening keynote, Federighi explicitly stated that Swift's a "systems programming language" and they even say it in the documentation:

It is the first industrial-quality systems programming language that is as expressive and enjoyable as a scripting language.

https://developer.apple.com/library/ios/documentation/Swift/...

Rusky2• 11 years ago

Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do

Because Swift can't do everything Rust can do. It's missing its biggest features.

JeffKilborn6• 11 years ago

It's missing its biggest features.

Like what? Please do enlighten us.

mattdw• 11 years ago

Swift is still (and will always be) automatically reference counted. Rust lets you closer to the metal. Rust also has much stronger safety guarantees – it's pretty easy to write Swift crashers that would just never compile in Rust. That's a big deal for the kind of software Rust is pitching itself at.

They do feel like quite similar languages; I'd think of them as a complementary Systems/Applications pair.

lambda2• 11 years ago

I think that this is a good question, but poorly phrased; you assume in the phrasing that it's possible for the existence of one language to "kill" another.

I was somewhat disappointed when Apple shipped Swift; I feel like Rust has considerably more potential as a general purpose language, and it would be nice to have less dilution of effort in fairly similar space.

However, I don't think that the existence of Swift is an existential threat to Rust.

Swift will be able to do everything Rust can do and is also positioned as a systems programming language

Swift is an interesting language, with some good ideas, and in many ways easier to use for application programming than Rust; but I still, on balance, think that Rust is more interesting and versatile.

Swift is not really a systems programming language. You can't write a kernel in Swift, nor target embedded platforms, nor write a library that could be called from other languages like Ruby or Python (at least, without bringing in the whole runtime as well). It's closer to the space of Go, a more systems-y application language.

Furthermore, open source Swift does not mean you will be able to use the whole ecosystem on other platforms. I highly doubt that Apple will port Cocoa/Cocoa Touch to other platforms; so Swift on other platforms will likely only be viable for back-end code.

Objective-C has been open source for years, and until the introduction of Swift was the dominant language of choice for writing code on one of the most popular smartphone platforms, but Apple canned cross-platform OpenStep when they bought NeXT, and Objective-C has never made serious inroads on other platforms (I know exactly one person who writes production, server-side code in Objective-C on Linux).

So, I could see Swift becoming popular for writing backends for iPhone applications, but I can't imagine that it will make serious inroads in other spaces, unless Apple makes a dramatic change in strategy and starts shipping their UI libraries on other platforms as well.

Aatch3• 11 years ago

Eh, at the end of the day, they're different languages and are following different paths. Sure they're superficially similar, but that's not all to it.

Python and Ruby are pretty similar languages overall, but neither has "killed" the other. Why? Because despite their similiarities, they offer different things. I generally prefer to use Python over Ruby, no real reason for it, I just prefer the language. With Rust and Swift, there are some pretty major differences that can't be waved away as personal preference, Rust's borrow-checker isn't something Swift can integrate overnight (and wouldn't likely do) and Rust can't just grow some ARC equivalent (and almost certainly won't).

And hey, some of my favorite minor features for Rust are cribbed from Swift. Namely `if let` and `while let`. I'm not scared of a little competition, keeps us on our toes and makes sure we keep looking for ways to improve the language and ecosystem.

jpgvm• 11 years ago

While I generally agree with the sentiment it's worth mentioning that Rust preceded Swift and any similarities are the result of the Swift designers being influenced by Rust, not the other way around.

Rust also has the equivalent of ARC in the form of the Rc and Arc containers, Rc does reference counting without atomics, Arc with atomics (for when you need to do reference counting with thread safety).

bfrog• 11 years ago

Impressed daily by the amount of stuff being done to advance Rust as an incredibly useful language.

Rust 1.1 Stable, the Community Subteam, and RustCamp

Related Stories