Logs: liberachat/#haskell
| 2025-10-19 13:13:25 | → | finsternis joins (~X@23.226.237.192) |
| 2025-10-19 13:13:33 | AlexNoo_ | is now known as AlexNoo |
| 2025-10-19 13:17:34 | <davean> | mreh: cabal doesn't default, its REQUIRED |
| 2025-10-19 13:17:40 | → | inline joins (~inline@2a02:8071:57a1:1260:d82c:6b3f:958f:cc66) |
| 2025-10-19 13:19:47 | <davean> | Defaulting would ruin the required nature of it |
| 2025-10-19 13:21:02 | × | Rembane quits (~Rembane@user/Rembane) (Quit: WeeChat 4.1.1) |
| 2025-10-19 13:21:44 | → | Rembane joins (~Rembane@user/Rembane) |
| 2025-10-19 13:22:11 | <ggVGc> | [exa]: yeah, I agree that is formally true, but in practice whatever GHC does is what Haskell is, in the same way that C is de-facto defined by extensions that GCC and clang both implement. |
| 2025-10-19 13:22:12 | <davean> | I know weirdly it is listed as optional in the field syntax reference, thats a bit missleading. Thats the base syntax, not the semantic syntax. |
| 2025-10-19 13:22:55 | davean | looks around at all the project you use regularly that have never been compiled with gcc or clang |
| 2025-10-19 13:22:58 | <ggVGc> | but yeah, GHC2021 is a nice attempt at collecting useful extensions into something coherent |
| 2025-10-19 13:23:23 | <ggVGc> | davean: I think those are few? |
| 2025-10-19 13:23:42 | <davean> | ggVGc: I'm not even sure you listed the most used C compilers |
| 2025-10-19 13:23:46 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-10-19 13:24:21 | <ggVGc> | interesting, would say it's intel or msvc? |
| 2025-10-19 13:24:32 | <ggVGc> | because I think I disagree with that for everyday software that I personally run |
| 2025-10-19 13:24:39 | <davean> | msvc is DEFINETLY huge |
| 2025-10-19 13:24:59 | <davean> | I didn't say it was common with what you run, I was saying you definately use stuff that is only compiled on msvc |
| 2025-10-19 13:25:00 | <ggVGc> | but it's widely accepted that msvc does not properly implement C? |
| 2025-10-19 13:25:25 | <davean> | icc is also a major compiler, and there are a bunch of others that are pretty major |
| 2025-10-19 13:25:33 | <davean> | C is a highly multi-compiler language |
| 2025-10-19 13:27:04 | <davean> | But a lot of stuff is embeded and neither gcc or clang is common in embeded at all |
| 2025-10-19 13:27:45 | <davean> | Haskell is not widely varied in compilers, though there are some others which you use for good reasons. C though? No C is not at all "what is implimended by gcc and clang" |
| 2025-10-19 13:28:26 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-10-19 13:28:26 | × | SlackCoder quits (~SlackCode@64-94-63-8.ip.weststar.net.ky) (Ping timeout: 248 seconds) |
| 2025-10-19 13:28:40 | <davean> | Seeing all the microhs patches come through is actually interesting ATM |
| 2025-10-19 13:29:33 | <ggVGc> | well, okay, I'm willing to retract what I said. But, for many people writing C on linux or osx, extensions to C implemented by GCC are seen by many as standard parts of the language, I think/ |
| 2025-10-19 13:29:54 | <ggVGc> | but, anyway, my point was still about Haskell and GHC |
| 2025-10-19 13:32:04 | → | SlackCoder joins (~SlackCode@208.26.91.234) |
| 2025-10-19 13:33:58 | <ggVGc> | I feel like GCC is quite common in embedded nowadays though? I've only done NXP, ESP and rp2050 stuff I guess, but those toolchains are gcc-based. And NXP is quite major? |
| 2025-10-19 13:34:13 | × | karenw quits (~karenw@user/karenw) (Ping timeout: 264 seconds) |
| 2025-10-19 13:34:17 | <ggVGc> | but. sure, my statement wasn't very well thought through |
| 2025-10-19 13:38:46 | <ggVGc> | anyway, I appreciate that GHC has a proper extension system. Unlike Scala, which I now writre for my day job, where everything just goes into trunk. |
| 2025-10-19 13:39:34 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-10-19 13:44:52 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-10-19 13:46:44 | <davean> | ooof I'm sorry |
| 2025-10-19 13:46:57 | × | __monty__ quits (~toonn@user/toonn) (Quit: leaving) |
| 2025-10-19 13:47:47 | <haskellbridge> | <magic_rb> We need a JVM backend in GHC :P |
| 2025-10-19 13:48:06 | <ggVGc> | I think it exists? |
| 2025-10-19 13:48:14 | <ggVGc> | or at least there was some project way back |
| 2025-10-19 13:48:19 | <haskellbridge> | <magic_rb> There was a external project |
| 2025-10-19 13:48:20 | <ggVGc> | unless I am making it up |
| 2025-10-19 13:48:26 | <ggVGc> | ah, right |
| 2025-10-19 13:48:40 | <haskellbridge> | <magic_rb> But it wasnt ever integrated into GHC proper, i think it was called etalang? |
| 2025-10-19 13:48:53 | <haskellbridge> | <magic_rb> Kinda died due the same reason ghcjs started dying, not upstream |
| 2025-10-19 13:48:55 | <ggVGc> | it may be heresy in here, but I actually would not like to write our backend in Haskell either. |
| 2025-10-19 13:49:09 | <haskellbridge> | <magic_rb> Heresy |
| 2025-10-19 13:49:11 | <ggVGc> | it's not the type of work I prefer to use Haskell for |
| 2025-10-19 13:49:28 | <haskellbridge> | <magic_rb> We're gonna string you up |
| 2025-10-19 13:50:30 | <ggVGc> | I appreciate it. Will give me a good excuse to leave my newborn twins with my wife for undefined duration? |
| 2025-10-19 13:50:53 | × | trickard quits (~trickard@cpe-57-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-19 13:51:33 | <ggVGc> | to be fair, I've never worked at a company running Haskell in production, and I am still curious how that looks day-to-day. So, my mind could be changed. |
| 2025-10-19 13:51:51 | <ggVGc> | (specifically for web backend) |
| 2025-10-19 13:52:00 | <ggVGc> | which, arguably, is almost all work available right now |
| 2025-10-19 13:52:51 | <ggVGc> | (I am willfully ignoring anything inside the browser) |
| 2025-10-19 13:55:22 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-10-19 13:55:30 | <davean> | I do all my web backend in haskell |
| 2025-10-19 13:55:47 | <davean> | Easiest experience I've ever had |
| 2025-10-19 13:56:08 | <Rembane> | davean: Are there any libraries that makes things particularly easy? |
| 2025-10-19 13:56:30 | <davean> | Rembane: uh yes but also not sure what you'd be asking |
| 2025-10-19 13:56:42 | × | inline quits (~inline@2a02:8071:57a1:1260:d82c:6b3f:958f:cc66) (Ping timeout: 248 seconds) |
| 2025-10-19 13:57:14 | × | CiaoSen quits (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 248 seconds) |
| 2025-10-19 13:57:26 | <davean> | Like there are always libraries that make tasks easy - actually the reusability of code in haskell is rather important there (thank you laziness) but like thats SUPER general and I think you want something more specific |
| 2025-10-19 13:58:11 | <Rembane> | davean: Sorry, I had all the context in my head and not on the screen. Context: My web development becomes really nice because I use Django when I work in Python and Phoenix and Ash when I work in Elixir. Are there any libraries like those, or don't you need them? |
| 2025-10-19 13:58:31 | <davean> | defiantely don't need something like that |
| 2025-10-19 13:58:48 | <davean> | there are some good routing libraries, and there are some good applicitive form libraries |
| 2025-10-19 13:59:02 | <Rembane> | Give me names! :D |
| 2025-10-19 13:59:08 | <davean> | where form is generalized to be the form HTTP type, not HTML |
| 2025-10-19 13:59:36 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2025-10-19 13:59:44 | <davean> | reform is pretty cool |
| 2025-10-19 13:59:47 | → | qqe joins (~qqq@185.54.23.200) |
| 2025-10-19 14:00:09 | × | merijn quits (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-10-19 14:00:55 | <Rembane> | It looks cool, thank you |
| 2025-10-19 14:01:10 | → | trickard_ joins (~trickard@cpe-57-98-47-163.wireline.com.au) |
| 2025-10-19 14:01:20 | <ggVGc> | what does your deployment setup look like, davean? And what do you use for metrics reporting? |
| 2025-10-19 14:01:51 | <davean> | deployment? Just have nix build the cabal package and create a systemd service |
| 2025-10-19 14:02:33 | <davean> | I have a little internal library for some graceful shutdown handling, but its nothing that isn't already supported but not like cleanly hooked up |
| 2025-10-19 14:03:43 | <davean> | As for metrics reporting, it depends on what metrics you care about. Like EKG is a pretty standard one. |
| 2025-10-19 14:04:51 | <davean> | I don't actually find metrics to be a thing I ever look at with haskell services. There isn't ever anything to track down and they're performant. I can't recall the last time I had to pay attention to any metrics for them |
| 2025-10-19 14:05:05 | <davean> | One of the nice parts of haskell is never having problems |
| 2025-10-19 14:05:30 | <davean> | god I spent so much time staring at metrics with python services ... |
| 2025-10-19 14:06:10 | <ggVGc> | Yeah, we also deploy as a systemd service at my current job, which I think is fine. |
| 2025-10-19 14:06:21 | <ggVGc> | how do you know if you have or don't have problems without metrics? |
| 2025-10-19 14:06:23 | <davean> | well the nix part is more significant |
| 2025-10-19 14:07:01 | <ggVGc> | what I mean is things like number of open DB connections, query times, HTTP response times, statistics on raturn codes etc. |
| 2025-10-19 14:07:07 | <davean> | ggVGc: well think about the sort of problems you might have, most of them are error logs. Like a DB is down or something |
| 2025-10-19 14:07:10 | <ggVGc> | concurrent request numbers |
| 2025-10-19 14:07:38 | <davean> | well, my haskell code already uses a fixed DB pool and trades them out, so the only issue that could happen there is a DB error, thats a log issue not a metric issue |
| 2025-10-19 14:08:20 | → | morj joins (~morj@user/morj) |
| 2025-10-19 14:08:51 | <davean> | don't need metrics for "if this ever happens, trip an alert on the first occurence" |
| 2025-10-19 14:08:57 | <ggVGc> | for me, metrics is not something that has to do with errors/issues. It's a way to know things about the service |
| 2025-10-19 14:09:14 | <ggVGc> | how do you know how many users you have, for example, at during which hours? |
| 2025-10-19 14:10:12 | <davean> | I mean that would be a stats issue, though also why would I care? How many users I have overall might matter, but why do I care which hours generally? And if I did I can get that out of analytics, but which hour is never really relivent to me |
| 2025-10-19 14:10:16 | <davean> | personally |
| 2025-10-19 14:10:37 | <davean> | I'm actually SLIGHTLY interested in that for launches |
| 2025-10-19 14:10:47 | <davean> | to see service uptake rate |
| 2025-10-19 14:11:10 | → | merijn joins (~merijn@host-vr.cgnat-g.v4.dfn.nl) |
| 2025-10-19 14:11:11 | <davean> | That I do look at some EKG based stuff for |
| 2025-10-19 14:11:43 | → | inline joins (~inline@2a02:8071:57a1:1260:99b9:102d:fb79:f90b) |
| 2025-10-19 14:13:10 | <davean> | There is the standard tracing protocols if you want more detailed stuff |
All times are in UTC.