aturon

5 ms·

1.
by aturon 9y ago
> Trying to change it's role into "marketing/communication/project management tool" out of a sudden FWIW, this was part of the story from the beginning ( https://github.com/rust-lang/rfcs&#x2F
2.
by aturon 9y ago
Yes, it could! There aren't plans to do so yet, but it'd be worth spinning up a thread on internals about this.
3.
by aturon 9y ago
I think the domains of use will be quite different. Since Rust doesn't require a GC or other runtime support, we envision it being used in specific modules to provide a boost to code otherwise written in JS. See https://hack
4.
by aturon 9y ago
There are changes that require a new edition, particularly around new keywords. However, to be clear, editions are primarily a marketing/communication/project management tool. They give us a way to try to bring together a number
5.
by aturon 9y ago
Yeah, it's really hard to strike the right balance here, and we're constantly learning from experience. Sorry for the pain! I'll put a note on the core team agenda to undergo a round of public discussion around policies here,
6.
by aturon 9y ago
You can track the full status here: https://github.com/rust-lang/rust-roadmap/issues/17
7.
by aturon 9y ago
Yes, and that's definitely something we hope to address with the Blitz, both by beefing up top-level library docs, and through the Cookbook.
8.
The Rust Libs Blitz(blog.rust-lang.org)
433 points by aturon 9y ago|122 comments
9.
by aturon 9y ago
Rust's goal is to make it easier to write fast, reliable software. It's not just targeted at C/C++ folks. The Rust team often hears from people who have been pulling their hair out trying to get a particular component written
10.
The Minimally-Nice Open Source Software Maintainer(brson.github.io)
224 points by aturon 9y ago|58 comments
11.
Rust's language ergonomics initiative(blog.rust-lang.org)
506 points by aturon 10y ago|288 comments
12.
by aturon 10y ago
The new book will be published by NoStarch press!
13.
by aturon 10y ago
The key problem: in-memory data structures can embed ownership of system resources.
14.
by aturon 10y ago
The intent wasn't to say that we should be seeing big production use right this second , but rather to set out an overall "north star" for work on Rust. The investments in Rust today should be made with an eye toward driving
15.
Designing futures for Rust(aturon.github.io)
20 points by aturon 10y ago|0 comments
16.
by aturon 10y ago
Thanks for this comment! I actually totally agree with this perspective, and wish I'd used your suggested scale in the post.
17.
by aturon 10y ago
Panics are caught at the "task" level -- and there's usually one task per connection. They don't take down the entire server (since tasks are isolation boundaries). Right now, nothing happens with the panic after it&#x27
18.
by aturon 10y ago
Yep, same here -- at least for fasthttp. This is pretty far into microbenchmarking territory, so the differences among the top libraries likely don't matter much in practice. But I think the main point is pretty clear -- even with an e
19.
by aturon 10y ago
No, it's more related to the fact that Rust allows you to use traits in both a statically- and dynamically-dispatched way. You can read some more on the topic here: http://aturon.github.io/blog/2015/09/28
20.
by aturon 10y ago
Thanks for the thoughtful reply! I'm a little confused about the snippet you're pointing out. It's not actually using futures at all! In fact, that code is just part of setting up threads for the server. The reason it'
21.
by aturon 10y ago
This is an exciting upcoming feature in Rust, which you can read more about in a couple places: - http://aturon.github.io/blog/2015/09/28/impl-trait/ - https://github.com/rust-lang&#
22.
by aturon 10y ago
To be clear, the issue here isn't so much stack vs heap, as much as how many heap allocations are happening. In practice, you build up a really big combined future on the stack, which has all of the space needed for any state in its
23.
by aturon 10y ago
Yes -- the blog post didn't go into details about this, but Futures in general have an error type as well, and all the combinators know how to propagate errors correctly. (There's also a notion of "cancellation" for a fu
24.
Cargo: predictable dependency management(blog.rust-lang.org)
211 points by aturon 10y ago|142 comments
25.
Neon: Node plus Rust(calculist.org)
338 points by aturon 11y ago|69 comments
26.
by aturon 11y ago
Regarding performance, one thing to keep in mind is that all of the languages you mention use GC, which can help with cache locality issues. In Rust, of course, the situation is different. Gankro also addresses the common and useful idioms
27.
by aturon 11y ago
He does say "There are usually escape hatches, but at some limit you're just writing procedural code again."
28.
by aturon 11y ago
Academic. The Mozilla supervisors (i.e. me) were very enthusiastic about the Rustonomicon being the thesis. But I think that what Gankro's working on now is even more exciting! But I'll let him talk about that...
29.
by aturon 11y ago
There's been a lot of work on integrating with Windows's native MSVC toolchain. In 1.4 (which is in beta today) this is fully supported for 64-bit. You can get it here: https://static.rust-lang.org/dist/rust-b
30.
by aturon 11y ago
"According to the paper, it simply makes everywhere outside of data structure code a quiescent state" -- yes, from a per-thread point of view, but of course all the hard work is in detecting global quiescence.

More ›