Newest at the top
| 2025-12-18 21:43:44 +0100 | <sprout> | whether it's exceptionally difficult for Haskell is debatable |
| 2025-12-18 21:43:20 +0100 | <sprout> | Liamzee: your AI gave you a statement of fact that is true for any language |
| 2025-12-18 21:43:13 +0100 | ljdarj1 | ljdarj |
| 2025-12-18 21:43:13 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 264 seconds) |
| 2025-12-18 21:41:11 +0100 | <haskellbridge> | <Liamzee> Go? |
| 2025-12-18 21:41:03 +0100 | <haskellbridge> | <Liamzee> Does Py etc use blocking FFI? |
| 2025-12-18 21:41:03 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-18 21:40:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2025-12-18 21:39:08 +0100 | <monochrom> | However, none of those 4 force you to use those safe idioms. That further cuts down the candidates to 0. |
| 2025-12-18 21:38:23 +0100 | <monochrom> | As a first-order approximation: Mutex is not childsafe unless used under Haskell's bracket idiom or Python's recent "with" idiom or C++'s RAII idiom. That immediately cuts down the candidates to just 4: Haskell, Python, C++, maybe Rust. |
| 2025-12-18 21:38:22 +0100 | <sprout> | Liamzee: that wasn't what the AI stated. and FFI-ing into something that isn't threadsafe of course is going to give you problems, no matter the language |
| 2025-12-18 21:36:57 +0100 | <haskellbridge> | <Liamzee> The AI comment was: "every language with worse concurrency", i.e, Py is an example because of how hard concurrency is, and Go is apparently another example. |
| 2025-12-18 21:36:46 +0100 | l0ckna | (~obr@2001:4bb8:103:9f41:2b3f:110b:6da3:4d72) (Quit: Leaving) |
| 2025-12-18 21:36:01 +0100 | <int-e> | brainfuck |
| 2025-12-18 21:35:40 +0100 | <monochrom> | Which languages are childsafe? |
| 2025-12-18 21:35:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-18 21:34:51 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-12-18 21:32:28 +0100 | <haskellbridge> | <Liamzee> the objective remark seems to be: Haskell concurrency + FFI is not childsafe (defined as, being brain-dead robust). It's the responsibility of the library builder to make it such. Or would you contest that? |
| 2025-12-18 21:31:15 +0100 | <monochrom> | But Haskell solutions have been well-known for decades for concurrently FFI-ing to C libs with global states and/or thread-local states. |
| 2025-12-18 21:31:11 +0100 | <haskellbridge> | <Liamzee> I mean the explanation is that other languages with their concurrency / FFI model is intended to be childsafe, i.e, it deliberately brain damages the concurrency + FFI model to avoid the overhead of childsafe-ing on the library designer side, but locks every user into the childsafe model, even when it's unnecessary |
| 2025-12-18 21:29:27 +0100 | <monochrom> | Programming is seriously difficult. Haskell is just being honest about it. Other languages try to sugar-coat it. |
| 2025-12-18 21:29:02 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-12-18 21:28:45 +0100 | <monochrom> | Hutton already explained why Haskell anything is seriously difficult. |
| 2025-12-18 21:27:34 +0100 | <monochrom> | Public LLMs are only as good as Internet trash. |
| 2025-12-18 21:27:18 +0100 | <haskellbridge> | <Liamzee> I'm asking here beceause AI hallucinates and is a bullshit machine, so I'd rather ask real humans |
| 2025-12-18 21:27:15 +0100 | <monochrom> | "AI" |
| 2025-12-18 21:27:03 +0100 | <haskellbridge> | <Liamzee> I mean, I can leave it unsafe, but I guess I put a premium on child safety |
| 2025-12-18 21:26:53 +0100 | <haskellbridge> | <Liamzee> Honestly, I just had AI tell me that FFI + Haskell green threads / concurrency model is seriously difficult, especially if the wrapped library has global state |
| 2025-12-18 21:24:08 +0100 | <int-e> | Other languages had you write dozens of lines of marshalling code by hand for the most trivial functions. |
| 2025-12-18 21:24:07 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-18 21:23:31 +0100 | <int-e> | And fwiw, as FFIs go Haskell's is actually pretty nice, especially considering how old it is. |
| 2025-12-18 21:22:55 +0100 | <monochrom> | (It's what gtk2hs does.) |
| 2025-12-18 21:22:35 +0100 | <monochrom> | (How better? You can send a f**king IO action as a message too. It doesn't even need to be data!) |
| 2025-12-18 21:22:00 +0100 | omidmash | (~omidmash@user/omidmash) omidmash |
| 2025-12-18 21:21:53 +0100 | <monochrom> | And is particularly sweet in Haskell because Haskell has a much better API for sending messages to worker threads and/or pools. |
| 2025-12-18 21:21:47 +0100 | omidmash | (~omidmash@user/omidmash) (Quit: Ping timeout (120 seconds)) |
| 2025-12-18 21:21:38 +0100 | Googulator72 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-18 21:21:06 +0100 | <monochrom> | If you want tight control on which thread does what, the technique of "worker thread pool" has been well known for decades. |
| 2025-12-18 21:20:41 +0100 | Googulator75 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) |
| 2025-12-18 21:19:28 +0100 | <int-e> | C libraries don't control from which threads they're called either |
| 2025-12-18 21:19:27 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-18 21:19:17 +0100 | <monochrom> | You can assume that the end user has made the correct choice between forkIO and forkOS. |
| 2025-12-18 21:18:23 +0100 | qqe | (~qqq@185.54.20.98) |
| 2025-12-18 21:18:17 +0100 | <haskellbridge> | <Liamzee> Still, if I'm trying to build a library wrapper, I can't control whether the end user is using forkIO or forkOS |
| 2025-12-18 21:17:42 +0100 | <haskellbridge> | <Liamzee> yes, I've used it. |
| 2025-12-18 21:17:36 +0100 | <haskellbridge> | <Liamzee> So, now I'm thinking no-inline unsafePerformIO global locks. ??? |
| 2025-12-18 21:17:36 +0100 | <monochrom> | Have you heard of forkOS? |
| 2025-12-18 21:16:47 +0100 | <monochrom> | I am not interested in blaming C, or blaming anything, at least for now. |
| 2025-12-18 21:16:33 +0100 | <haskellbridge> | <Liamzee> I've been trying to build a wrapper around the tinyfiledialogs library, and it turns out that traverse_ forkIO, on Macos, at least, will cause the script runner to jam buffers |
| 2025-12-18 21:16:03 +0100 | <haskellbridge> | <Liamzee> From experienced production devs: is it cursed? |