6 ms·

The grievances you and the article's author mention seem less to do with Rust itself, and more to do with this seemingly horrible futures library. As far as I c

by gnode 9y ago

The grievances you and the article's author mention seem less to do with Rust itself, and more to do with this seemingly horrible futures library. As far as I can tell, it's still in the rust-lang-nursery, which is an indication it's not ready for prime time yet.

pimeys 9y ago
Don't get me wrong, it's a great library! You can do pretty darn fast systems with it, all type-checked and correct. Just don't try to fit in too many things into one thread yet, wait for async/await and non-statical lifetimes in the core.
reaperducer 9y ago
If we'd all start programming in stable, mature languages instead of letting peer pressure goad us into using betaware and worse, work would be a lot simpler. It would also encourage organizations large and small to start releasing complete, polished products instead of the "move fast and break things" crap that has infected the industry. Imagine if car makers worked the same way.
- srdone 9y ago
  Isn't that what Uber is doing? :/
- majewsky 9y ago
  By that logic, programs written in C are the most polished. Yeah, that checks out. /s
  - kpil 9y ago
    Ask a COBOL programmer about this...
    - arghwhat 9y ago
      Ask an assembly programmer about this...
      - evancox100 9y ago
        Ask a machine code programmer about this...
        elcritch 9y ago
        Ask a Minecraft machine programmer about this.... (errr, couldn’t resist)
- arghwhat 9y ago
  Your "stable and mature" languages were the crazy research projects of old. No one is forcing you to do anything, but let us not forget the nature of our "mature" technologies and the process by which they form.
tveita 9y ago
I hope async programming doesn't become the standard in Rust. So much work has gone into allowing clean and safe threading, but people seem to be led towards the async libraries, which IMO solves a scaling problem only 1% of users will have. It's great that they exist, but if you're not expecting to have a c10k class problem, you can use threads and you'll probably have a better time.
- staticassertion 9y ago
  I just want to be able to say "do this thing or time out in 5 seconds", and that's like all the 'async' I need in rust. Everything else, nah. But that's just me - many people need these 0 cost abstractions, this is Rust's focus, and I'll have to wait for the higher level stuff for my projects.
- geofft 9y ago
  If you're a library, creating threads causes side effects for the host program, and doing async when called doesn't. For instance, in a single-threaded program, it's always safe to call malloc() after fork(). In a multi-threaded program, another thread might have called malloc() and picked up a global lock; since only the thread that called fork gets copied (since you don't want to do the other threads' work twice!), there's now a copy of that global lock being held by a thread that doesn't exist, so calling malloc() will deadlock. My personal interest in Rust is as a C replacement, including as a replacement for existing libraries that are written in C. While I agree threads can be very efficient (after all, the kernel implements threading by being async itself, more or less), they're annoying for this use case.
- deleted 9y ago
  [deleted]
paulddraper 9y ago
> less to do with Rust itself, and more to do with this seemingly horrible futures library Doesn't almost every major programming language have Futures though? (C++, Java, Python, Ruby, JavaScript, Go). It seems a fair criticism for so common a building block.
- steveklabnik 9y ago
  Rust's futures leverage the type system to have extremely minimal overhead; many of those languages don't try to do that. That's where the difficulty comes in.
- gnode 9y ago
  For a long time C++ and Javascript did not have futures. Rust is relatively new, and futures aren't part of the language proper yet. The problem is that the author's criticism of Rust seems to all hinge around a bleeding edge feature. I would agree with the author's criticism if it was "futures are in the lang nursery and still not ready to use," rather than: Rust is bad, because I got nasty errors when using this work-in-progress library.

by gnode 9y ago

pimeys 9y ago

Don't get me wrong, it's a great library! You can do pretty darn fast systems with it, all type-checked and correct. Just don't try to fit in too many things into one thread yet, wait for async/await and non-statical lifetimes in the core.

reaperducer 9y ago

If we'd all start programming in stable, mature languages instead of letting peer pressure goad us into using betaware and worse, work would be a lot simpler. It would also encourage organizations large and small to start releasing complete, polished products instead of the "move fast and break things" crap that has infected the industry. Imagine if car makers worked the same way.

srdone 9y ago
Isn't that what Uber is doing? :/
majewsky 9y ago
By that logic, programs written in C are the most polished. Yeah, that checks out. /s
- kpil 9y ago
  Ask a COBOL programmer about this...
  - arghwhat 9y ago
    Ask an assembly programmer about this...
    - evancox100 9y ago
      Ask a machine code programmer about this...
      - elcritch 9y ago
        Ask a Minecraft machine programmer about this.... (errr, couldn’t resist)
arghwhat 9y ago
Your "stable and mature" languages were the crazy research projects of old. No one is forcing you to do anything, but let us not forget the nature of our "mature" technologies and the process by which they form.

tveita 9y ago

I hope async programming doesn't become the standard in Rust. So much work has gone into allowing clean and safe threading, but people seem to be led towards the async libraries, which IMO solves a scaling problem only 1% of users will have. It's great that they exist, but if you're not expecting to have a c10k class problem, you can use threads and you'll probably have a better time.

staticassertion 9y ago
I just want to be able to say "do this thing or time out in 5 seconds", and that's like all the 'async' I need in rust. Everything else, nah. But that's just me - many people need these 0 cost abstractions, this is Rust's focus, and I'll have to wait for the higher level stuff for my projects.
geofft 9y ago
If you're a library, creating threads causes side effects for the host program, and doing async when called doesn't. For instance, in a single-threaded program, it's always safe to call malloc() after fork(). In a multi-threaded program, another thread might have called malloc() and picked up a global lock; since only the thread that called fork gets copied (since you don't want to do the other threads' work twice!), there's now a copy of that global lock being held by a thread that doesn't exist, so calling malloc() will deadlock. My personal interest in Rust is as a C replacement, including as a replacement for existing libraries that are written in C. While I agree threads can be very efficient (after all, the kernel implements threading by being async itself, more or less), they're annoying for this use case.
deleted 9y ago
[deleted]

paulddraper 9y ago

> less to do with Rust itself, and more to do with this seemingly horrible futures library Doesn't almost every major programming language have Futures though? (C++, Java, Python, Ruby, JavaScript, Go). It seems a fair criticism for so common a building block.

steveklabnik 9y ago
Rust's futures leverage the type system to have extremely minimal overhead; many of those languages don't try to do that. That's where the difficulty comes in.
gnode 9y ago
For a long time C++ and Javascript did not have futures. Rust is relatively new, and futures aren't part of the language proper yet. The problem is that the author's criticism of Rust seems to all hinge around a bleeding edge feature. I would agree with the author's criticism if it was "futures are in the lang nursery and still not ready to use," rather than: Rust is bad, because I got nasty errors when using this work-in-progress library.