Hacker News Reader

Comment by rustc | Hacker News Reader

How's the MIR stuff going on? Is there an ETA on when MIR will land in beta/stable? Will the incremental compilation work start after that?

View on HN

MIR is still going well. To be clear, it's already landed, and has been working, it's just not the default yet. There's a PR https://github.com/rust-lang/rust/pull/34096 and there are currently three blockers: https://github.com/rust-lang/rust/milestone/29

Incremental compilation has been worked on while MIR development was happening, so it won't start, it's already in-progress. :)

Does this imply we should see single-crate compile times improve?

Which part?

With MIR, yes, the idea is that compile time should improve. One of those tracking bugs is to make sure that it doesn't regress before turning it on by default.

With incremental compilation, you should see compiles after the first improve; you'll need to compile a lot less code for each change. Right now, the entire crate is recompiled, but afterwards, just the portion that changed will need to be.

My understanding of compilers is somewhat limited, but I'm curious how the compiler can detect "just the portion that changed", given that Rust does heavy inlining.

There's some information about the design in the RFC text:

https://github.com/rust-lang/rfcs/blob/master/text/1298-incr...

AFAICT, the idea is to track and hash items like function signatures and bodies, map them to the object files produced by LLVM, and to recompile them when the hashes change.

Indeed, inlining is an obstacle for such fine-grained incremental recompilation as Rust envisions. However, when compiling in debug mode (which is the default) Rust (or rather LLVM) does not do all that much inlining, and considering that people compile in debug mode much more often than they compile in release mode this should present a large time savings to the average developer use case.

(Note also that MIR should generate somewhat faster debug binaries than current trans (by virtue of doing "obvious" optimizations in the frontend, rather than asking LLVM to chew on it), so if there are people out there who currently make release builds during development because their debug builds are too doggone slow, then this should help alleviate that.)

Also is there an ETA on syntax extensions being stabilized ? This and incremental compilation are my personal milestones that Rust (core language/compiler) went over the initial growing pains (lack of tooling I can deal with)

There is no ETA yet, but it is being worked on.

Out of curiosity, do you want general syntax extensions, or is it stuff like Serde/Diesel, specifically?

For a project I have in mind I'm looking for a way to reflect on the code and generate both serialization and RPC API from code based on conventions/traits/annotations - I guess I could do it with syntex but that looks hacky and slow (two passes). In general I'm not in a rush to start that project and these two things seem like the last big missing peaces of the compiler/language - I'm waiting on those before I start pitching rust to my coworkers.

Cool, thanks. We have some ideas for a solution to these kinds of cases that might come a lot sooner than general syntax extensions, but it's still shaking out.

Any discuss threads or RFCs I could look at? I'm also interested in those use cases.

There are two that I know of off the top of my head:

Code generators/source maps: https://github.com/rust-lang/rfcs/pull/1573

Procedural macros: https://github.com/rust-lang/rfcs/pull/1566

Ah, okay. I was aware of those, and was thinking maybe people were talking about compile-time introspection rather than code generation.

Serde [1] creator here. I think serde can do this out of the box. Is it missing something you need?

[1]: https://github.com/serde-rs/serde

Looking at it - it seems like a serialization framework ala .NET ISerializable, while that's a part of what I need I also need a way to dump code metadata out to some file (like JSON) at compile time and then use that data to auto generate the client API to access the data (but that would be done outside of rust). And since I can constrain my models serialization part wouldn't benefit much from a framework - most of the complexity would be in extracting the metadata and validating model constraints. I'm not sure if Serde helps with those I can't tell from github ?

(also the reference links in the readme are broken, eg. http://serde-rs.github.io/serde/serde/serde/ser/trait.Serial... - seems like one too many /serde)

Not sure if this fits the bill, but you can do code generation at compile time with cargo using build scripts: http://doc.crates.io/build-script.html

I have an as-yet-unpublished crate that takes a JSON API spec and generates an API client for it (in rust) at compile time using this method.

Thanks for finding that bug!

In a way, Serde itself is all about extracting the metadata of a type and handling validation issues. However this is metadata is currently not exposed to end users. It's something I've thought about doing, but I haven't had a driving use case to help come up with a proper API for it. I don't think it'd be that hard to implement once we actually have a clear idea on what we want.

The code Serde generates though typically optimizes down into nearly the same code as a hand written serializer and deserializer. On my laptop, serde_json [1] serializes a particular micro-benchmark [2] that serializes as fast as a hand rolled serializer (416MB/s vs 414MB/s). In comparison, rapidjson serializes the same structure in 432MB/s. I didn't write a hand written deserializer, but serde_json is comparable to rapidjson (193MB/s vs 182MB/s).

So it may be fast enough that you might be able to just implement whatever you want by just using Serde directly without having to generate parsers.

[1]: https://github.com/serde-rs/json

[2]: https://github.com/serde-rs/json/blob/master/json_tests/benc...

[3]: https://github.com/erickt/rust-serialization-benchmarks/tree...

For me, quickcheck! It's possible to live with a quickcheck feature that only works on nightly but it would be nicer if it were integrated like cargo test; cargo quickcheck.

Reply on news.ycombinator.com