Announcing Rust 1.15 | Hacker News Reader

Announcing Rust 1.15

blog.rust-lang.org

461 pointssteveklabnik90 comments

WHOA!

MSP430 support is HUGE. In case you don't know, that's a well-known very low-power microcontroller.

edit: this might be the only current platform that's <32 bits. I know there was some work on supporting the 8-bit AVR architecture, but MSP430 gets rust a lot closer to super-low-power applications.

There is work underway to create an LLVM backend for the Tensilica Xtensa, so Rust on the ESP32 / ESP8266 might soon be a reality!

Not the ESP8266 of course, but in the same vein you may be interested in effots to get Rust working on the RTL8710: https://polyfractal.com/post/rustl8710/

Do you know of any place one can track this work? Best reference google brought me was https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk/gcc/con... - but pretty hard to decipher current state from that...

Got that directly from an Espressif employee as inofficial info, but it has since been confirmed: https://twitter.com/buddy_casino/status/824299718104743938

So I guess its not in the open right now.

I wonder if its going to be specific to their chips, because the Xtensa architecture is highly configurable and so there isn't really a single target, but potentially many.

Probably not "soon", AVR took a really long time to get merged into LLVM, and that's a pre-requisite for Rust support.

I can't comment on timelines but I know someone has been working on AVR support for Rust.

Oh yeah the micro folks are definitely working on it, I meant that if work is just starting on the LLVM Xtensa backend, the Rust merge is nowhere near, and as example submitted that the AVR backend had taken a long time to be merged into LLVM and still needs to be finished & merged for Rust.

There is nothing that I could do with them, but I love their specs, specially when I think about my first MS-DOS computer.

So I imagine there would be lots of nice maker opportunities when that support comes out, not only for Rust, but for other LLVM frontends as well.

Totally, I like to think of them as this generations C64, though some might argue that the Arduino Uno or the Raspberry Pi deserve that title.

For example, the MSP430 was used in Square's early credit card readers to encrypt the mag stripe data.

Fun fact - the MSP430 ISA is based on the PDP-11 ISA.

Do you have a source I could read? This is super interesting.

Best independent source I can find is http://www.cpushack.com/CPU/cpu4.html#Sec4Part14.

I noticed whilst writing a verilog implementation - seeing the @PC+ relative modes for immediate data made me dig out my PDP-11 reference card.

The number of addressing modes has been halved, gaining a bit for register encoding, and the status register is now in the register file (R2), and R3 is used to generate various constants depending on mode.

Compare and contrast:

* https://en.wikipedia.org/wiki/PDP-11_architecture#CPU_regist... * https://en.wikipedia.org/wiki/TI_MSP430#MSP430_CPU

Awesome, thanks.

So was the Motorola 6800. I think it would be more surprising if they did everything from scratch rather than modelling it on some pre-existing work...

https://en.wikipedia.org/wiki/Motorola_6800

Yeah, in light of how hard AVR is to get over to LLVM it's really encouraging to see MSP430 support.

MSP430 has been in LLVM for a very, very long time though, since 2010 or so.

Is there a good solution for getting the code onto a chip? Last time I tried with the open source GCC stack, I eventually gave up and installed the painfully large (~1GB) IDE from TI.

I don't know if I would call it "good" but if you're willing to settle for "official" there is http://www.ti.com/tool/MSP430-FLASHER which will work with TI's own MSP-FET on all three major OSs.

Accepts a .hex so you can use whatever toolchain you want.

> I eventually gave up and installed the painfully large (~1GB) IDE from TI.

Is it still C++98 only?

This is pretty major. In anticipation of this release, I was able to remove all nightly feature flags from a smallish web backend which makes heavy use of type-driven codegen (serde and diesel). Really, truly, utterly fantastic to have stability promises for custom_derive. So excited!

!!!!!!

So excited!

Yes! We have a bunch of Rust apps at work, and just one of them was still on nightly, and now we can move that to stable, too. And we can get rid of a bunch of build.rs scripts elsewhere, which is always nice.

Just a small question, how did you find coding in rust for your web backend, did you encounter any major issues?

I've been doing a lot of web development in Rust over the past few weeks. Same as the parent poster; I was using beta so that I could have serde/diesel :)

I chose to go with straight-up tokio/hyper, rather than use existing frameworks. All of the current frameworks haven't integrated it yet, because it's only available on hyper master. (They're working on getting docs and such going before releasing the next version.) Here's my Cargo.toml: https://github.com/rust-lang-nursery/thanks/blob/master/Carg...

Overall, I feel that it's pretty great. It is still extremely new, though, so you have to be a bit comfortable with working on the bleeding edge. Also, because there's no big framework yet, it has a more... node-ish feel, in that you're doing a lot yourself and hooking up libraries, rather than using the conveniences of something like Rails. But that's not too bad; I wrote a little routing framework that also serves static content, it's about 150 lines. Another 12 or so to wrap up handlebars into something a bit nicer to use. And it uses so, so much less memory than my Rails apps do, and a six megabyte statically linked binary is a dream for deployment.

I was originally quite skeptical of all of this, but as the docs and libraries mature, I think it'll be pretty great. It won't be as easy as something like Rails, but it's much nicer than I originally assumed.

I wouldn't describe any of the issues I've had as major. There have been several papercuts (some of which are resolved by the current release), and I'm honestly not a huge fan of the iron library that I've used. I think in general I really like having Rust's nudges towards correctness for backend web code, but I need to try using something like tokio or rocket.rs instead of iron before I make too broad of a claim about how it is to develop. I think iron is good for several things, but the current amount of documentation (and several other factors) would prevent me from recommending using it in a new project right now.

I'm bullish on Rust for web development, but I think that stable custom_derive with 1.15 is just the start of improved ergonomics for it.

Which frameworks are you using for Web Development? Thanks I'm trying to get into Rust, gave it a chance a few weeks back and have been slowly working my way into it. I love it so far after ignoring it for so long.

The application is using iron, but I think at some point in the future I'd like to try building part of it in either raw tokio/hyper or using rocket.rs.

If you go for rocket I believe you'll be back on nightly, it uses some codegen that goes above and beyond what serde/diesel use in order to define routes the way it does.

That is correct, as well as another host of nightly-only features. It's gonna be a while before Rocket is stable.

Yep! I just haven't explored the options much since tokio matured more (I was at the hack night last fall for it and was very excited, but haven't tried it in the last couple of months) or since rocket was announced.

Thank you, that's one Framework I want to try!

I'm getting this: error: `#[derive]` for custom traits is not stable enough for use. It is deprecated and will be removed in v1.15 (see issue #29644)

Sounds like like you're using a crate that uses the old derive system. Where does the error originate?

I know only Serde and rustc-serialize.

Whole text of error: error: `#[derive]` for custom traits is not stable enough for use. It is deprecated and will be removed in v1.15 (see issue #29644) --> src/services/locations.rs:8:65 | 8 | #[derive(RustcDecodable, RustcEncodable, Clone, Default, Debug, Deserialize)] | ^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile -------------------------------------

Nothing helpful.

(If you indent text by two spaces, it will be formatted as code on HN.)

Are you using the macros 1.1 versions of those crates? In particular, serde_macros should now be serde_derive: https://github.com/serde-rs/serde/releases/tag/v0.8.10

thanks for help, I found.. way how to solve it (thanks to help in IRC). I'll take pause before publicly sharing my emotions about this update.

Congratulations! This seems an extremely important release, maybe even the most important since 1.0. Why? The lack of the trait deriving functionality on the stable release has kept libraries that are actually quite central to the ecosystem, such as Serde and Diesel, using the nightly compiler – until now.

The stabilisation of the trait deriving functionality is a small step for the compiler but a giant leap for the Rust ecosystem!

This is probably the most exciting release yet. Congratulations to the Rust team! I'm continually impressed by the inertia this project has.

I can not wait to see what everyone will build with custom derive now.

Like I said in another comment in this thread. I created a library that allows you to derive common traits with the new custom derive (e.g. `Add` and `From`). I just released a new version of it 30 minutes ago, with better docs and more derivable traits.

Any feedback is very much appreciated: https://github.com/JelteF/derive_more

Pretty sure you meant momentum, instead of inertia. Inertia is tied to mass and not remaining static, not speed ;)

Former physics person here. Inertia as a technical term is literally the mass or momentum. As a colloquial term I've also heard it used for both and in general to mean "inability to be slowed down", but it gets used more often to mean "inability to speed up". So it's ambiguous, but correct.

Yeah, but colloquially inertia "a tendency to do nothing or to remain unchanged."

This is true, but, in a physics context, an object that has velocity keeps that velocity when it remains unchanged (ie, like the GP said, it's literally momentum).

Like I said, it depends. Colloquially it is also "inability to slow down". The "inability to speed up" is more common, but it doesn't invalidate the first one.

I guess I meant it in the context of it has a lot of velocity and is continuing so.

But I agree :)

I've been hapilly awaiting this release. I have been heavily updating my rust first Rust library so it makes use of the new derive API, so that it could be used by stable Rust.

It adds derives for common traits such as Add and From: https://github.com/JelteF/derive_more. Any remarks/tips are very much appreciated.

You've got a very obvious typo in your example code, plus a couple of missing semicolons.

Fixed, that's what happens when you just want to be done with writing docs.

Woo, std::char::encode_utf8 is now stable, I can finally get rid of the nightly requirement for https://github.com/kballard/rust-lua!

Great to see the progress here. The one I'm really looking forward to is 'impl trait'.[0]

My understanding is this will allow returning trait implementations (such as Iterator) without resorting either to dynamic dispatch or leaking the concrete type.

[0] https://github.com/rust-lang/rust/issues/34511

I thought this was already supported for free standing functions? Or is that only in nightly

Only in nightly.

Can't say when it will hit stable, but "sooner rather than later" is a phrase I've heard.

thanks steve!

Rather keen on getting impl Trait myself. I won't have to return so many Vecs!

On https://thanks.rust-lang.org/rust/all-time

    Rank  Name  Commits
    1     bors  10401

That bors guy is such a monster! ;)

If you want details: http://ruststat.youknowone.org/

bors works very hard on every release. Bots are people too! :p

> Rust 1.15 sees an extremely eagerly-awaited feature land on stable

Hoped to read incremental recompilation there, what a tease ;)

Soon! Remember, you can already try it out on the nightly compiler. Filing any bugs that come up can help us ensure that it works well enough to stabilize.

Binary crates support across projects would also be nice. :)

Anyway congratulations on the work!

What do you mean by "across projects"?

(and thanks!)

I think they mean a nix-like binary cache for packages that get build multiple times (for different projects).

Ah; if that's true, it's being worked on.

Yep that is it.

Currently I tried to make use of the shared target directory configuration to see if it would help.

Awesome! I have been stuck on nightly for so many different things because of my dependency on serde. It's very nice to have this on stable now.

Stabilizing custom derive is a massive usability improvement given the large number of ever growing libraries taking advantage of it. This is probably the most exciting release to me besides the 1.0 and MIR integration releases.

This is amazing. Is Rust the best developer team out there? They move quickly and release features with a cadence I have not seen in other languages. I would love to hear more about other languages release this way.

Go has releases every 6 months.

Not a Rust expert by any means, this one piece of code from the example stuck out to me: `String::from("Ferris")`. What is the difference between that and `"Ferris"` on its own?

With "Ferris", these six bytes are in your program's read-only data section; the "Ferris" expression actually returns a reference to these six bytes (this reference is a "fat" pointer, which consists of a word with the address of the first byte and another word with their length, in this case 6).

The String::from("Ferris") method call returns a String. With the String, these six bytes are in the heap; internally, a String is similar to a Vec<u8> (heap-allocated vector of bytes).

String literals have the type "&'static str", that is, an immutable reference to a string that lives for the entire program. As a reference, it doesn't have ownership over its contents.

String is a growable, changable, string type. String::from will convert a &str to a String. It does have ownership over its contents.

String is needed here because when you read something at runtime, you're not going to have a literal, of course. But when you're creating something from a literal, you'll have to convert it to a String.

For a _much much_ more in-depth explanation that you don't need a _ton_ of Rust knowledge to understand, see http://rust-lang.github.io/book/ch04-00-understanding-owners... (and its three sub-sections)

It's like in C. "Ferris" is a pointer (and length, in Rust) into the binary's static storage segment.

String::from("Ferris") creates a pointer to a string on the heap with the contents "Ferris".

The difference is that in C this distinction is implicit, so you can accidentally try to modify the string in static storage, which is undefined behaviour, whereas Rust treats these distinct things as distinct types.

This makes C's approach sound worse than it really is: in practice you'll either get a compiler warning or a segfault, not the potential nose-demons typically associated with undefined behavior. C also gives you a type-level way to track static strings (the const qualifier) though it isn't as strictly enforced.

It's like `const char[]` vs `std::string`.

As someone who came from C++ to Rust, this analogy was most helpful for me. I can understand why it seems a little odd to someone without a systems background, though.

The literal `"Ferris"` is a slice, i.e. a (const) pointer, which in this case will even point a part of to the data section of the binary. The String version is dynamically allocated and can be changed, can grow, etc.

String::from("Ferris") returns a String object (https://doc.rust-lang.org/std/string/struct.String.html) whereas "Ferris" on its own is a primative "str" (https://doc.rust-lang.org/std/primitive.str.html)

This is the real Rust 1.0 for me. So excited!! For anyone that has been hesitating to try Rust, I wholeheartedly recommend that you dive in now.

Looking forward to trying this out on my Rust learning project[1]. It should be nicer to use serde without the extra code generation step.

1. https://github.com/rjosephwright/saytshen

Installing out of distro Rust on Linux in custom location became rather difficult, and it's not a well documented process. Previous installer was much neater, since it was installing Rust globally.

So these procedural macros, would it be fair to characterise them as compile time reflection? It seems like these get used in the same way reflection does in other languages.

In some sense, yes.

Yay, custom derive is stable.

Nice, I like the look of custom derive.

I've been using x.py/rustbuild since just after it was committed and it's been a pretty good experience so far.

Great to see custom derive landing in stable. Big thanks to Mozilla and everyone else working on improving Rust!

So it seems cross-compiling is supported now?

It has been for a very long time.

Have you filed a bug?

Reply on news.ycombinator.com