Hacker News Reader

Comment by rubber_duck | Hacker News Reader

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)

View on HN

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