erickt

But only if you use the `slice.unchecked_get`[1] method, otherwise you still get bounds checking in an unsafe block.

[1]: http://doc.rust-lang.org/std/primitive.slice.html#method.get...

If anyone is interested in hearing from the creator, Sean Griffin will be talking about Diesel at the next Bay Area Rust Meetup on February 18th [1], which will be live streamed and eventually archived on Air Mozilla [2]:

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

[2]: https://air.mozilla.org/bay-area-rust-meetup-february-2016/

Wonderful! Are you able to say which company you deployed this in, and if you've run into any trouble? And by DLL, was this in Windows? I can't recall if we've heard of any Windows users putting rust into production yet. We're quite interested in making sure our production users don't run into any problems. If you'd prefer to not speak in public, you could reach out to our private channel, community-team@rust-lang.org. Best of luck!

Yes there is. That's the wasm2asm project Alon mentioned in the post.

Last I worked on llvm-c, it was supposed to stay backwards compatible. They do add new functionality but the old API should still work until llvm 4. For rust, while we have been broken by bad code we generated and llvm bugs, I can't recall if the API ever was changed out from under us.

Don't forget we kinda sorta have byte characters and strings a la `b'x'` and `b"foo"`, which are really just simpler ways of expressing byte slices. Unfortunately they lack string specific methods until we get specialization (fingers crossed).

Longtime Rust developer here. You definitely made the right choice, it would have been a pretty big risk to bet a startup on rust back in 2014 if you didn't have the freedom to keep up to date with the breaking changes. Crazy people like me had a lot fun seeing the language evolve in realtime, but it certainly would have been stress-inducing if I was betting my livelihood on it.

Now that we're stable, please let us know if you plan on experimenting with Rust. We'd love to hear how it goes (I run the SF meetups and am always looking for speakers), and what we can do to help. One of our short/medium term goals is to make some high quality bindings to other languages, so that projects like yours could slowly introduce Rust where it makes sense.

It doesn't quite yet. By default it errors on unknown fields, and my plan is to add an annotation to ignore it instead. Not quite sure if I got the default behavior correct though. I'm considering flipping it.

Thanks! I need to get back into writing on it.

I just pushed up a rust pull parser version here: https://github.com/kostya/benchmarks/pull/54. Is that what you were thinking of?

I wrote serde_json, and wrote the rust benchmark here a few months ago. Interestingly when I wrote this benchmark, I had my implementation as equivalent to RapidJSON on my Mac, but for some reason Kostya couldn't replicate it:

Ohttps://github.com/kostya/benchmarks/pull/44

I'm guessing gcc just has some optimizations llvm doesn't.

Rust does have some experimental SIMD, but I'm not using it yet because I want the serde libraries to be safe to use on byte streams, and reading 16 bytes ahead could block if at the end of a socket stream. Hopefully we will get specialization soon, which would let me use SIMD when I know I have at least X bytes in a buffer.

I love these articles, thanks! I can't wait for rust to get more involved in this space. How do you plan on doing error handling in timely? Do you expect it to be more along the lines of MPI, where you restart from the last snapshot, or MapReduce/Spark, where lost work is transparently recomputed?

You're not accounting for fractional reserve banking, where the banks only need to keep a certain amount of deposits on hand, and can loan the rest out to other people. For example, you deposit $100 into a bank. They keep, say, $20, and loan Erin $80 out to another person. This essentially creates money out of thin air since you still legally own that $100 dollars, and but now Erin has $80, bringing the total amount of money in our little economy to $180.

This all works fine assuming you don't try to withdraw all $100 since they only have $20 on hand. Nor would it be good if Erin defaults on her debt. Or the bank collapses. This is what FDIC is there to protect, where the government will create new money in case things collapse.

There's a fierce battle between the honorable Vim-ers (https://github.com/rust-lang/rust.vim), and those scoundrel Emac-ians (https://github.com/rust-lang/rust-mode). Work is ongoing to have better support for code completion (https://github.com/phildawes/racer), and I heard that there has been some preliminary work to get support into Visual Studio and JetBrains, but I'm not sure how far along that is yet.

We're still pretty confident that Rust will be able to support a high quality green threading library and other M:N concurrency libraries without needing to be integrated into the language itself. All the type magic that we do to pass data between threads should work quite well for a green threading library. We already have a couple projects experimenting with this [1], [2], [3]. Servo also has a pretty nifty work-stealing queue [4] that is yet another abstraction for easily sharing data between threads.

1: https://github.com/rustcc/coroutine-rs 2: https://github.com/zonyitoo/simplesched 3: https://github.com/dpc/mioco 4: https://github.com/servo/servo/blob/c76720d67c0d04f6d77c138c...

Serde (https://github.com/serde-rs/serde) is my baby, so let me know if you need any help with it. In a sense serde is a compile time reflection library. It's designed to recursively walk through a structure while calling a function on each component. While the primary purpose is to do serialization, it could be used to do other reflection-y things, like build a UI widget for arbitrary structures. To really support full reflection though serde would have to be modified to support in-place modification. It wouldn't trivial, but it's certainly not impossible.

No it's not a stupid question. libc (or CRT on windows) really is the library that exposes all the user space system libraries. It contains the functions to do IO, sockets, threads, and etc. So we use it to expose that functionality to rust users.

Now there are some languages, namely Go, that skip libc and just implement directly against the syscall interface. Go has the advantage of being able to draw from Google's vast experience interacting deep within the system, so it was comparatively cheap for them to do this.

For rust, it never really felt like it was worth the effort for the benefit we'd get out of it. It was more important to get the language done.

Zappos built their brand on high quality customer service: http://www.businessinsider.com/zappos-customer-service-crm-2...

Years ago we had pure functions that have since been replaced with our current function model. I'm betting that we are still reserving "pure" from that time. I haven't heard of anyone proposing to use it for something, so should probably unreserve it.

We are not quite ready to support users of libsyntax and librustc as we are very serious about keeping our stable api stable, and freezing those apis would really impact the future development of the compiler, so it will not be exposed in rust 1.0. We want to eventually get something for this purpose though.

It is very probable that a sufficiently smart optimizer could see the assertion was always true and delete it. Then see no one reads "a" and delete it as well. In certain circumstances this can cause a secret to be leaked in, say a register, making our safe function unsafe. You need to be very careful writing secure code, and probably need to go down to the level of writing assembly to be sure the optimizer isn't turning your safe code into unsafe code.

We actually have an interesting project in rust where someone is writing a syntax extension to take rust like code and generate assembly [0]. It's probably unsafe to use right now but if sufficiently well implemented it could be the foundation of a lot of interesting cryptography work.

[0]: https://github.com/klutzy/nadeko

We had a Bay Area Rust meetup [0] all about cryptography back in December (here[1] is a video if you want to watch the event). One of the subjects of that talk was about a project tars[2] that tries to provide for a secure buffer for keys that is protected against it being leaked using a variety of techniques. It hasn't yet been analyzed, so of course you shouldn't actually trust it yet.

There's a lot of interest in our community to build out a solid foundation and verified foundation of cryptography primitives. If you're interested in helping out, hop in the #rust-crypto channel on irc.mozilla.org.

[0]: http://www.meetup.com/Rust-Bay-Area/events/210632582/

[1]: https://air.mozilla.org/bay-area-rust-meetup-december-2014/

[2]: https://github.com/seb-m/tars

Google supposedly has implemented something similar called user-level threads, which they talked about at the 2013 Linux Plumbers Conference. If I recall the video correctly, they talk about plans to open source it, but as far as I know there hasn't been much movement in that space yet:

http://www.linuxplumbersconf.org/2013/ocw/proposals/1653 https://www.youtube.com/watch?v=KXuZi9aeGTw

If anyone is interested in rust and cryptography, we have a meetup this Thursday in San Francsico focused on it:

http://www.meetup.com/Rust-Bay-Area/events/210632582/

We are currently full, but we are live streaming it on:

https://air.mozilla.org/bay-area-rust-meetup-december-2014/

We also have about 10-15 people unrsvp the day-of, so there is a chance spots for free up between now and then.

There are two things going on in Servo that are causing it to use a lot of unsafe { ... } blocks. First, it still depends on a large amount of large c libraries, like SpiderMonkey for JavaScript. We automatically treat c foreign functions as unsafe as we can't protect against them doing unsafe things. Second, the DOM is very much built on an object oriented class hierarchy, and we in rust have put off figuring out how we can support that until after 1.0. So Servo uses unsafe code to hack around our temporary lack of support for that feature. So while there may be a lot of unsafe blocks, it should only be for the short/medium term.

To be fair, we in the rust community are telling people to wait for 1.0 unless they are okay with constantly updating their code as we clean up the language for our first release. It's fair though to speak about momentum. Comparing Go's contributor list (https://golang.org/CONTRIBUTORS) with ours (https://github.com/rust-lang/rust/blob/master/AUTHORS.txt) has us with about 100 more than Go. I'm not saying our community is better than Go's or anything, but I'm certainly impressed a new language has been able to gain so much interest so quickly. When I first started contributing a couple years ago, we had like 15 people in our irc channel. Now we got over 500.

That's a good point. I filed https://github.com/rust-lang/rust/issues/19168 to get it fixed.

That wouldn't be safe, because then they would have access to your private key and impersonate you. Having you (indirectly via their script) generate the key and submit the public key for signing means your private key never leaves the premises.

Avro is self describing [1]. It embeds the schema of whatever it is describing inside the format so a reader can handle arbitrary avro serialized files. It is also cross platform. I'm not sure if avro maps can cache keys, but if you use a record type the keys are not stored in the data. As far as I know though, avro cannot handle custom types, so those will need customized importers and exporters.

[1]: http://avro.apache.org/docs/current/

If anyone is interested in a meetup about Rust's growing gaming infrastructure, we are having a meetup on 6/26 (http://www.meetup.com/Rust-Bay-Area/events/171111672/) and a hackathon on 6/28 (http://www.meetup.com/Rust-Bay-Area/events/183377112/). If you can't make it in person, we will be streaming the meetup over https://air.mozilla.org, where you can watch it live.

It is coming soon. Firefox Nightly has it as an option, and according to this it's supposed to be an option in Firefox 30. I'm not sure when it will be turned on by default though:

https://wiki.mozilla.org/Electrolysis