[00:54] Greetings...everybody [00:55] <_stink__> yo [00:56] hello [00:56] yolo stink [00:56] what did i miss? [00:57] 4 hours of idling [00:57] idle here, idle there, it's all good! [01:47] <_stink__> yes [13:35] morning [13:37] morning [13:37] morning [13:48] Good morning [14:44] <_stink__> yo [16:11] more evidence that Go is written by someone who doesn't know much: https://groups.google.com/forum/#!topic/golang-nuts/gdp1q6T0DNY Rob doesn't understand sendfile and thinks that "it can be written in a few lines of efficient user code." [16:11] Um [16:12] That's an awesome way to get buffer-overruns if you have "a few lines of efficient user code" [16:14] Pretty sure this is a moonshot: http://stackoverflow.com/jobs/135577/director-of-product-engineering-creative-commons [16:25] I think it can easily be done without buffer-overruns. [16:25] sendfile exists for zerocopy. The kernel knows about hte open file and the open socket (or two sockets, or two files) and can copy data between them without copying the data to user space. [16:26] I'd have expected an expert like Rob Pike to both know and understand this. [16:26] The more I go down this go rabbit whole, the more I realize it really is garbage. [16:27] OK, I think I'm missing something here [16:28] So they're looking for a way in Go to use Sendfile? [16:29] or a way to replicate what sendfile does without the kernel call? [16:29] (but yeah, that R. Pike didn't know about that call is a little concerning. ;)) [16:34] the link i posted is 7yrs old. [16:34] right, i got that [16:35] its the dismissiveness and unawaredness which concerns me. [16:35] Well, it does have a certain "BSD doesn't do that" vibe to it [16:36] or rather "huh, these kids and their system calls" [16:36] (BSD does have it, so I'm reading things wrong) [16:38] * cmaloney is feeling less like a programmer and more like a punter. [16:44] plan9 probably has no userspace and everythig is kernel space and hence r pike's lack of understanding. [16:51] <_stink__> hah [17:32] or... apparently sendcopy is a helper function for splice. maybe rpike knew how to use splice... i'll bet not though, given his userspace comment.