Newest at the top
| 2024-09-21 23:22:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 276 seconds) |
| 2024-09-21 23:20:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-21 23:17:29 +0200 | mikess | (~mikess@user/mikess) |
| 2024-09-21 23:17:15 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 23:08:35 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 244 seconds) |
| 2024-09-21 23:03:36 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 23:03:24 +0200 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 260 seconds) |
| 2024-09-21 22:52:37 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-09-21 22:51:55 +0200 | <EvanR> | more job security xD |
| 2024-09-21 22:50:45 +0200 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2024-09-21 22:47:48 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-21 22:47:17 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-21 22:43:54 +0200 | tcard_ | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2024-09-21 22:37:24 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2024-09-21 22:36:45 +0200 | <tuxpaint> | even plugins written in go, many of them are written in go, then compiled via tinygo to wasm, then run via like wazero in go. since zero compatiblity between go versions. |
| 2024-09-21 22:35:46 +0200 | <tuxpaint> | typical plugins systems are either grpc or wasm. and because of the cgo overhead, it's very common to compile code -> wasm, then use a pure-go wasm runtime. |
| 2024-09-21 22:33:41 +0200 | <tuxpaint> | that is all "implementation", developers are "not supposed to rely on it" |
| 2024-09-21 22:33:16 +0200 | <tuxpaint> | there is 0 stability guarantee for any go internals between versions. |
| 2024-09-21 22:32:59 +0200 | <tuxpaint> | dont worry. go can barely even do that within go. the plugin system requires everything to be compiled with the exact same compiler version, and it's awful |
| 2024-09-21 22:32:46 +0200 | <tomsmeding> | tuxpaint: maybe, yes |
| 2024-09-21 22:32:43 +0200 | <monochrom> | (Fortunately it didn't happen during the last 10 years, so by "induction" we're safe.) |
| 2024-09-21 22:32:14 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 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 :') |