7 ms·

I prefer golang's syscalls and os modules. Just direct interfaces to the C functions, no abstractions and no cruft.

• wmf 9y ago
  That's not idiomatic Go, is it? Go also abstracts I/O by converting it to async under the hood.
• virgilp 9y ago
  I'm not familiar enough with golang, but from your description it seems like in the Rust world, you're saying "I prefer the mio crate[1]" [1] https://docs.rs/mio/0.6.10/mio/ https://docs.rs/mio/0.6.10/mio/
  • bryanlarsen 9y ago
    AFAICT, a more go-like approach would be to use std::fs inside a std::thread
    • tatterdemalion 9y ago
      What's missing here is that Go has a userspace scheduler and greenthreads. Despite presenting the user with something that looks like old school blocking IO, because you are only blocking a greenthread it is actually asynchronous IO under the hood. And of course there is a huge amount of abstraction to build this up. It's just all hidden in the language runtime, so people can say with a straight face that there is "no abstraction and no cruft."
• jcrites 9y ago
  My understanding is that Go programs typically tackle these problems with goroutines and channels which are definitely an abstraction over kernel functionality.
• vvanders 9y ago
  Does golang use io completion on Windows? I know Tokio does so if that's not the case then there's probably a pretty large delta in performance.
  • ori_b 9y ago
    It does: https://golang.org/src/net/fd_windows.go https://golang.org/src/net/fd_windows.go
• leshow 9y ago
  Isn't go's greenthread offering part of it's runtime? If you use a go channel or thread, is that not calling some go std lib abstraction? What you're talking about seems like a pretty non-idiomatic use of go.
• JoshTriplett 9y ago
  That's still an abstraction, just one built into the language. And Go's approach (as well as other things, like garbage collection) requires a runtime; while that does support an interesting programming model, it also makes Go unusable for a variety of use cases that need to run without a runtime. This approach in Rust, as well as Rust's approach to memory management and other things, allow it to run without a runtime, which allows it to work for anything C does.
  • tatterdemalion 9y ago
    There's another reason Rust's ecosystem uses futures (as opposed to having some library-based greenthreading system): each future is like the stack of a userspace thread, but perfectly sized (it will be as large as the largest stack space needed at a yield point). This reduces the memory footprint of services using futures.
  • cshenton 9y ago
    What use cases need no runtime (genuine question)? I understand the benefit of being compiled, since you can target a cpu instruction set and run without dependencies.
    • JoshTriplett 9y ago
      Low-level firmware, embedded applications, OS kernels, interrupt service routines, applications that can't afford the latency of being periodically interrupted, platforms where you don't have a scheduler or most OS services, libraries intended to be loaded into other applications written in other languages (e.g. where you don't control the main program entry point), writing language runtimes themselves, etc. Early Rust, pre-1.0, did have a runtime and a green-threads mechanism; they ripped it out because they recognized that they couldn't go everywhere they wanted to go if they kept it. And if they hadn't done that, I believe Rust would have been far less successful than it has been.
      • cshenton 9y ago
        So I'm guessing it's the runtime itself that expects to interact with things like an OS scheduler. Does that mean if you attempted to write an OS in Go, you'd basically have to do it without many of the features of the runtime (that provide the abstractions that are useful for application progamming?). That would be pretty crummy.
• lossolo 9y ago
  For all asking what OP is talking about, this is example of using epoll directly in Go: https://gist.github.com/tevino/3a4f4ec4ea9d0ca66d4f https://gist.github.com/tevino/3a4f4ec4ea9d0ca66d4f This is description (from dotGo2017) of how netpoll works in Go under the hood if anyone is interested: https://www.youtube.com/watch?v=xwlo3xigknI https://www.youtube.com/watch?v=xwlo3xigknI
  • fpoling 9y ago
    I am not sure what exactly that gist tries to show. As it forces the go runtime to run each read call on a separated native thread, it just shows that one can use go to implement rather bad epoll antipattern.
• pcwalton 9y ago
  Go's I/O is anything but a direct interface to the C functions. Its scheduler is a large abstraction.
• deleted 9y ago
  [deleted]
• lkjalskdjflasdf 9y ago
  Go IO is implemented with green threads using a scheduler underneath. Rust had green threading in the initial phases but this was voted out.