Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
tmandry
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
12 ms
·
1.
▲
by
tmandry
3y ago
My hope is that you can use Send variants generated with the macro to reduce the typing, in cases where you need that. In the future with return type bounds, middleware would just use the local variants and only the end user needs to specif
2.
▲
by
tmandry
3y ago
I don't have numbers handy, but I can say with confidence that the answer to both questions is "yes". It depends on the use case. Boxing is a useful tool and in many cases the overhead is minimal, but you don't want to u
3.
▲
Contexts and Capabilities in Rust
(tmandry.gitlab.io)
43 points
by
tmandry
5y ago
|
4 comments
4.
▲
by
tmandry
5y ago
Study design: Tracks 200 people over one year and measures a suite of biomarkers at the beginning, 6 months, and 12 months. Participants are randomly assigned to one of four dosages or a placebo. Double blind. The study hopes to find an opt
5.
▲
by
tmandry
6y ago
> Otherwise we are always dependent on the good will of the companies without democratic control. Yes, but that’s already true without this action, which doesn’t make them any more or less democratically controlled. A more democratic way
6.
▲
by
tmandry
6y ago
Most libraries don’t target nightly anymore. It certainly used to be the case that nightly had all the cool features everyone wanted, but almost all features that popular crates depended on have now been stabilized. Even Rocket (the most
7.
▲
by
tmandry
6y ago
You seem to be hitting the nail on the head with regard to seamless UX. I’d gladly pay to support something like this, but the lock-in / “what happens if you go away” problem is real and holds me back from investing all my knowledge an
8.
▲
by
tmandry
6y ago
“mild” symptoms has been used to mean flu-like, i.e., not something I would call mild and certainly not the same as asympotomatic, but not requiring hospitalization.
9.
▲
by
tmandry
6y ago
I’m not sure I would call this a memory model per se, but here’s how async tasks are laid out in memory. http://tmandry.gitlab.io/blog/posts/optimizing-await-1/
10.
▲
by
tmandry
7y ago
Only models sold after a certain date support this, and you have to go through a menu sequence to enable HDMI 2. It’s documented on their website.
11.
▲
by
tmandry
7y ago
Just to clarify for those following along, Rust async code does not use green threads and doesn't require a stack per task.
12.
▲
Rust optimizes async/await: Program analysis
(tmandry.gitlab.io)
4 points
by
tmandry
7y ago
|
0 comments
13.
▲
Rust compiles async/await: Program analysis
(tmandry.gitlab.io)
6 points
by
tmandry
7y ago
|
0 comments
14.
▲
by
tmandry
7y ago
I didn’t know about this.. I’d love to read that book :)
15.
▲
by
tmandry
7y ago
The concept of a pseudo-thread you're referring to is a task. A task contains a whole tree of futures awaiting other futures. So no manual propagation is necessary. Of course, it's possible for tasks to spawn other tasks that ex
16.
▲
by
tmandry
7y ago
Futures were developed outside Rust core, in a third-party library, before being brought into the language. Working with them in combinator form definitely was less ergonomic, but async/await fixes that.
17.
▲
by
tmandry
7y ago
Disclaimer: I'm not an expert on the proposal, but have looked at it some, and can offer my impressions here. (Sorry, this got a bit long!) The C++ proposal definitely attacks the problem from a different angle than Rust. One somewhat
18.
▲
by
tmandry
7y ago
It's the same underlying mechanism for generators as for futures: they are stackless coroutines. All the space they need for local variables is allocated ahead of time. In my experience, the fact that they are stackless is not at all
19.
▲
by
tmandry
7y ago
I'd agree with this, and emphasize the point that this stuff is really tricky to get right without GC. Fighting the borrow checker is somewhat expected when you're dealing with this level of inherent complexity in your memory ma
20.
▲
by
tmandry
7y ago
Generators do nothing unless you call their resume() method. resume moves the generator from the last state it was in to the next yield (or return). Internally, when the code hits a yield, it's happening inside the resume method. yield
21.
▲
by
tmandry
7y ago
This is a great quote, and one that I missed while first writing the post! I've added it now.
22.
▲
by
tmandry
7y ago
Most languages allocate every future (and sub-future, and sub-sub-future) separately on the heap. This leads to some overhead, allocating and deallocating space to store our task state. In Rust, you can "inline" an entire chain of
23.
▲
by
tmandry
7y ago
Not necessarily. They're an implementation detail of the compiler, and aren't fully baked yet to boot. But there's plenty of reason to want generators, including the fact that they let you build streams. And the fact that asy
24.
▲
by
tmandry
7y ago
That's what I get for publishing late at night. Fixed, thanks!
25.
▲
How Rust optimizes async/await
(tmandry.gitlab.io)
351 points
by
tmandry
7y ago
|
123 comments
26.
▲
Being an advocate of your code
(blog.codinghorror.com)
1 points
by
tmandry
8y ago
|
0 comments
27.
▲
Fukushima’s nuclear signature found in California wine
(technologyreview.com)
399 points
by
tmandry
8y ago
|
153 comments
28.
▲
by
tmandry
8y ago
Just to clarify for others, Actix is a more general actor-based programming framework. Actix-web is a nice little web server framework built on top of that, which you could integrate with other Actix components. From looking at the two, Act
29.
▲
by
tmandry
8y ago
Rust is working on exactly this, targeting stabilization later this year: http://aturon.github.io/2018/04/24/async-borrowing/
30.
▲
Show HN: Build with Bazel from Visual Studio
(github.com)
3 points
by
tmandry
8y ago
|
0 comments
More ›