Can anybody share their thoughts on which key features / libs are still missing in Rust?
Async-await on stable Rust
241–250 of 392 posts
Re: Async-await on stable Rust
#242Earlier quoted context omitted.
Maybe the website tells more? https://www.prisma.io/ Basically we offer a code generator for typescript, migrations and a query engine to simplify data workflows. Go support is coming next.
Maybe, but you linked the repo and it don't even have link to the website, let alone a description. Looks like a great project, best of luck.
Sorry, didn't mean this to be product advertisement, so I wanted to just link to the core code.
The user-facing product is typescript and go and in different repositories. The backend is Rust and we jumped into the async/await train some months ago already. Wanted to share some experience and how quickly in the end we were able to get a working system out with the new apis.
Re: Async-await on stable Rust
#243The level of fanboyism in the comments is saddening. Many other fast and productive languages have async since a while.
Features aren't just checkboxes. It's about the whole package and how they make everything work together.
I need a language with minimal runtime, good support for the C ABI and structure formats, decent macros, good ecosystem and community for mainstream programming needs, and support for async.
Where else can I find that whole package?
Go has too much of a runtime, GC, and doesn't support C structure formats very well (i.e. best case you need to copy/translate them to Go; you can't operate on them directly).
C++ can do it, but the details are ugly and the result unsatisfying.
Ada lacks macros and a mainstream ecosystem.
So... what do I use if not rust?
Re: Async-await on stable Rust
#244Earlier quoted context omitted.
The solution suggested by that article is to use M:N threading, which was tried in Rust and turned out to be slower than plain old 1:1 threading. If you don't want to deal with async functions, then you can use threads! That's what they're there for. On Linux they're quite fast. Async is for when you need more performance than what 1:1 or M:N threading can provide.
> If you don't want to deal with async functions, then you can use threads! Truly? If some very popular lib become async (like actix, request, that I use), I can TRULY ignore it and not split my world in async/sync?
[deleted]
Re: Async-await on stable Rust
#245Earlier quoted context omitted.
Clojure's pmap function (parallel map) is pretty cool: http://clojure.github.io/clojure/clojure.core-api.html#cloju...
There is rayon in rust land. This is a pretty different (simpler) thing.
Rayon uses iterators. Iterators are the dual of first order functions. Iterators are superior because they are more general. (You can implement pmap using iterators. You cannot implement iterators using pmap.)
Re: Async-await on stable Rust
#246I have never used async/await and cant really understand it. Is it like coroutines in lua? It seems very similar. But I guess its not limited to one thread like lua? Whats makes it better then threaded IO? Losing the overhead of threads? I like coroutines but thats mostly because they are not threads, they only switch execution on yield, and that makes them easy to reason about :)
> Is it like coroutines in lua?
idk about Lua, but afaik python's async is pretty much implemented on top of coroutines ("generators"). `await` is basically `yield`
> I like coroutines but thats mostly because they are not threads, they only switch execution on yield, and that makes them easy to reason about :)
pretty sure i've heard the same thing said about async io!
Re: Async-await on stable Rust
#247Earlier quoted context omitted.
In Rust, you can use a future adapter that does this: futures::join!(asyncTaskA(), asyncTaskB()).await See the join macro of futures[0]. The way it works is, it will create a future that, when polled, will call the underlying poll function of all three futures, saving the eventual result into a tuple. This will allow making progress on all three futures at the same time. [0] https://docs.rs/futures/0.3.0/futures/macr…
I don't know Rust but I understand the question if await is the only way to yield execution. Without a yield instruction its strange to ask "how do I start all these futures before I await" and join does make sense because it does both of those things. But other languages can start futures, yield, reenter, start more futures, and wait for them all while making progress in the mean time. I'm curious what the plan in t…
Join doesn't do everything. It's just a way to take multiple futures, and return a Future wrapping them all. I think there's a misunderstanding of how Futures and Executors interact in rust here which is why everyone is having a hard time understanding things.
A future in rust is really just a trait that implements a `poll` function, whose return type is either "Pending" or "Ready". When you create a future, you're just instantiating a type implementing that function.
For a future to make progress, you need to call its poll function. A totally valid (if very inefficient) strategy is to repeatedly call the Future's poll function in a loop until it returns Ready.
All the `await` keyword does is propagate the Pending case up. It can be expanded trivially to the following:
match future.poll() {
Pending => return Pending,
Ready(val) => val
}
So if you want to start a future, you will either have to spawn it as a top-level future (in which case you cannot get its output or know when it finishes executing unless you use channels) or you join it with other sub-futures so that all your different work will progress simultaneously. Note that you can join multiple time, so you can start two futures, join them, and have one of those futures also start two futures and join them, there's no problem here.
Re: Async-await on stable Rust
#248Earlier quoted context omitted.
Sorry, how is Rust not that language? You can use single threaded executors that only require Send and not Sync on data being executed on.
Nit: Singlethreaded executors also don't require "Send", since they don't move things between threads. That allows you too e.g. use non-atomically refcounted things (Rc ) on singlethreaded executors, which you can't use in the multithreaded versions.
Yes, you're quite correct, and I don't think a nit. That is much more accurate.
Re: Async-await on stable Rust
#249This is a big improvement, however this is still explicit/userland asynchronous programming: If anything down the callstack is synchronous, it blocks everything. This requires every components of a program, including every dependency, to be specifically designed for this kind of concurency. Async I/O gives awesome performance, but further abstractions would make it easier and less risky to use. Designing everything a…
[deleted]
Re: Async-await on stable Rust
#250This is a major milestone for Rust usability and developer productivity. It was really hard to build asynchronous code until now. You had to clone objects used within futures. You had to chain asynchronous calls together. You had to bend over backwards to support conditional returns. Error messages weren't very explanatory. You had limited access to documentation and tutorials to figure everything out. It was a proce…
Yes this is amazing! And refactoring is actually quit easy to my experience, with two projects I've done this with at least.
I think it's straightforward, but it took me quite a while to do correctly in my dns project.