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.
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.
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.
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:
Accepts a .hex so you can use whatever toolchain you want.
Is it still C++98 only?
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'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.
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)
8 | #[derive(RustcDecodable, RustcEncodable, Clone, Default, Debug, Deserialize)]
error: aborting due to previous error
error: Could not compile
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
The stabilisation of the trait deriving functionality is a small step for the compiler but a giant leap for the Rust ecosystem!
I can not wait to see what everyone will build with custom derive now.
Any feedback is very much appreciated: https://github.com/JelteF/derive_more
But I agree :)
It adds derives for common traits such as Add and From: https://github.com/JelteF/derive_more. Any remarks/tips are very much appreciated.
My understanding is this will allow returning trait implementations (such as Iterator) without resorting either to dynamic dispatch or leaking the concrete type.
Can't say when it will hit stable, but "sooner rather than later" is a phrase I've heard.
Rank Name Commits
1 bors 10401
Hoped to read incremental recompilation there, what a tease ;)
Anyway congratulations on the work!
Currently I tried to make use of the shared target directory configuration to see if it would help.
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 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)
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.
I've been using x.py/rustbuild since just after it was committed and it's been a pretty good experience so far.