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.
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.
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.
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.
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...
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.
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!
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.
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.
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.
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
-------------------------------------
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!
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.