Newest at the top
| 2024-09-21 22:32:02 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 22:31:54 +0200 | <monochrom> | Now imagine 10 years from now we Haskellers have to write "foreign import goapi" instead haha. |
| 2024-09-21 22:31:30 +0200 | <geekosaur> | which is why I compared it to accursedUnutterablePerformIO |
| 2024-09-21 22:31:24 +0200 | <tuxpaint> | tomsmeding: you would think? but thinking about how many ways there are to do x in rust/c makes me think not |
| 2024-09-21 22:31:19 +0200 | <geekosaur> | I think not, I really do think they need to do this for speed |
| 2024-09-21 22:30:46 +0200 | <monochrom> | I will do quasi-politics instead. They say it's for speed, but I say it's for politics. If you go through any C lib, you confess that C is still native. Well Go wants to replace C and be called the new native, of course it can't go through a C lib for posture. |
| 2024-09-21 22:30:39 +0200 | <tomsmeding> | (isn't that the idea of every language :p) |
| 2024-09-21 22:30:04 +0200 | <tuxpaint> | which is one of the ideas of go - don't worry too much about implementation, just write go code and let the language implementation people make the go code faster for you as the language evolves |
| 2024-09-21 22:29:30 +0200 | <geekosaur> | (and, of course, sunk cost fallacy such that if they turned out to be false, they think turning back would be too much work) |
| 2024-09-21 22:29:18 +0200 | <tuxpaint> | personally, as the developer i don't really care. if they changed how it worked one day i wouldn't really bat an eye. |
| 2024-09-21 22:29:11 +0200 | <tomsmeding> | right, direct syscalls vs libc handling is a game of tradeoffs: needing to track linux syscall ABI vs a little overhead |
| 2024-09-21 22:28:30 +0200 | <tuxpaint> | but they're paying for it and it works. |
| 2024-09-21 22:28:28 +0200 | <geekosaur> | google apparently thinks it's a good thing; I have not heard any statistics to back them up, but I;m sure they have them (but how true are they? lies, damned lies, and…) |
| 2024-09-21 22:28:12 +0200 | <tuxpaint> | whether you should implement the syscalls with pure go, or handle libc specially, idk which is better |
| 2024-09-21 22:28:10 +0200 | <tomsmeding> | (something got lost in communication here, somewhere) |
| 2024-09-21 22:27:59 +0200 | <tomsmeding> | tuxpaint: thank you, that answers my question :p |
| 2024-09-21 22:27:50 +0200 | <geekosaur> | and, well, this is part of why I dont like or use go |
| 2024-09-21 22:27:43 +0200 | <tuxpaint> | yeah, there's no special handling of libc |
| 2024-09-21 22:27:39 +0200 | <geekosaur> | now you're in a quasi-philosophical argument with the go devs |
| 2024-09-21 22:27:33 +0200 | <tomsmeding> | libc calls can crash, but syscalls also can |
| 2024-09-21 22:27:14 +0200 | <tomsmeding> | and I claim that these (hypothetical) libc calls are written by go developers in the go stdlib, so there's no good reason to have to go through all the usual hoops |
| 2024-09-21 22:27:03 +0200 | <tuxpaint> | i think the go team felt that was just as much effort as doing it themselves |
| 2024-09-21 22:26:56 +0200 | <tuxpaint> | i guess you could make your own special wrappers with safety guarantees around each libc, yes |
| 2024-09-21 22:26:50 +0200 | <tomsmeding> | that is exactly what I'm asking |
| 2024-09-21 22:26:40 +0200 | <tuxpaint> | there's no special things to handle libc safely, if that is what you are asking? |
| 2024-09-21 22:26:32 +0200 | <tuxpaint> | the only way to use libc in go is through CGO, it's treated as any other c library |
| 2024-09-21 22:26:27 +0200 | <tomsmeding> | sorry for the outburst |
| 2024-09-21 22:26:13 +0200 | <tomsmeding> | I fucking KNOW, you two :') |
| 2024-09-21 22:25:58 +0200 | <tomsmeding> | but you were saying that there's _more_ and I still haven't gotten clear what that is :p |
| 2024-09-21 22:25:50 +0200 | <geekosaur> | libc does extra runtime checks, it randomly wraps syscalls with extra goop that updates libc internal data, etc, |
| 2024-09-21 22:25:49 +0200 | <tomsmeding> | I get that 1. linking with libc means that the compiler has to do more, and that 2. going via libc takes longer than just doing the syscall, and 3. initialising libc takes time |
| 2024-09-21 22:25:26 +0200 | <tomsmeding> | I get that! |
| 2024-09-21 22:25:18 +0200 | <tomsmeding> | as far as I understand, the gomaxprocs story is all irrelevant |
| 2024-09-21 22:25:17 +0200 | <tuxpaint> | and its to have the fast compile times, and to compile the entire project from source every compile |
| 2024-09-21 22:25:17 +0200 | <geekosaur> | but I'm bailing since I'm apparently talking to a wall |
| 2024-09-21 22:25:06 +0200 | <geekosaur> | and I told you part of what that runtime cost was |
| 2024-09-21 22:25:04 +0200 | <tomsmeding> | and I have been trying to reason that there is no such cost, apart from libc being somewhat slower, which is what geekosaur has been saying all the time already |
| 2024-09-21 22:24:53 +0200 | <tuxpaint> | there is no libc at all, that is one of the goals |
| 2024-09-21 22:24:35 +0200 | <tomsmeding> | _apart_ from initialisation at the start of the process |
| 2024-09-21 22:24:29 +0200 | <geekosaur> | that's the whole point of this, libc is replaced by go's RTS |
| 2024-09-21 22:24:24 +0200 | <tomsmeding> | because previously you were claiming, repeatedly, that there is a real runtime cost |
| 2024-09-21 22:24:22 +0200 | <tuxpaint> | imo yes. and it's a major language feature of go |
| 2024-09-21 22:24:12 +0200 | <tomsmeding> | tuxpaint: is that linking/rebuilding/static binaries reason the only reason to not want to link libc? |
| 2024-09-21 22:24:10 +0200 | <geekosaur> | tomsmeding, in the go world you do _not_ call it. at all. |
| 2024-09-21 22:24:01 +0200 | <tuxpaint> | for such static binaries |
| 2024-09-21 22:23:49 +0200 | <tuxpaint> | which defeats the goal of having portable static binaries, and very fast build times |
| 2024-09-21 22:23:47 +0200 | <tomsmeding> | geekosaur: right, but you just do that once, right? |
| 2024-09-21 22:23:40 +0200 | <tuxpaint> | so you either need to link it, or rebuild it every time |
| 2024-09-21 22:23:33 +0200 | <geekosaur> | …right, never mind |
| 2024-09-21 22:23:32 +0200 | <tuxpaint> | well now you are calling libc right? |