Logs: liberachat/#haskell
| 2021-08-01 10:57:27 | × | Guest9 quits (~Guest9@43.250.157.202) (Quit: Connection closed) |
| 2021-08-01 11:02:55 | → | MoC joins (~moc@user/moc) |
| 2021-08-01 11:06:02 | × | FinnElija quits (~finn_elij@user/finn-elija/x-0085643) (Quit: FinnElija) |
| 2021-08-01 11:06:45 | → | Pickchea joins (~private@user/pickchea) |
| 2021-08-01 11:08:37 | → | agua joins (~agua@191.177.175.57) |
| 2021-08-01 11:09:00 | × | norias quits (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) (Ping timeout: 258 seconds) |
| 2021-08-01 11:09:02 | → | fendor joins (~fendor@178.165.188.54.wireless.dyn.drei.com) |
| 2021-08-01 11:10:16 | → | FinnElija joins (~finn_elij@user/finn-elija/x-0085643) |
| 2021-08-01 11:10:58 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-08-01 11:11:36 | × | pesada quits (~agua@2804:18:4e:4e3d:1:0:74be:869) (Ping timeout: 250 seconds) |
| 2021-08-01 11:13:12 | <dexterfoo> | is there a non-blocking version of Conduit "await" function? I want to process all the current data that is queued |
| 2021-08-01 11:14:17 | × | MidAutumnHotaru quits (~MidAutumn@user/midautumnmoon) (Quit: Leaving for a break - theLounge) |
| 2021-08-01 11:14:52 | → | MidAutumnHotaru joins (~MidAutumn@user/midautumnmoon) |
| 2021-08-01 11:15:44 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2021-08-01 11:16:38 | <lechner> | Hi, Haskell offers interesting methods to structure database access like esqueleto. Who uses such domain specific features, please, and what is the benefit over traditional ways like postgres-simple, aside from possibly being independent of the specific SQL grovider? Thanks! |
| 2021-08-01 11:18:24 | → | hmmmas joins (~fidnc@183.217.200.220) |
| 2021-08-01 11:19:32 | <dexterfoo> | i think the advantages are: 1) type checks that validate that your queries are correct and match the database schema. 2) composability: create small query fragments that can be reused in bigger queries |
| 2021-08-01 11:20:46 | × | curiousgay quits (~curiousga@77-120-186-48.kha.volia.net) (Ping timeout: 272 seconds) |
| 2021-08-01 11:21:15 | → | pesada joins (~agua@2804:18:4e:4e3d:1:0:74be:869) |
| 2021-08-01 11:23:09 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-08-01 11:23:18 | × | agua quits (~agua@191.177.175.57) (Ping timeout: 272 seconds) |
| 2021-08-01 11:25:41 | × | Lycurgus quits (~juan@cpe-45-46-140-49.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-08-01 11:26:23 | <hpc> | especially #2 - the alternatives are actually writing out the query (which it seems nobody knows how to do anymore) |
| 2021-08-01 11:26:47 | <hpc> | using an orm that lifts the logic outside the query, leading to some pretty embarassing performance problems (i have seen this in python) |
| 2021-08-01 11:26:59 | <hpc> | or using store procedures and views, which... nobody seems to know how to be a dba anymore either |
| 2021-08-01 11:28:19 | <Hanicef> | hpc: yeah, orm has its caveats, but it also have benefits, especially since haskell's laziness helps with optimizing queries at times |
| 2021-08-01 11:29:02 | <hpc> | at times |
| 2021-08-01 11:29:31 | <Hanicef> | have you heard of the n+1 problem with orms? if not, i suggest you read up about it :) |
| 2021-08-01 11:29:37 | <hpc> | if you're writing out the query yourself, the language doesn't have to be lazy, you just control how far into the table you take the cursor |
| 2021-08-01 11:29:42 | → | drd joins (~drd@2001:b07:a70:9f1f:1562:34de:f50f:77d4) |
| 2021-08-01 11:30:05 | × | bruceleewees quits (~bruceleew@83.24.236.64.ipv4.supernova.orange.pl) (Ping timeout: 258 seconds) |
| 2021-08-01 11:32:37 | <hpc> | Hanicef: yeah, i am referring to the n+1 problem there |
| 2021-08-01 11:32:54 | → | bruceleewees joins (~bruceleew@83.24.236.64.ipv4.supernova.orange.pl) |
| 2021-08-01 11:33:08 | <hpc> | but n+1 is optimistic if you have sufficiently complex data |
| 2021-08-01 11:34:50 | <hpc> | if you look at it from the python code's perspective, it can easily be 2n or n**2 |
| 2021-08-01 11:35:19 | <hpc> | because you don't think about what sql each operation does, and you just casually foo.bar() your way to passing the test suite |
| 2021-08-01 11:35:52 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 256 seconds) |
| 2021-08-01 11:35:58 | × | Brianmancer quits (~Neuromanc@user/briandamag) (Ping timeout: 272 seconds) |
| 2021-08-01 11:36:03 | <dexterfoo> | The high-level haskell database libraries are more similar to C# LINQ then to ORMs |
| 2021-08-01 11:39:55 | <maerwald> | Why would you even use SQL if you don't care about performance |
| 2021-08-01 11:40:34 | <hpc> | because you aren't webscale enough for mongodb and files are bad? |
| 2021-08-01 11:40:42 | <Hanicef> | maerwald: well, performance does matter if its causing issues for the end user |
| 2021-08-01 11:40:51 | <hpc> | or you want the acid properties, or you just like the query language |
| 2021-08-01 11:41:07 | <Hanicef> | the important thing is that it's good enough for the user not to be bothered by it |
| 2021-08-01 11:41:09 | <maerwald> | no, SQL is entirely about performance... it's decades of optimisation |
| 2021-08-01 11:41:18 | <hpc> | or the aws budget comes from operations and not development :P |
| 2021-08-01 11:41:19 | <maerwald> | which is thrown out by ORMs |
| 2021-08-01 11:42:00 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-08-01 11:42:01 | <Hanicef> | maerwald: it's also an attempt on making a common and portable interface to relational database, but that went terrible |
| 2021-08-01 11:42:01 | <maerwald> | Files are great |
| 2021-08-01 11:43:02 | <hpc> | files are potentially great, but it's easy to screw up locking, fsync, etc |
| 2021-08-01 11:43:07 | × | sim590 quits (~simon@modemcable090.207-203-24.mc.videotron.ca) (Ping timeout: 258 seconds) |
| 2021-08-01 11:43:23 | <maerwald> | files are great on non-windows platforms |
| 2021-08-01 11:43:32 | <merijn> | Files are awful everywhere >.< |
| 2021-08-01 11:43:33 | <hpc> | heh, that too |
| 2021-08-01 11:43:48 | <lechner> | maerwald: do the DB alternatives you are thinking of offer data integrity, like ON DELETE CASCADE? |
| 2021-08-01 11:44:01 | <hpc> | libraries that use files under the hood are often great though |
| 2021-08-01 11:44:06 | <dexterfoo> | This article claims that "Files are fraught with peril" and you will likely have data loss: https://danluu.com/deconstruct-files/ |
| 2021-08-01 11:44:24 | <merijn> | dexterfoo: That article is entirely correct, tbh :p |
| 2021-08-01 11:44:34 | <maerwald> | lechner: check package manager file handling code. The database is supposed to be on one device and all operations are atomic. Man errors can be recovered from. |
| 2021-08-01 11:44:42 | <merijn> | If you want a database, but you don't, like, want a database, you just want SQLite :p |
| 2021-08-01 11:44:54 | <hpc> | (proof: all libraries are file-backed eventually, and the only one that matters is postgres :D) |
| 2021-08-01 11:45:14 | <hpc> | sqlite is so nice firefox bundled it twice |
| 2021-08-01 11:45:21 | <merijn> | hpc: Untrue, the only ones that matter are postgres *and* SQLite :p |
| 2021-08-01 11:45:45 | <hpc> | at least, they used to |
| 2021-08-01 11:45:48 | <merijn> | My only regret from introducing SQLite into my codebase is: 1) not integrating more of it, 2) not integrating it sooner, and 3) using persistent :p |
| 2021-08-01 11:45:54 | × | burnsidesLlama quits (~burnsides@dhcp168-012.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2021-08-01 11:46:20 | <maerwald> | I went from an sqlite->postgres conversion, so I really only use sqlite for toy things or local stuff, not real world data |
| 2021-08-01 11:46:22 | → | burnsidesLlama joins (~burnsides@dhcp168-012.wadham.ox.ac.uk) |
| 2021-08-01 11:46:32 | <merijn> | maerwald: It depends what real world data |
| 2021-08-01 11:47:01 | <merijn> | I'm not advocating the use of SQLite for, like, massively concurrent webservers |
| 2021-08-01 11:47:12 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-08-01 11:47:15 | <merijn> | more for, like, "local commandline tool data management" |
| 2021-08-01 11:47:42 | <hpc> | we've drifted off of esqueleto, -offtopic? |
| 2021-08-01 11:48:57 | <maerwald> | merijn: stack uses sqlite (not sure since when) and I think it has only increased the number of errors it throws |
| 2021-08-01 11:49:41 | <merijn> | maerwald: Seems weird to conclude that that must be SQLite's fault, as opposed to mismanagement |
| 2021-08-01 11:50:09 | <merijn> | maerwald: Also |
| 2021-08-01 11:50:12 | <maerwald> | my point is: don't pick a database unless you really need to |
| 2021-08-01 11:50:23 | <merijn> | stack uses sqlite via persistent (because, duh) |
| 2021-08-01 11:50:27 | <maerwald> | many people will do it just because they're familiar with it and less familiar with filesystem |
| 2021-08-01 11:50:33 | <merijn> | And I'm absolutely *not* surprised that that's broken as fuck |
| 2021-08-01 11:50:46 | <merijn> | Because persistent is a disaster |
| 2021-08-01 11:51:05 | <merijn> | And I've had to repeatedly fix persistent-sqlite to get reasonable behaviour |
| 2021-08-01 11:51:06 | × | burnsidesLlama quits (~burnsides@dhcp168-012.wadham.ox.ac.uk) (Ping timeout: 272 seconds) |
| 2021-08-01 11:52:52 | <maerwald> | oh, to install nix inside docker you need a privileged container. Wat? |
| 2021-08-01 11:53:00 | <merijn> | Yes |
| 2021-08-01 11:53:17 | <merijn> | Can't really use Nix without root unless you recompile it yourself |
| 2021-08-01 11:54:42 | <maerwald> | I'm trying to run stack integration tests in a container, but it requires nix |
| 2021-08-01 11:55:11 | <maerwald> | first, nix tries to invoke sudo without my consent (and there is none), then it tries to mount /proc or whatever |
| 2021-08-01 11:55:32 | × | wei2912 quits (~wei2912@112.199.250.21) (Quit: Lost terminal) |
| 2021-08-01 11:56:51 | <maerwald> | did we come up with controlling the environment so we don't have to write robust code anymore? |
| 2021-08-01 11:56:59 | <hpc> | yes |
| 2021-08-01 11:57:03 | <hpc> | that's exactly what it is |
| 2021-08-01 11:57:25 | → | burnsidesLlama joins (~burnsides@dhcp168-012.wadham.ox.ac.uk) |
| 2021-08-01 11:58:29 | × | dschrempf quits (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.2) |
| 2021-08-01 11:58:43 | <hpc> | it started with controlling the runtime environment because "this code is from 1997" |
| 2021-08-01 11:59:02 | <hpc> | then someone noticed you could control the development environment too, and programmers never had to think ever again |
| 2021-08-01 11:59:14 | <lechner> | I have never used ORMs due to the "impedence mismatch". With Haskell's declarative features, it seems the language should be able to offer something else, although I am not sure what I am looking for. This article even offers the intriguing statement that "A major mismatch between existing relational and OO languages is the type system differences." Is there anything else, maybe a set-based |
| 2021-08-01 11:59:16 | <lechner> | approach? https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch |
| 2021-08-01 11:59:25 | → | dschrempf joins (~dominik@070-207.dynamic.dsl.fonira.net) |
All times are in UTC.