9 ms·

well actually he says that DNS lookups etc needs to be asynchronous, but aren't go's channels blocking? I mean he also says that rust has no good epoll/select

by merb 10y ago

well actually he says that DNS lookups etc needs to be asynchronous, but aren't go's channels blocking? I mean he also says that rust has no good epoll/select abstraction, which is wrong. And also "a welter of half-solutions in third-party crates but describe no consensus about which to adopt" I think he didn't researched well enough. I mean it would be the same as saying that there is no good way to create a custom non blocking dns server with pure java/scala (no external library used). Rust has https://tokio.rs/ https://tokio.rs/ and everbody who even looked into network services with rust, stumbled across it. Well maybe for his goals and contributor base go is prefered and that is ok, but well this article is more or less written as a rant against rust, that he/she/it does not agree with the generel design/documentation/whatever of rust. In fact I also think that the tooling of rust sucks. rust is a language which shines with extremly good tooling. I mean rust has a godlike package manager and every tooling gets better and better. Compared to go where the package management just sucks but the tooling even IDE completion is extremly great. P.S.: I would not want to have a garbage collected ntp server. But for a lot of things I thing Go would be a good fit, even when it would not be my tool of choice.

_jezell_ 10y ago
Go has both async buffered channels and blocking sync channels. Just slightly different syntax to pick between the two.
swsieber 10y ago
Well, I think he has a point about the epoll/select - while I'm not sure about how good that is, the tokio library is relatively new - barely reached stable. I do think that the majority of the resistance though is that the author could not get productive with Rust in 4 days. For that reason, even though the epoll and documentation issues might clear up, I don't think the author would ever select Rust, not matter how much time has passed. Which as I write, I realize that I think that Rust would be better, lack of easy on-boarding aside.
dbaupp 10y ago
tokio 0.1 was released concurrently with (or slightly after) the initial investigations behind this post, so missing it/passing over seems reasonable. That said, as pointed out in the previous discussion about this, C also doesn't have epoll in the core language (it also isn't in the standard library there, either), and Rust can call the C epoll functions directly on the platforms that have it.
- sidlls 10y ago
  It takes a fair bit of effort to call into the epoll system in a sane and safe manner from Rust. It's more than just slapping a thin "unsafe-Rust" wrapper on the C epoll API. Or at least it is in anything but, say, a toy rust-equivalent of the man-page entry examples for epoll.
  - dbaupp 10y ago
    That's fair, but the complaint seems to be epoll not being possible at all, rather than it being annoying to call. (Obviously the latter is important, but the former shows a possible deeper misunderstanding of the language.)
  - jupp0r 10y ago
    It also takes a fair bit of effort to call into epoll from C in a safe manner, though.
    - sidlls 10y ago
      Much less than from any FFI.
bjourne 10y ago
From https://tokio.rs/blog/tokio-0-1/ https://tokio.rs/blog/tokio-0-1/: "Announcing Tokio 0.1 ... The 0.1 release is a beta quality release. ... This release also represents a point of relative stability for the library, which has been undergoing frequent breaking changes up until now. While we do intend to eventually publish a 0.2 release with breaking changes ..." I'm not trying to take a dump on the project (breaking changes are expected and welcome for new projects), but it is obvious a lot of the Rust ecosystem is in a very immature state. Probably much to immature to base an ntp server on.
- Manishearth 10y ago
  Rust has had https://github.com/carllerche/mio https://github.com/carllerche/mio for two years now, longer than Rust itself has been stable. tokio is just a higher-level, nicer, API. ESR knows this. It was there in the comments of his previous issue. Yet he chooses to link to a two-year old issue with one comment that says that Rust doesn't have epoll as a source of truth. Mio can't compare to the baked-in goroutine goodies (neither can epoll in C!), but this blog post is outright dishonest.
  - bjourne 10y ago
    mio is currently at version 0.6.2. A version number with a leading zero usually indicates that the authors of the software deem it to be of alpha or beta quality. It's api has also significantly evolved in a backwards incompatible manner recently: https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_changed_substantially/ https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_ch... Again, not taking a dump on mio because its authors are doing the right thing. 0.x means bugs and api breaks are to be expected. Use the software at your own risk. Basing an ntp server on it might not be appropriate (atm).
    - Manishearth 10y ago
      Right, mio isn't marked stable yet, and is changing the API (mostly for tokio), but the project is mature in the sense that you wouldn't expect many bugs in it, and you can pin to a version and just use that for a while if you are worried about API stability. But yes, the async I/O space in Rust isn't amazing. But it's not as bad a picture as he paints.
bluejekyll 10y ago
> has no good epoll/select abstraction, which is wrong I can't reiterate this enough. Rust has one of the best abstractions I've ever used over epoll/kqueue and MS' variant, MIO. MIO has picked not the crappy POSIX select, which every major OS has a better alternative to now, but instead the OS' preferred event system. The 10 year stability requirement is awkward, as I don't think anyone can predict the future, and in 10 years, who knows what will change. As you mention, tokio is an awesome futures based abstraction on top of that, making it a breeze to write complex, fast, event driven logic. I'm sad that after four days he didn't like Rust, I had a 100% different experience. After one day I fell in love with nearly every aspect of the language, and it was specifically because of state machines (which they mention as one of their core desires). My biggest complaint against the language hasn't changed, which is dealing with different Error types, but even that after a lot more experience with Rust has become easier. Anyway, for NTPSec it's sad that this didn't suit their desires, but that doesn't mean that we can't write our own.
- zbobet2012 10y ago
  Go's epoll abstraction is baked into the runtime. They are called goroutines. Goroutines blocked of FD's automatically use epoll and schedule based on its results: https://github.com/golang/go/blob/master/src/runtime/netpoll_epoll.go https://github.com/golang/go/blob/master/src/runtime/netpoll...
  - bluejekyll 10y ago
    I wasn't commenting on go, just pointing out the library that most people in Rust are using for async-io.
- AsyncAwait 10y ago
  > My biggest complaint against the language hasn't changed, which is dealing with different Error types Do you mean syntactic sugar? Because there's try! and ? Or do you mean dealing with Option and Result in a more uniform way?
  - 10y ago
serge2k 10y ago
> Rust has https://tokio.rs/ https://tokio.rs/ and everbody who even looked into network services with rust, stumbled across it. didn't it launch a week ago?

by merb 10y ago

_jezell_ 10y ago

Go has both async buffered channels and blocking sync channels. Just slightly different syntax to pick between the two.

swsieber 10y ago

Well, I think he has a point about the epoll/select - while I'm not sure about how good that is, the tokio library is relatively new - barely reached stable. I do think that the majority of the resistance though is that the author could not get productive with Rust in 4 days. For that reason, even though the epoll and documentation issues might clear up, I don't think the author would ever select Rust, not matter how much time has passed. Which as I write, I realize that I think that Rust would be better, lack of easy on-boarding aside.

dbaupp 10y ago

tokio 0.1 was released concurrently with (or slightly after) the initial investigations behind this post, so missing it/passing over seems reasonable. That said, as pointed out in the previous discussion about this, C also doesn't have epoll in the core language (it also isn't in the standard library there, either), and Rust can call the C epoll functions directly on the platforms that have it.

sidlls 10y ago
It takes a fair bit of effort to call into the epoll system in a sane and safe manner from Rust. It's more than just slapping a thin "unsafe-Rust" wrapper on the C epoll API. Or at least it is in anything but, say, a toy rust-equivalent of the man-page entry examples for epoll.
- dbaupp 10y ago
  That's fair, but the complaint seems to be epoll not being possible at all, rather than it being annoying to call. (Obviously the latter is important, but the former shows a possible deeper misunderstanding of the language.)
- jupp0r 10y ago
  It also takes a fair bit of effort to call into epoll from C in a safe manner, though.
  - sidlls 10y ago
    Much less than from any FFI.

bjourne 10y ago

From https://tokio.rs/blog/tokio-0-1/ https://tokio.rs/blog/tokio-0-1/: "Announcing Tokio 0.1 ... The 0.1 release is a beta quality release. ... This release also represents a point of relative stability for the library, which has been undergoing frequent breaking changes up until now. While we do intend to eventually publish a 0.2 release with breaking changes ..." I'm not trying to take a dump on the project (breaking changes are expected and welcome for new projects), but it is obvious a lot of the Rust ecosystem is in a very immature state. Probably much to immature to base an ntp server on.

Manishearth 10y ago
Rust has had https://github.com/carllerche/mio https://github.com/carllerche/mio for two years now, longer than Rust itself has been stable. tokio is just a higher-level, nicer, API. ESR knows this. It was there in the comments of his previous issue. Yet he chooses to link to a two-year old issue with one comment that says that Rust doesn't have epoll as a source of truth. Mio can't compare to the baked-in goroutine goodies (neither can epoll in C!), but this blog post is outright dishonest.
- bjourne 10y ago
  mio is currently at version 0.6.2. A version number with a leading zero usually indicates that the authors of the software deem it to be of alpha or beta quality. It's api has also significantly evolved in a backwards incompatible manner recently: https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_changed_substantially/ https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_ch... Again, not taking a dump on mio because its authors are doing the right thing. 0.x means bugs and api breaks are to be expected. Use the software at your own risk. Basing an ntp server on it might not be appropriate (atm).
  - Manishearth 10y ago
    Right, mio isn't marked stable yet, and is changing the API (mostly for tokio), but the project is mature in the sense that you wouldn't expect many bugs in it, and you can pin to a version and just use that for a while if you are worried about API stability. But yes, the async I/O space in Rust isn't amazing. But it's not as bad a picture as he paints.

bluejekyll 10y ago

> has no good epoll/select abstraction, which is wrong I can't reiterate this enough. Rust has one of the best abstractions I've ever used over epoll/kqueue and MS' variant, MIO. MIO has picked not the crappy POSIX select, which every major OS has a better alternative to now, but instead the OS' preferred event system. The 10 year stability requirement is awkward, as I don't think anyone can predict the future, and in 10 years, who knows what will change. As you mention, tokio is an awesome futures based abstraction on top of that, making it a breeze to write complex, fast, event driven logic. I'm sad that after four days he didn't like Rust, I had a 100% different experience. After one day I fell in love with nearly every aspect of the language, and it was specifically because of state machines (which they mention as one of their core desires). My biggest complaint against the language hasn't changed, which is dealing with different Error types, but even that after a lot more experience with Rust has become easier. Anyway, for NTPSec it's sad that this didn't suit their desires, but that doesn't mean that we can't write our own.

zbobet2012 10y ago
Go's epoll abstraction is baked into the runtime. They are called goroutines. Goroutines blocked of FD's automatically use epoll and schedule based on its results: https://github.com/golang/go/blob/master/src/runtime/netpoll_epoll.go https://github.com/golang/go/blob/master/src/runtime/netpoll...
- bluejekyll 10y ago
  I wasn't commenting on go, just pointing out the library that most people in Rust are using for async-io.
AsyncAwait 10y ago
> My biggest complaint against the language hasn't changed, which is dealing with different Error types Do you mean syntactic sugar? Because there's try! and ? Or do you mean dealing with Option and Result in a more uniform way?
- 10y ago

serge2k 10y ago

> Rust has https://tokio.rs/ https://tokio.rs/ and everbody who even looked into network services with rust, stumbled across it. didn't it launch a week ago?