erickt

In case you didn't see, I mentioned there is a way to do this right now:

https://news.ycombinator.com/item?id=13791945

One approach for this that I haven't really seen get used much that you can use a macro to get around this. In your comboluator.rs, just add this at the bottom of the file:

    #[cfg(test)]
    Mod tests {
        include!("comboluator_tests.rs");
    }

Then write your tests there. It allows you to write unit tests against private things, but also allows you to decouple the files to keep things cleaner.

Rust Core team member here. Out of the box, the Rust standard library only provides very basic networking support [1]. If you want to process requests in parallel, then yes you need to spawn an OS thread to process the request. We went with this model because we wanted to have the standard library be portable across all our supported platforms, and there isn't really a great standard for doing portable IO.

Instead, we're layering platform-specific code in external libraries. At the raw C-level bindings, we have libc [2] and winapi [3]. For higher level APIs, we've got Mio [4] which abstracts the system APIs, and now Tokio [5], which uses futures to simplify async operations.

We're just working our way up the stack. All of these are being developed by members of the various Rust teams, so they're as "official" as everything else we're doing.

[1]: https://doc.rust-lang.org/std/net/ [2]: https://crates.io/crates/libc [3]: https://crates.io/crates/winapi [4]: https://github.com/carllerche/mio [5]: https://tokio.rs/

Amazon Machine Instance [1]. Its the name Amazon uses for the virtual machine image running on AWS.

1: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html

Serve creator here. The core library 'serde' never actually required nightly. It was just the helper library 'serde_derive' which can automatically implement the serde traits that needed nightly. dtolnay has been doing a wonderful job getting us off nightly. We can't wait to finally get rid of using it.

For those not watching the compiler development traffic, macros 1.1 (which will enable things like #[derive(FromForm))]) could land in stable as soon as 6 weeks from now. We haven't really started thinking about a "macros 1.2" yet, so syntex will still have some use.

If you want to know more about our glorious macros 1.1 future, David Tolnay just have a great meetup talk all about this a few weeks ago:

https://air.mozilla.org/rust-meetup-december-2016-12-15/

Thanks for the heads up! We fixed that setting, so mail away.

That's a wonderful idea! I filed [1] to track it. I meant to do something like this, but it got lost in the shuffle prepping for the announcement. We'll publish one in a future blog post.

[1]: https://github.com/rust-community/underhanded.rs/issues/9

To add on to kibwen and Manishearth, another aspect is that one of the Rust Team's 2017 objectives [1] is to get our community more engaged in mentoring people and projects. We see the open ended aspect of this contest as a way to encourage people to help find and fix security bugs in our ecosystem. This should help to accelerate getting Rust even more production ready.

[1]: https://github.com/aturon/rfcs/blob/roadmap-2017/text/0000-r...

Thanks! I just pushed up a fix for that.

There's no real difference with what serde_codegen does, and what the compiler does for expanding macros. It's just expanding to source rather than raw AST.

The idea would be that these types would be put into a library (or just another module) that's used by the rest of the app. There wouldn't be duplication of these structures. It's not ideal, which is why we are working on stabilizing the compiler features to do away from codegen.

Serde code generation can be used on stable Rust, it just requires a bit of boilerplate code to setup: https://serde.rs/codegen-stable.html. Things will be much better once macros 1.1 gets stabilized.

Serde creator here. Steve's right, serde is fundamentally a generic protocol that implements serialization. I didn't use nom for serde_json (because it didn't exist at the time) but it's definitely possible to use nom and other parser generators to implement the serde protocol.

Rust uses the train release model which releases every 6 weeks [1]. It's definitely possible for someone to have an open PR for a year that's not in this list. I'm pretty sure this list is generated by running `git log --format='%aN' 1.12.0..1.13.0 | sort -u`.

[1]: https://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

In the Rust case, the crashes are either the stack being blown on recursion or panics when overflowing numbers.

Check out https://github.com/stepancheg/grpc-rust. Still in development.

One rust crate that seems fairly well along is https://github.com/stepancheg/grpc-rust. It claims it can communicate with the go client.

> By keeping platforms / package collections in userland we can get organic collections of stuff that make sense to bundle together. Imagine a "server platform", an "event loop platform", a "calculus platform", a "programming language platform". It would be detrimental to creativity to have all these collections live in the shadow of the "rust committee blessed platform".

That's exactly what we want to do. We don't have the domain expertise in many of these areas, but we want to enable those ecosystems to help develop their own platforms. It's one of our goals to make sure any infrastructure we develop for the "Rust Platform" is usable throughout our community.

Rust Core Team member here. I actually wrote up an RFC [1] that proposes adding JavaScript-like source map support to Rust, in order to improve our plugins-in-stable-code supports. Odds are we are going to reject it for now since I think we found a simpler way to achieve our goals, but we are certainly not opposed to adding support for it if there's demand.

[1]: https://github.com/rust-lang/rfcs/pull/1573

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

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

The drop flag is only generated for types that implement the `Drop` trait. Furthermore, there's work [0] that will shift the drop flag out of the value onto the call stack frame, and then even only in situations where the compiler cannot statically prove that that the type will be dropped or not. This should save a lot of memory, and potentially open up a whole host of optimizations.

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

That's a reasonable question! I put that on our list for the next survey: https://github.com/rust-community/team/issues/28#issuecommen...

Yeah, we iterated a bunch on this question, and I still don't think we have it quite right.

On the REPL side, we've had a few prototyped out [1] out over the years. We'd love something someday. What do you use for your scientific computing? We are also have some projects that are trying to ease using Rust with other languages ([2], [3]), so knowing what we should priorities would help.

[1]: https://github.com/murarth/rusti

[2]: https://github.com/rustbridge/helix

[3]: https://github.com/rustbridge/neon

Rust Community Team lead here.

It is fine if people don't consider themselves underrepresented, we just want to be proactive about discovering if people end up self selecting themselves out of our community because they don't feel welcome. Furthermore, we are starting some initiatives to focus growing a diverse group of participants (https://github.com/rust-community/RustBridge), and so we need some baselines to see if we are successful or not.

We did have a number of categories that people could select from. Our plan for next year is to identify groups from the free text for next year. We are tracking our improvement plans here: https://github.com/rust-community/team/issues/28

Rust Community Team here.

Yeah that was a mistake. We were trying to cut out redundant questions, but it would have been so easy just to split this into three answers. We might be able to split this out based on secondary information, but we didn't finish that analysis in time for this post. Maybe we can get it into a future post if we trust our result.

As I mentioned in my prior post, consider the percentages against the total number of responders, rather than across each demographic.

Rust Community Team member here.

This survey question allowed for people to describe themselves as they decided, and so people could select multiple choices if they wanted, as well as enter in free text. The percentages John used in this writeup should just be compared to the total number of people that replied, rather than across each of these demographics.

We have our meetups at Mozilla's San Francisco office, so we piggy back on their AV equipment. Unfortunately I don't know what that they use. However, there is an IRC channel irc://irc.mozilla.org/#airmozilla that I'm sure has some folks that could answer your questions.

Cool! I run this meetup. This video was taken at the Bay Area Rust meetup [1] last week. We also had two other speakers that also gave great talks:

Sean Griffin, on Diesel, a safe and extensible ORM [2]

Alan Jeffery, on Parsell, a streaming parser written for WebAssembly [3]

[1]: http://www.meetup.com/Rust-Bay-Area/events/219697075/

[2]: http://diesel.rs

[3]: https://github.com/asajeffrey/parsell