Logs: liberachat/#haskell
| 2021-08-22 15:14:52 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-08-22 15:14:52 | → | wroathe joins (~wroathe@user/wroathe) |
| 2021-08-22 15:14:57 | → | adamflott joins (~adamflott@c-73-60-249-202.hsd1.ma.comcast.net) |
| 2021-08-22 15:17:59 | × | mastarija quits (~mastarija@78-3-210-70.adsl.net.t-com.hr) (Quit: Leaving) |
| 2021-08-22 15:18:49 | → | turlando joins (~turlando@93-42-250-112.ip89.fastwebnet.it) |
| 2021-08-22 15:18:49 | × | turlando quits (~turlando@93-42-250-112.ip89.fastwebnet.it) (Changing host) |
| 2021-08-22 15:18:49 | → | turlando joins (~turlando@user/turlando) |
| 2021-08-22 15:25:39 | × | xff0x quits (~xff0x@2001:1a81:52ba:f800:ba30:5326:3556:79a1) (Quit: xff0x) |
| 2021-08-22 15:26:11 | tremon | is now known as tremon_ |
| 2021-08-22 15:27:42 | <dsal> | kuribas: that would've been nice, though less applicable. I've written that bug more than once, though. |
| 2021-08-22 15:28:35 | <kuribas> | dsal: isn't it differently applicable though? |
| 2021-08-22 15:29:31 | <kuribas> | these instances don't overlap. |
| 2021-08-22 15:31:36 | → | zebrag joins (~chris@user/zebrag) |
| 2021-08-22 15:32:06 | <kuribas> | for Monoids I think about "combining", not "throwing away", though of course they both follow the Monoid laws. |
| 2021-08-22 15:35:10 | <dsal> | If both existed, they'd overlap, wouldn't they? |
| 2021-08-22 15:35:34 | <kuribas> | with different behaviour |
| 2021-08-22 15:36:06 | <dsal> | But yeah, I had the same intuition. I've also got code with maps nested like, five deep with piles of `unionWith (<>)` |
| 2021-08-22 15:38:17 | <nshepperd> | (Ord k, Semigroup v) => Monoid (Map k v) even |
| 2021-08-22 15:38:33 | <kuribas> | ah indeed |
| 2021-08-22 15:39:42 | <nshepperd> | it would nicely subsume the existing instance if you (fmap First) |
| 2021-08-22 15:40:07 | <nshepperd> | or maybe Last. see, i can't even remember which way it's biased |
| 2021-08-22 15:40:19 | <dsal> | Yeah. There's a bit of ship-has-sailed, though. `union` exists today and is correct behavior for some apps. I suppose it wouldn't break anything silently, though. |
| 2021-08-22 15:40:31 | × | keutoi quits (~keutoi@157.47.25.147) (Ping timeout: 252 seconds) |
| 2021-08-22 15:40:44 | <kuribas> | maybe being explicit is better in this case. |
| 2021-08-22 15:40:48 | <dsal> | Right, that's half the problem. I've written *that* bug several times, too. |
| 2021-08-22 15:41:04 | × | Igfoo quits (~ian@matrix.chaos.earth.li) (Quit: BIAB) |
| 2021-08-22 15:41:15 | <dsal> | "The expression (union t1 t2) takes the left-biased union of t1 and t2. It prefers t1 when duplicate keys are encountered, i.e. (union == unionWith const)." |
| 2021-08-22 15:41:42 | <dsal> | `(<>) = union` |
| 2021-08-22 15:42:33 | → | keutoi joins (~keutoi@157.47.0.177) |
| 2021-08-22 15:42:36 | → | hnOsmium0001 joins (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-08-22 15:42:39 | <dsal> | It'd be nice to be able to confidently combine maps without read the docs each time. |
| 2021-08-22 15:45:32 | <dsal> | https://github.com/haskell/containers/issues/539 |
| 2021-08-22 15:49:58 | → | nate1 joins (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-08-22 15:52:38 | → | benin036932 joins (~benin@183.82.178.142) |
| 2021-08-22 15:54:38 | → | Igloo joins (~ian@matrix.chaos.earth.li) |
| 2021-08-22 15:55:04 | → | averell joins (~averell@user/averell) |
| 2021-08-22 15:55:09 | × | Igloo quits (~ian@matrix.chaos.earth.li) (Client Quit) |
| 2021-08-22 15:55:18 | → | Igloo joins (~ian@matrix.chaos.earth.li) |
| 2021-08-22 15:59:58 | → | alicebudda joins (~alicebudd@cold.passenger.volia.net) |
| 2021-08-22 16:01:55 | → | Lycurgus joins (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-08-22 16:01:59 | <adamflott> | I have a strange error I'm not sure where to start debugging. I have a fairly simple stack based app that runs fine on NixOS, but fails with "app: user-error" on Ubuntu and OSX. They all use stack, ghc-8.10.4, and polysemy |
| 2021-08-22 16:02:50 | × | acidjnk quits (~acidjnk@p200300d0c72b9549d9d86757fde39a6c.dip0.t-ipconnect.de) (Ping timeout: 250 seconds) |
| 2021-08-22 16:03:07 | <adamflott> | I know it at least enters main as my argument parser is run, but after that I have no context/idea where it could be failing |
| 2021-08-22 16:03:07 | <Lycurgus> | does anyone use NixOS in production? |
| 2021-08-22 16:03:21 | <Lycurgus> | i used it about a decade ago |
| 2021-08-22 16:03:29 | <Lycurgus> | not in prod ofc |
| 2021-08-22 16:03:41 | <maerwald> | I rip it out of production whenever I can :p |
| 2021-08-22 16:04:31 | <dminuoso> | Lycurgus: Yes. |
| 2021-08-22 16:04:32 | → | shapr joins (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-08-22 16:05:02 | <dminuoso> | Lycurgus: We're starting to switch our complex infrastructure pieces, and depending on how this goes perhaps largely switch everything over. |
| 2021-08-22 16:05:10 | <maerwald> | oh dear |
| 2021-08-22 16:05:30 | <Lycurgus> | dminuoso, interesting to see how that turns out |
| 2021-08-22 16:05:36 | <dminuoso> | Right now this entails our zoo of mail related servers, and in the near future our customer authentication infrastructure |
| 2021-08-22 16:05:42 | <maerwald> | Lycurgus: with a low bus factor :p |
| 2021-08-22 16:05:48 | <Lycurgus> | in fairness I haven't looked at nix/nixos in a few years |
| 2021-08-22 16:06:10 | <maerwald> | it hasn't changed... still all constantly moving underdocumented stuff with bad bus factor |
| 2021-08-22 16:06:34 | <maerwald> | now there's a new haskell pkg infrastructure |
| 2021-08-22 16:06:46 | <dminuoso> | maerwald: We're reducing this. Im aiming for 3 senior nix engineers for the rest of the team to ask in depth questions. :) |
| 2021-08-22 16:06:53 | <Lycurgus> | sfaik the originating utrecht dept is the only place it's used outside enthusiasts |
| 2021-08-22 16:06:54 | <dminuoso> | Which for our size is good enough |
| 2021-08-22 16:07:08 | <maerwald> | yeah, I'd rather not hire nix engineers to begin with :p |
| 2021-08-22 16:07:09 | <Lycurgus> | utrecht or wherever |
| 2021-08-22 16:07:09 | <dminuoso> | And yes, the bus factor is definitely a valid concern, but one that is addressable through organizational means |
| 2021-08-22 16:07:21 | <dminuoso> | maerwald: We're going to do the training with existing engineers. |
| 2021-08-22 16:07:36 | <Lycurgus> | lol, will 3 be enuf? |
| 2021-08-22 16:07:37 | <maerwald> | I usually make clear in interviews that I'm not willing to learn nix :p |
| 2021-08-22 16:07:45 | <dminuoso> | Lycurgus: We're a relatively small shop, so yes. |
| 2021-08-22 16:08:00 | <dminuoso> | We arent using nix for development, so this is more about devops of servers. |
| 2021-08-22 16:08:13 | <dminuoso> | maerwald: That's completely fair. |
| 2021-08-22 16:08:33 | <Lycurgus> | it's pretty easy to learn, or was |
| 2021-08-22 16:08:41 | <dminuoso> | I think the important part of nix is to be open and honest about the issues it has. |
| 2021-08-22 16:08:44 | <maerwald> | If someone else maintains it... sure. But I already had a case of nix engineer leaving the startup and then everyone got cold feet. |
| 2021-08-22 16:09:00 | → | machinedgod joins (~machinedg@24.105.81.50) |
| 2021-08-22 16:09:09 | <dminuoso> | I think to some extend, the critcism of nix is just more open and honest, the sheer amount of headaches Ive had with things like ansible.. it's all a trade off. |
| 2021-08-22 16:09:24 | <dminuoso> | Except ansible fanboys have a low tendency to agree that there's deep issues with their approach |
| 2021-08-22 16:09:31 | <dminuoso> | Lack of reflection |
| 2021-08-22 16:09:47 | <maerwald> | ansible is just bash |
| 2021-08-22 16:09:52 | <dminuoso> | heh |
| 2021-08-22 16:09:53 | <Lycurgus> | you could make a much better case for it when it started 15 ya or so |
| 2021-08-22 16:10:01 | <dminuoso> | lexically written in yaml |
| 2021-08-22 16:10:05 | <Lycurgus> | since then LSB distro have vastly improved |
| 2021-08-22 16:10:28 | <dminuoso> | I think the only reasonable alternative for our problem domain would have been k8s |
| 2021-08-22 16:10:34 | <Lycurgus> | fight the next war, not the last one |
| 2021-08-22 16:10:54 | <Lycurgus> | *distros |
| 2021-08-22 16:11:09 | <maerwald> | all distros suck |
| 2021-08-22 16:11:41 | <Lycurgus> | well you want NixOS then |
| 2021-08-22 16:11:49 | <Hecate> | or no computers |
| 2021-08-22 16:11:57 | <Hecate> | which would be optimal :p |
| 2021-08-22 16:12:10 | <dminuoso> | 18:11:09 maerwald | all distros suck |
| 2021-08-22 16:12:15 | <dminuoso> | Just like all programming languages suck |
| 2021-08-22 16:12:25 | <maerwald> | dminuoso: yeah, I also say that in interviews: programming sucks |
| 2021-08-22 16:13:27 | <dminuoso> | Right now, its just that nixos is in my comfort zone, and it gives me the right mix of proper declarative description with atomic updates, and yet results in a mostly plain linux system that non-nixos users can interact with. |
| 2021-08-22 16:13:48 | → | Guest|58 joins (~Guest|58@77.213.94.23) |
| 2021-08-22 16:13:51 | <dminuoso> | So our old admins can still log in and look around for problems like they're used to. With k8s that approach doesnt work anymore |
| 2021-08-22 16:14:10 | → | Erutuon joins (~Erutuon@user/erutuon) |
| 2021-08-22 16:14:33 | <maerwald> | calling nixos *declarative* is a far stretch, that may merely rely on technical definitions rather than reality |
| 2021-08-22 16:15:04 | <maerwald> | once you got your messy stuff written out, it does roughly the same thing (except in different environments/kernels/...) |
| 2021-08-22 16:15:55 | → | stef204 joins (~stef204@user/stef204) |
| 2021-08-22 16:16:11 | <dminuoso> | I dont know about that, with nixos its much easier to say "this is an accurate description of our systems". If I remove `services.postfix.enable = true;`, then I have very good reason to trust that the systemd unit will no longer appear. |
| 2021-08-22 16:16:50 | <dminuoso> | Of course this is still based on contracts. If people violate it through various means (say a user is running a postfix from a shell in a tmux session), that cant be helped. |
All times are in UTC.