Newest at the top
| 2025-12-18 22:46:47 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2025-12-18 22:46:23 +0100 | gabiruh_ | (~gabiruh@vps19177.publiccloud.com.br) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2025-12-18 22:43:22 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-18 22:39:09 +0100 | <haskellbridge> | <Liamzee> Until SIMD support in GHC becomes fully mature, it'll be very difficult to compete with Rust, and the simplest way might simply be to FFI to C/C++/Rust in the interim. FFI on its own is relatively easy, concurrency in Haskell is also easy, but once you mix FFI and concurrency, whether it's Haskell specific or not, it becomes a bit more of a headache. |
| 2025-12-18 22:38:30 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-18 22:38:04 +0100 | <haskellbridge> | <Liamzee> But either case, is it worth trying to specialize in the concurrency + FFI combo? |
| 2025-12-18 22:37:42 +0100 | <haskellbridge> | <Liamzee> The example I was tossed was green threads (virtual threads) in FFI |
| 2025-12-18 22:27:42 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-18 22:22:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-18 22:22:13 +0100 | dolio | (~dolio@130.44.140.168) dolio |
| 2025-12-18 22:16:48 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-18 22:14:49 +0100 | dolio | (~dolio@130.44.140.168) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2025-12-18 22:11:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-18 22:04:40 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-18 21:55:46 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2025-12-18 21:54:01 +0100 | lambda_gibbon | (~lambda_gi@208.83.175.39) (Ping timeout: 244 seconds) |
| 2025-12-18 21:51:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-18 21:50:51 +0100 | Googulator73 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) |
| 2025-12-18 21:50:43 +0100 | Googulator75 | (~Googulato@2a01-036d-0106-48e4-3c18-a4bd-1bda-7c8b.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-12-18 21:48:52 +0100 | lambda_gibbon | (~lambda_gi@208.83.175.39) |
| 2025-12-18 21:47:53 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-12-18 21:46:11 +0100 | michalz | (~michalz@185.246.207.193) (Remote host closed the connection) |
| 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 |