Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust without the async (hard) part

lunatic.solutions

Post reply on HN
Print view View original

51–60 of 136 posts

Re: Rust without the async (hard) part

#51

Post by Matthias247 »

etra0 wrote: post #29
lewantmontreal wrote: post #19

I use Rust for the amazing types, map/filter/reduce, and, even if I never write macros myself, beautiful libraries like serde and clap. I do need to often use async to wait for multiple network requests at once, although I'm not quite comfortable with it. Requesting urls n-at-a-time took me a while ( https://play.rust-lang.org/?version=stable&mode=debug&editio... ). In particular rust-analyzer itself cannot figure ou…

Sometime ago I was comparing go, python and Rust to do some GET request asynchronous. At first, I noticed that the go version was actually faster than the Rust one, and then I saw that in `reqwest`, they recommend you if you're doing multiple GET request, to create a `Client` and then use that to get better performance[1]. After changing my code, the Rust version was effectively a bit faster (not by much, to be hones…

reqwest::get() is even worse than not having a connection pool. It will also reload the full content of system certificate stores on each invocation - since it creates a new reqwest client. On some hosts that can take 10-100ms alone.

Always create a client explicitly. And also always add a timeout.

The Go http.Get() function uses a shared global client, so making a request doesn't have high initialization costs, and requests can make sure of a shared connection pool.

Re: Rust without the async (hard) part

#52

Post by hgomersall »

zaphar wrote: post #3

Anything using the green/lightweight or OS thread model is usually easier to use at the cost of some runtime performance. Whether the runtime performance matters for your use case can only be determined by measuring stuff. The perception that async rust is where you should start for concurrent rust because it's built in and everyone uses it perhaps should be revisited. I would argue that the other options are worth c…

Personally, once I grokked async rust, I found it much easier to use and reason about than threads. Things just seem to map better without any messy stuff to think about.

Re: Rust without the async (hard) part

#53

Post by mikevm »

api wrote: post #41
estebank wrote: post #39

Earlier quoted context omitted.

> There is no sane way to make async optional in a library and reuse code. FWIW, there's an effort to do exactly that, but because it will require language level changes and it is just on the drawing board phase, it will likely be a while before it can be widely used. The "optionality" of `async` while sharing code also applies for `const` and mutability (why do we need `Deref` and `DerefMut`?). Finding a solution th…

Great to hear! That's really the solution. Rust async code can be a bit challenging until you get it, but I can't think of a way to make it that much simpler without sacrificing the whole "systems programming language" concept or support for embedded. The only good alternative is Go-like fibers and that requires a fat runtime. We use both Rust and Go at ZeroTier and find that they both have their own niches. (We are…

Where do you use Go?

Re: Rust without the async (hard) part

#54

Post by pornel »

zaphar wrote: post #3

Anything using the green/lightweight or OS thread model is usually easier to use at the cost of some runtime performance. Whether the runtime performance matters for your use case can only be determined by measuring stuff. The perception that async rust is where you should start for concurrent rust because it's built in and everyone uses it perhaps should be revisited. I would argue that the other options are worth c…

Rust used to have green threads before 1.0 (libgreen). Early Rust was meant to be more like Erlang[1]. The problem with them wasn't only the overhead, but also interoperability and how they affect every interaction of the language with the OS and other libraries. It made the whole language dependent on its own custom runtime.

Rust isn't meant to be a language for CRUD apps (despite making inroads in this space). It's meant to be a C/C++ alternative that can work every difficult niche where these two can, including processes that already have their own runtimes, kernel space, microcontrollers, and other situations where any overhead or bringing custom threads with magic I/O and special stack handling is unacceptable.

Rust's async is designed to be separate from the core language, and work on top of arbitrary runtimes. Most people use tokio, but it can also work with your custom loop on microcontrollers, or on top of another runtime, e.g. WASM + browser's event loop, or gtk-rs that can work on top of GTK's event loop.

[1]: http://venge.net/graydon/talks/intro-talk-2.pdf

Re: Rust without the async (hard) part

#55

Post by Animats »

dboreham wrote: post #23
loeg wrote: post #15

Earlier quoted context omitted.

Too many major packages in the ecosystem only support an async model now. It's pretty frustrating if you are just writing a synchronous program, or one with a straightforward OS threading model.

This "async virality" syndrome is the main reason why async is harmful imho. _Some_ async can be very useful in certain constrained circumstances, I believe. However forcing the async execution model on all code is a terrible idea.

Yes. I've been saying this for some time. I call it "async contamination".

The async model assumes you spend most of your time waiting for your slow users to do something. (Why a web site, which is inherently stateless, should be doing that routinely is another issue.) I'm writing a metaverse client that has about 10-20 threads, many of them compute bound, running at different priorities. Works fine, but is totally different from the async model. Trying to keep async out of the networking has been difficult. I don't use "hyper" any more. I look at builds to see if "tokio" somehow got pulled in.

Re: Rust without the async (hard) part

#56

Post by ithrow »

eloff wrote: post #31
zaphar wrote: post #3

Anything using the green/lightweight or OS thread model is usually easier to use at the cost of some runtime performance. Whether the runtime performance matters for your use case can only be determined by measuring stuff. The perception that async rust is where you should start for concurrent rust because it's built in and everyone uses it perhaps should be revisited. I would argue that the other options are worth c…

Yes, async is hard. It adds lots of complexity, both to the code and in your mental model. That slows development. I'd rather have faster development most times. It's why I prefer to use Go over Rust whenever possible. That's why I'm really interested in what lunatic is doing here. It might narrow the gap a little.

Yes, async is hard. It adds lots of complexity, both to the code and in your mental model. That slows development.

Nodejs devs seem to be doing fine? and I would say their development is faster than most devs working on other stacks. Nodejs is also a top 3 server stack and growing.

Re: Rust without the async (hard) part

#57

Post by Animats »

etra0 wrote: post #29
lewantmontreal wrote: post #19

I use Rust for the amazing types, map/filter/reduce, and, even if I never write macros myself, beautiful libraries like serde and clap. I do need to often use async to wait for multiple network requests at once, although I'm not quite comfortable with it. Requesting urls n-at-a-time took me a while ( https://play.rust-lang.org/?version=stable&mode=debug&editio... ). In particular rust-analyzer itself cannot figure ou…

Sometime ago I was comparing go, python and Rust to do some GET request asynchronous. At first, I noticed that the go version was actually faster than the Rust one, and then I saw that in `reqwest`, they recommend you if you're doing multiple GET request, to create a `Client` and then use that to get better performance[1]. After changing my code, the Rust version was effectively a bit faster (not by much, to be hones…

They recommend you if you're doing multiple GET request, to create a `Client` and then use that to get better performance

Right, then it doesn't have to reopen the connection for each request. That's not an async thing, it's a caching thing.

Re: Rust without the async (hard) part

#58

Post by toolz »

jstx1 wrote: post #36

I've done some beginner Rust and Go programming (read "the books" on both, written small programs) and I'm wondering which one to spend more time on or try to get a job with in the future. When I see discussions like this one about Rust, I start to worry that it's unnecessarily complicated and difficult to work with and that this will only get worse in the future to the point that it won't be a good fit for many of t…

If you're trying to break into the industry you're not going to be working on problems that the language really matters. Pick a popular language, learn enough to be dangerous and specialize once you find categories of problems that interest you. Go and rust are only compared a lot because they're sexy buzzwords - they do not target the same problems and they aren't competing languages. Learning both at some point could prove valuable, but personally I'd never recommend go to anyone for anything anyways.

Re: Rust without the async (hard) part

#59

Post by estebank »

daenz wrote: post #9
zaphar wrote: post #3

Anything using the green/lightweight or OS thread model is usually easier to use at the cost of some runtime performance. Whether the runtime performance matters for your use case can only be determined by measuring stuff. The perception that async rust is where you should start for concurrent rust because it's built in and everyone uses it perhaps should be revisited. I would argue that the other options are worth c…

Imo, 99% of the time, ergonomics should take precedence over power. Power can always be added later with clever hacks, without ruining an ergonomic interface. But adding ergonomics to power is a much more broken process.

> Power can always be added later with clever hacks, without ruining an ergonomic interface.

This puts limits on what can be accomplished. Starting with a more restricted set of code allowed, and then expanding it over time can be more successful in many cases, without locking you into a perhaps more ergonomic looking interface that needs to be coddled with no tooling support to avoid the "slow path". For examples in Rust: `impl Trait` used not to exist, which meant you had to use `Box` instead, which can be slower and certainly ads some verbosity. Then `impl Trait` was added and a bunch of code was now representable, and soon `type Alias = impl Trait;` will be stabilized which will allow even more code to be representable, in a way that is both performant and easier to use. A language that instead says "just use `-> Trait` and the compiler will figure out what to do" would have increased the user's perf without intervention, but for anyone that really cares about FFI stability or wants to keep on top of heap allocations would be out in the cold.

It is the same reason that you can complain about the complexity of the String/&str distinction in Rust[1], but avoiding lingering references to big strings in JS (effectively a memory leak) becomes much harder.

[1]: https://fasterthanli.me/articles/working-with-strings-in-rus...

Re: Rust without the async (hard) part

#60

Post by jstx1 »

toolz wrote: post #58
jstx1 wrote: post #36

I've done some beginner Rust and Go programming (read "the books" on both, written small programs) and I'm wondering which one to spend more time on or try to get a job with in the future. When I see discussions like this one about Rust, I start to worry that it's unnecessarily complicated and difficult to work with and that this will only get worse in the future to the point that it won't be a good fit for many of t…

If you're trying to break into the industry you're not going to be working on problems that the language really matters. Pick a popular language, learn enough to be dangerous and specialize once you find categories of problems that interest you. Go and rust are only compared a lot because they're sexy buzzwords - they do not target the same problems and they aren't competing languages. Learning both at some point cou…

> they do not target the same problems and they aren't competing languages.

Is this really true? All the problems that are solvable in Go should be solvable in Rust too right (but not vice versa because Go is GCed)? They might not compete on every front but there definitely should be overlap in the use cases.

Post reply on HN