Recent submissions

Comment · 2 years 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 specify the Send or Local variant.
Comment · 2 years 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 use it all the time. Likewise, static inlining can bite you in deeply nested cases and I've heard of this happening too.

The future we're working toward is for this to be a decision you can make locally without introducing compatibility hazards or having to change a bunch of code. Ideally, one day you can even ask the compiler to alert you to potential performance hazards or make reasonable default choices for you...

Comment · 5 years ago
Comment · 5 years 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 of deciding clear limits on free speech would be great, but the absence of one doesn’t mean the platforms should sit on their hands and do nothing while the world burns.

Comment · 6 years 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 high-profile holdout I know of) now works on stable as of earlier this year.

As for maintenance, as with all library ecosystems it’s a mix. The most popular crates tend to be the most well-maintained in my experience. This is definitely something to consider when taking on new dependencies.

Comment · 6 years 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 and time. Short of an actual federated system, a self hosted option OR just markdown export / backup of an entire database would completely alleviate that for me.
Comment · 6 years 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.
Comment · 6 years ago
Comment · 6 years 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.
Comment · 7 years ago
Just to clarify for those following along, Rust async code does not use green threads and doesn't require a stack per task.
Comment · 7 years ago
I didn’t know about this.. I’d love to read that book :)
Comment · 7 years 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 execute independently. (To be clear, if you are awaiting something from within your task, it is not a separate task.) For spawning new tasks, there's a standard API[1], which doesn't include any executor-specific stuff like priority. You'll have to decide what you want the default behavior to be when someone calls this; for example, a newly spawned task can inherit the priority of its parent.

To get more sophisticated, you could even have a "spawn policy" field for every task that your first-party code knows how to set. Any new task spawned from within that task inherits priority according to that task's policy. The executor implementation decides what tasks look like and how to spawn new ones, so you can go crazy. (Not that you necessarily should, that is.)

To summarize the Rust approach, I'd say you have 3 main extension points:

1. The executor, which controls the spawning, prioritization, and execution of tasks

2. Custom combinators (like join_all[2]), which allow you to customize the implementation of poll[3] and, say, customize how sub-futures are prioritized (This is at the same level as await, so per-Future, not per-Task.)

3. Leaf futures (like the ones that read or write to a socket). These are responsible for working with the executor to schedule their future wake-ups (with, say, epoll or some other mechanism). For more on this, see [4].

[1]: https://doc.rust-lang.org/1.28.0/std/task/trait.Executor.htm...

[2]: https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-a...

[3]: https://doc.rust-lang.org/1.28.0/std/future/trait.Future.htm...

[4]: https://boats.gitlab.io/blog/post/wakers-i/

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton