5 ms·

> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but

> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I think about personally and which are probably a little more unusual to see: * Batteries not included: the standard library's been pretty stripped down in favor of moving things out into external crates. The justification is that packages included in the standard library tend to ossify and become liabilities as they outlive their usefulness [1]. I buy the argument, but am a little worried that it's going to result in a fractured ecosystem where even extremely common functions like HTTP don't have "one true path" so we get a dozen different packages that try to handle it. * Tunnel vision focus on Tokio: to my eye the community seems a little obsessed with Tokio and zero-cost futures. It's really nice how performant it is, but I'm not crazy about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`). I think that for most cases where performance is not an absolute mission critical necessity, a light runtime that manages asynchronous operations for you (say like Go's) is probably the way to go because it unlocks far better productivity. I'm cautiously optimistic about the possible inclusion of something like an `await/async` construct. [1] https://blog.rust-lang.org/2017/05/05/libz-blitz.html https://blog.rust-lang.org/2017/05/05/libz-blitz.html

eridius 9y ago
Rust used to have a light runtime that managed asynchronous operations using green threads. It was eventually discarded because it caused an unavoidable performance hit even when not using it (because the low-level runtime and I/O methods all needed virtual dispatch) and it wasn't providing any clear benefit over just using OS threads.
tatterdemalion 9y ago
I think we all agree that future chaining isn't great surface API in the long-term, but we have a pretty good idea of how to desugar async/await to the futures we have. That's why we're build the runtime around them; because they're fast and they will (someday) have a relatively convenient API.
coldtea 9y ago
>about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`) How is that more boilerplate than any other way to have concurrency?
- steveklabnik 9y ago
  Async/await is commonly suggested as a lighter-weight syntax.
  - coldtea 9y ago
    Well, isn't async/await complementary to futures?
    - xorxornop 9y ago
      Oh, it is, it just makes them a lot easier to use. The compiler does method restructuring magic behind the scenes to build the necessary state machines. Everything gets a lot easier to understand.
- arianvanp 9y ago
  Do notation makes this stuff a whole lot more readable (See Haskell). Or Async-await (See C#)
  - brandur 9y ago
    +1. Also, Go's goroutines and channels.
  - marcosdumay 9y ago
    About do notation, can't Rust get something similar with macros? (I still didn't get to making macros in it.)
    - steveklabnik 9y ago
int_19h 9y ago
The big problem with Go-like concurrency is that it does not cross the ABI boundary well, because we're still effectively stuck with C for ABIs. So if you want to use that one language for everything, that is fine. But if you want to invoke an API written in other language, then "and_then" type futures make more sense, because they can be easily mapped to a C ABI. To give one specific example, WinRT uses futures, and there you can write async code that flows from C++ through C# to JavaScript and back, with mapping to a common ABI type done transparently at the interop layers (https://docs.microsoft.com/en-us/uwp/api/windows.foundation.iasyncoperation_tresult_ https://docs.microsoft.com/en-us/uwp/api/windows.foundation....). If and when we standardize on a higher-level ABI that includes fibers or something similar, then the other approach might make more sense. Of course, the problem is that there isn't a single consensus design to standardize on...
carllerche 9y ago
The futures underpinning of Tokio actually doesn't have much to do with futures. The task system is really what is special about it (though, currently futures are the main way it is exposed) however, there is a lot of potential other routes that can be explorered. If you want green threads, you could build them on top of the task system and it would interopt with futures.

eridius 9y ago

Rust used to have a light runtime that managed asynchronous operations using green threads. It was eventually discarded because it caused an unavoidable performance hit even when not using it (because the low-level runtime and I/O methods all needed virtual dispatch) and it wasn't providing any clear benefit over just using OS threads.

tatterdemalion 9y ago

I think we all agree that future chaining isn't great surface API in the long-term, but we have a pretty good idea of how to desugar async/await to the futures we have. That's why we're build the runtime around them; because they're fast and they will (someday) have a relatively convenient API.

coldtea 9y ago

>about how futures-based concurrency spreads into your code through huge amounts of necessary boilerplate (`.and_then(...).and_then(...).and_then(...)`) How is that more boilerplate than any other way to have concurrency?

steveklabnik 9y ago
Async/await is commonly suggested as a lighter-weight syntax.
- coldtea 9y ago
  Well, isn't async/await complementary to futures?
  - xorxornop 9y ago
    Oh, it is, it just makes them a lot easier to use. The compiler does method restructuring magic behind the scenes to build the necessary state machines. Everything gets a lot easier to understand.
arianvanp 9y ago
Do notation makes this stuff a whole lot more readable (See Haskell). Or Async-await (See C#)
- brandur 9y ago
  +1. Also, Go's goroutines and channels.
- marcosdumay 9y ago
  About do notation, can't Rust get something similar with macros? (I still didn't get to making macros in it.)
  - steveklabnik 9y ago

int_19h 9y ago

The big problem with Go-like concurrency is that it does not cross the ABI boundary well, because we're still effectively stuck with C for ABIs. So if you want to use that one language for everything, that is fine. But if you want to invoke an API written in other language, then "and_then" type futures make more sense, because they can be easily mapped to a C ABI. To give one specific example, WinRT uses futures, and there you can write async code that flows from C++ through C# to JavaScript and back, with mapping to a common ABI type done transparently at the interop layers (https://docs.microsoft.com/en-us/uwp/api/windows.foundation.iasyncoperation_tresult_ https://docs.microsoft.com/en-us/uwp/api/windows.foundation....). If and when we standardize on a higher-level ABI that includes fibers or something similar, then the other approach might make more sense. Of course, the problem is that there isn't a single consensus design to standardize on...

carllerche 9y ago

The futures underpinning of Tokio actually doesn't have much to do with futures. The task system is really what is special about it (though, currently futures are the main way it is exposed) however, there is a lot of potential other routes that can be explorered. If you want green threads, you could build them on top of the task system and it would interopt with futures.