Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
Pauan
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
Pauan
3y ago
Threads cannot scale at all, because you're limited to the number of threads (which is usually quite small). Async code can scale essentially infinitely, because it can multiplex thousands of Futures onto a single thread. And you can h
2.
▲
by
Pauan
3y ago
> Async traits come to mind immediately, I agree that being able to use `async` inside of traits would be very useful, and hopefully we will get it soon. > generally needing more capability to existentially quantify Future types witho
3.
▲
by
Pauan
3y ago
> So you’re stuck choosing a single CPU or having to write send and sync everywhere. There’s a lot of use cases where you would want a thread-per-core model like Glommio to take advantage of multiple cores while still being able to writ
4.
▲
by
Pauan
3y ago
Even the costs you are talking about are a one-time cost to read the documentation and learn the abstraction. And the long-term benefits of the abstraction are far greater than the one-time costs. That's why we create abstractions, bec
5.
▲
by
Pauan
3y ago
I never said that ALL abstractions in Rust are zero-cost, though the vast majority of them are, and you actually have to explicitly go out of your way to use non-zero-cost abstractions.
6.
▲
by
Pauan
3y ago
I'm curious what things you consider to be half-baked about Rust async. I've used Rust async extensively for years, and I consider it to be the cleanest and most well designed async system out of any language (and yes, I have us
7.
▲
by
Pauan
3y ago
I am very aware of the definition of zero-cost. We're talking about the comparison between using an abstraction vs not using an abstraction. When I said "doesn't have a runtime cost", I meant "the abstraction doesn&
8.
▲
by
Pauan
3y ago
The whole point of an abstraction is to remove complexity for the user. So I assume you mean "implementation complexity" but that's irrelevant, because that cost only needs to be paid once, and then you put the abstraction in
9.
▲
by
Pauan
3y ago
Ah, my mistake.
10.
▲
by
Pauan
3y ago
Every executor (including tokio) supports spawning Futures that aren't Send: https://docs.rs/tokio/1.32.0/tokio/task/fn.spawn_local.html There is a lot of misinformation in this thread, with people
11.
▲
by
Pauan
3y ago
No, tokio does not require your Futures to be thread-safe. Every executor (including tokio) provides a `spawn_local` function that spawns Futures on the current thread, so they don't need to be Send: https://docs.rs/tok
12.
▲
by
Pauan
3y ago
Yes, you can do that. You can use `block_on` to convert an async Future into a synchronous blocking call. So it is entirely possible to convert from the async world back into the sync world.
13.
▲
by
Pauan
3y ago
If you choose to use Mutex, that's on you. Rust gives you channels (both synchronous blocking channels and async channels), and they work great, there is nothing stopping you from using them.
14.
▲
by
Pauan
3y ago
Rust embraces abstractions because Rust abstractions are zero-cost. So you can liberally create them and use them without paying a runtime cost. That makes abstractions far more useful and powerful, since you never need to do a cost-benefit
15.
▲
by
Pauan
3y ago
Rust has had OS channels since forever, and async channels for 5 years. Rust has changed a lot in the past 5 years, people just haven't noticed, so they assume that Rust is still an old outdated language.
16.
▲
by
Pauan
3y ago
Rust Futures are essentially green threads, except much lighter-weight, much faster, and implemented in user space instead of being built-in to the language. Basically Rust Futures is what Go wishes it could have. Rust made the right choice
17.
▲
by
Pauan
5y ago
I think there are a couple important details you are missing... First, wasm-pack is not Ashley's personal project, it is an official Rust Wasm project. That means it is owned by the Rust Wasm team, and it is maintained by the Rust Wasm
18.
▲
by
Pauan
11y ago
I am aware of Dylan, however it did not have any influence on Nulan. Nulan's macro system is very similar to Common Lisp or Arc's macro system, in the sense that a macro is simply a compile-time function that accepts code and retu
19.
▲
by
Pauan
11y ago
Hey guys, I'm the creator of Nulan. There were some bugs in the tutorial, which I fixed just now. If the tutorial wasn't working for you, please try again. ---- This is a pleasant surprise: I honestly was not expecting this, since