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

Zero-cost futures in Rust

aturon.github.io

Post reply on HN
Print view View original

271–280 of 348 posts

Re: Zero-cost futures in Rust

#271

Post by pcwalton »

saynsedit wrote: post #264
pcwalton wrote: post #225

Earlier quoted context omitted.

> Right, there may be a lot of back and forth marshaling between using thread pools and not depending on whether the library you're using is futures based or not. So just like if you use cgo. You can't get away from having to deal with the issue entirely; the most you can do is to punt it to the FFI layer. There is the question of how much of the community is using blocking vs. nonblocking I/O, to be sure, but Go has…

I see your cgo analogy but at the same time it's much less pronounced there since the programming interface is the same, the programmer is supposed to assume everything will work as it should (even if it doesn't always). In this case it's a different programming interface and I think that stresses the issues. Regarding your comment on preferentially having control over blocking/async code. I think that's right. At th…

It's not just about GC pauses. Rust isn't "little Go" that you reach for only when you can't afford a GC. Many people choose Rust for the cargo package manager, generics, pattern matching, mature optimizer that prioritizes runtime speed over compilation speed, ability to write libraries callable by any language, fast FFI, compiler-enforced data race prevention, memory safety in multithreaded mode, etc. etc. These benefits apply to servers too. And many of these benefits are what lead to the futures model being more appropriate than the M:N model for the language.

Go has its benefits too, of course! One of those benefits is that blocking I/O is a simpler mental model. Both languages can happily coexist without one being in the shadow of the other.

Re: Zero-cost futures in Rust

#272

Post by ridiculous_fish »

steveklabnik wrote: post #210
steveklabnik wrote: post #131

Earlier quoted context omitted.

One solution is to put the Future into a Box.

And I can't believe I missed this, but the other way is to make the struct generic over a type implementing Future.

Does this work though? How do you create an instance of the struct without an instance of the Future?

Re: Zero-cost futures in Rust

#273

Post by lossolo »

Why you didn't compare it to C++ or C ? If you want to compete with C/C++ it would be natural to compare those in benchmarks. Java and Go have GC. It's like comparing super car with street cars when you should compare it to other super cars.

Re: Zero-cost futures in Rust

#274

Post by Animats »

pcwalton wrote: post #268
Animats wrote: post #251

Earlier quoted context omitted.

OK, make an HTTP request, and if it fails, wait 2 seconds and retry. After 10 times, give up.

Timeouts are covered here. http://alexcrichton.com/futures-rs/futures/index.html#exampl... As for repeating something multiple times, you would either repeat the chain 10 times or write your own future combinator. Probably writing a custom future combinator would make the most sense here; actually, such a thing ought to be built-in to futures.rs.

That's the problem - having to roll your own control structures. IF, WHILE, and FOR cover just about everything. This semi-functional style doesn't break down into a small number of simple, well-known primitives.

Re: Zero-cost futures in Rust

#276

Post by plesner »

This looks really impressive. I'm curious what the story is around propagating errors through chains of futures. Traditionally future libraries don't pay much attention to that which can make debugging excruciating, which it doesn't have to be. But then rust does errors differently so maybe it's less of an issue there?

About the naming though, I was a little disappointed. Out of future, deferred, and promise, "promise" is the better term. The two others imply that something will happen later which is misleading because it's fine to have promises stick around long after they're fulfilled.

Re: Zero-cost futures in Rust

#277

Post by alexnewman »

AndyKelley wrote: post #25

This is huge. This allows one to express concurrency in a natural way not prone to the typical errors of problems of this nature, with no runtime overhead, while competing with C in terms of the constraints of the runtime. Big kudos to Aaron Turon and Alex Crichton. You guys knocked it out of the park.

Checkout https://github.com/tokio-rs/tokio. It builds on top of future-rs

Re: Zero-cost futures in Rust

#278

Post by stshine »

pcwalton wrote: post #111
rdtsc wrote: post #84

As mentioned in the post, given Rust wants to operate in the same space as C, this approach makes sense. However from a higher level, building more complex concurrent systems, dealing with futures/deferred-s/promises and/or a central select/epoll/kqueue reactor loop gets daunting and doesn't mix with complex business rules. Deferred based approach has been a round for many years. I experienced it by using Twisted (Py…

> So wondering if Rust provides any ability to add that kind of an N:M threading approach. Perhaps via an extension, macro or some other mechanism. I don't want M:N threading as Go implements it. It's a big loss of performance for marginal benefit over futures. In particular the libmill approach was tried in Rust and the results were far worse than 1:1. However, assuming this takes off I would like to see async/await…

Simply comparing M:N threading with futures is not correct. In my experience using futures in Javascript, it does not support control flow at all. The goroutine's equivalent is async/await, which transform the cps of asynchronous I/O back to sync form, but it may impose more overheads than M:N threading since it stores the stack structure in its parameter.

Re: Zero-cost futures in Rust

#279

Post by nv-vn »

Anyone else find the f.select(g)/f.join(g) syntax unintuitive/awkward? I'm confused as to why they wouldn't go with the (IMO) more logical select(f, g) and join(f, g) in this case (since neither Future is really the "subject" in these cases). Not that this is a major concern (it would take only a few lines of code to change within your own program using an alias for the functions), just interested in knowing the rationale behind the choice.

Re: Zero-cost futures in Rust

#280

Post by pjmlp »

haimez wrote: post #243
gpderetta wrote: post #193

Earlier quoted context omitted.

For the example if you are using kernel bypass of the network stack, which is increasingly common in high throughput/low latency applications.

If you're going to bypass the kernel network stack for performance, you're definitely not going to write the rest of your code in go. The garbage collector, goroutine scheduler, and conservative compile time optimizations will totally undermine the end goal. If you're in that world, you're using C, C++, or That if you're feeling dangerous.

The JVM is used a lot in Fintech.

Of course it isn't the OpenJDK, rather specialized JVMs like Azul or they code using C style coding with the GC out of the out paths, having profiled the applications with tools like Java Mission Control.

These are the customers driving Oracles effort for value types, AOT compilation and JNI replacement.

Why not just use C and C++, one might ask?

In spite of all these tricks and required knowledge, salaries are lower than for C and C++ developers and overall project costs are anyway lower due to shorter development times for the other tools not available in C and C++.

Hence why Fintech nowadays is looking into languages like Pony, because they don't want to wait for Java 10, if possible.

So an area where Rust might eventually earn some friends.

Post reply on HN