| --- Log opened Tue Jun 28 00:00:43 2022 |
| 00:14 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [[NS] Quit: -a- Connection Timed Out] |
| 00:14 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 01:02 | | gizmore [kvirc@Nightstar-c7jiq3.dip0.t-ipconnect.de] has joined #code |
| 01:05 | | gizmore|2 [kvirc@Nightstar-s3to6c.dip0.t-ipconnect.de] has quit [Ping timeout: 121 seconds] |
| 01:33 | | ErikMesoy [Bruker@Nightstar-37t.pui.211.84.IP] has quit [Connection closed] |
| 01:35 | | ErikMesoy [Bruker@Nightstar-37t.pui.211.84.IP] has joined #code |
| 01:39 | | Pinkhair [Pink@Nightstar-9t0bd0.ph.cox.net] has quit [Connection closed] |
| 01:40 | | Pink [Pink@Nightstar-9t0bd0.ph.cox.net] has joined #code |
| 02:34 | < simon_> | ha |
| 02:34 | < simon_> | I'm attending a Rust meetup on Thursday |
| 02:35 | < simon_> | recently I asked myself if I should learn actix-web or axum. actix-web is the most popular web-framework, and axum is a new contender that integrates really well with the tokio stack, so you can derive middleware from the tokio stack. |
| 02:36 | < simon_> | so today I notice that the Rust meetup actually gives a presentation on axum |
| 02:36 | < simon_> | and that the presentation is held by one of my old students |
| 02:36 | < simon_> | and that he's the author of the framework :-D |
| 02:38 | < simon_> | (actix-web is built with the tokio stack, too. I suppose axum is just smaller and less macro-ey and does things more in the way of tokio.) |
| 02:38 | <&McMartin> | What's the Rust community's attitude towards macros? |
| 02:40 | < simon_> | McMartin, how much have you dug into Rust? |
| 02:41 | <&McMartin> | Written a modest number of toy applications with it, designed a couple medium-sized applications where I didn't like the design, hacked on/reverse-engineered a fairly large project |
| 02:41 | <&McMartin> | General focus is on desktop applications |
| 02:42 | <&McMartin> | (The two mid-sized applications turned into "this problem is C-shaped" and "this problem is Python-shaped") |
| 02:42 | < simon_> | so the best answer I can give is: I don't know yet, I haven't socialised a lot around Rust yet. |
| 02:42 | <&McMartin> | Fair enough |
| 02:43 | < simon_> | I think it's probably a big mixture. the "procedural macros" that are used in e.g. deriving attributes are widely used. |
| 02:44 | <&McMartin> | Ah yeah. And of course println! and friends |
| 02:44 | <&McMartin> | I was mostly thinking of designs that went macro-heavy vs designs that tried to encapsulate harder behind traits |
| 02:44 | < simon_> | yeah I think those are "declarative" macros, at least if I understand it correctly. |
| 02:44 | <&McMartin> | In the very early days I got the impression that limitations on traits made the ! macros spread out into places where they were unwelcome. |
| 02:44 | < simon_> | basically, the bla! stuff takes one chunk of AST and replaces it with another, so "declarative macro" (according to the words used on doc.rust-lang.org) |
| 02:44 | <&McMartin> | Yeah, makes sense |
| 02:45 | < simon_> | and the #[cfg(test)] stuff are procedural ones |
| 02:45 | <&McMartin> | I know that try! ended up being retired in favor of special-purpose syntax later on, which is another sign to me that they might consider declarative macros unergonomic |
| 02:45 | < simon_> | so I think... there's some cut-off point where people get skeptic about macros, and that's either when the syntax gets too special, or when the derivation produces something unpredictable. |
| 02:46 | <&McMartin> | I have quite a bit more experience with C aesthetics and your description there matches my impression of them in that space. |
| 02:46 | < simon_> | so vec![1,2,3] is great because nobody disputes that that's probably {let mut v = Vec::with_capacity(3); v.push(1); v.push(2); v.push(3); v} or something like that (I'm guessing, I have no idea). |
| 02:48 | < simon_> | but I got thoroughly tired of the inflexibility of the proptest library's syntax: https://docs.rs/proptest/0.9.4/proptest/macro.proptest.html#example |
| 02:49 | < simon_> | it's like they have to go through the same trouble of Haskell's QuickCheck: sure, that type-class magic is super fancy and properties look really cool. but if you ever want to re-use a generated property because the generator is expensive, or *anything* that functions can do but these hardwired macros can't, you have to learn the functional API anyways. |
| 02:50 | < simon_> | https://github.com/tokio-rs/axum#high-level-features <- "Route requests to handlers with a macro free API." -- makes me think that there's at least some opposition to macros. maybe from a "KISS" perspective. |
| 02:51 | <&McMartin> | Yeah |
| 02:51 | <&McMartin> | From the C side, the API for https://github.com/orangeduck/mpc has intrigued me for some time |
| 02:52 | <&McMartin> | They went to great effort to make sure that the functional API is the only thing you need, with some wrappers around it that are, themselves, functional, just more data-driven |
| 02:52 | <&McMartin> | The gap between this and even the outputs of flex/bison are *profound* |
| 02:53 | < simon_> | I recall from the Haskell community that some are really into heavy TemplateHaskell while others avoid it at all costs; mostly it takes time and makes caching of compilation units impossible, so big cost on build time unless you isolate all TH into single dependencies. (Haskell has some alternatives for deriving code that doesn't rely on TemplateHaskell, and they're also moderately expensive and come in |
| 02:53 | < simon_> | hierarchies called "strategies": https://kowainik.github.io/posts/deriving#strategies) |
| 02:54 | < simon_> | McMartin, ah. yeah, that's what it's supposed to be. :) so is the 'nom' library in Rust is also purely functional. but not syntactic similar to Haskell's Parsec, sadly. |
| 02:59 | < simon_> | McMartin, I never understood why flex/bison-as-embedded-DSLs were never a thing. |
| 03:00 | < simon_> | it seems like only parser combinators were deemed worthy of being embedded. |
| 03:01 | <&McMartin> | Not actually sure what you'd describing as the missed opportunity |
| 03:01 | < simon_> | pretty big fan of this: https://hackage.haskell.org/package/regex-applicative -- in *theory*! in practice, using a non-regular parser combinator library is just as convenient. |
| 03:01 | <&McMartin> | But the language class Bison handles (LALR(1)) has a bunch of obnoxious corner nightmares |
| 03:02 | <&McMartin> | And while you can use its action-handling stuff to spin stuff together in your program, the strong consensus from the community is that it makes your code unpleasant and actively more difficult to maintain |
| 03:02 | < simon_> | I'm not even sure the distinction between LALR and LR makes sense any more? |
| 03:02 | <&McMartin> | It was always and ever only just a cheap space hack. |
| 03:03 | < simon_> | oh, so you mean LR corner cases, too? |
| 03:03 | <&McMartin> | Well, no, I meant more "you will never accidentally hit the points that are LR(1), which is easy for a human to reason about when writing a grammar, but not LALR(1), which is not" |
| 03:04 | <&McMartin> | (But yeah, in the absence of combinators, the C guys I know are all firmly on team "make the language LL(k) and just do recursive descent") |
| 03:04 | < simon_> | I had two periods writing parsers. one was as a TA for a compilers course where I used ML-lex and ML-yacc. and another was for a Haskell course (and subsequently in my spare time), using Haskell's Parsec. while I stuck with Parsec because Haskell had better ergonomics, I feel like the shift-reduce conflicts of Yacc were more... indicating of where there were problems. whereas with parser combinators, you |
| 03:04 | < simon_> | kinda had to property test with an adversarial pretty-printer (ugly-printer) to figure out if it contained unwanted behavior. |
| 03:05 | <&McMartin> | Yeah |
| 03:05 | <~Vornicus> | ...adversarial pretty printer? |
| 03:05 | <&McMartin> | Combinators don't even fit into the old classifiers, IIRC |
| 03:05 | <&McMartin> | Because Combinator parsers explicitly allow backtracking |
| 03:05 | < simon_> | Vornicus :-P yeah like print whitespace in any which way; print 0 whitespace when allowed, to see if "if0" and "if 0" are treated the same, and so on. |
| 03:05 | <~Vornicus> | aha |
| 03:06 | < simon_> | Vornicus, I saw a fellow TA do this ugly-printer to test submissions, to catch corner-cases where whitespace was improperly handled. |
| 03:07 | < simon_> | Vornicus, or use the whole alphabet for identifiers. |
| 03:10 | < simon_> | McMartin, mpc seems pretty well-made. |
| 03:11 | <&McMartin> | Yeah. I have yet to have a proper excuse to put it through its paces, but I'm keeping an eye out. |
| 03:27 | | Degi_ [Degi@Nightstar-9eq680.pool.telefonica.de] has joined #code |
| 03:28 | | Degi [Degi@Nightstar-pqruie.pool.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 03:28 | | Degi_ is now known as Degi |
| 07:47 | <~Vornicus> | https://cdn.discordapp.com/attachments/715457752666996767/991196374341255199/c.png |
| 08:21 | | Kindamoody [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [Client exited] |
| 08:31 | | Kimo|autojoin [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
| 08:31 | | mode/#code [+o Kimo|autojoin] by ChanServ |
| --- Log closed Tue Jun 28 08:39:01 2022 |
| --- Log opened Tue Jun 28 08:44:07 2022 |
| 08:44 | | TheWatcher [chris@GlobalOperator.Nightstar.Net] has joined #code |
| 08:44 | | Irssi: #code: Total of 26 nicks [15 ops, 0 halfops, 0 voices, 11 normal] |
| 08:44 | | mode/#code [+o TheWatcher] by ChanServ |
| 08:44 | | Irssi: Join to #code was synced in 14 secs |
| 09:39 | < FLHerne> | https://lkml.org/lkml/2022/6/27/2322 Not a new sentiment, but well put |
| 10:41 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [[NS] Quit: -a- Connection Timed Out] |
| 10:41 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 11:04 | | Kimo|autojoin is now known as Kindamoody |
| 14:26 | < simon_> | heh. I just learned about a variant of Brainfuck called Smallfuck where the byte array becomes a bit array, and +/- become "flip". |
| 14:29 | < simon_> | I've wanted something Turing-complete for which you can express correct execution by arithmetizing the language rules into constraint polynomials; I've already got language rules for Brainfuck, and the Smallfuck ones are just a genetic degradation of those. |
| 14:30 | < simon_> | I can't imagine many proofs-of-concept where Smallfuck gives you any benefit over Brainfuck; but these constraint polynomials live just around the ceiling of my current understanding, so dumb simplifications like these fit perfectly with being able to finish this. |
| 15:16 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Connection reset by peer] |
| 15:17 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 16:40 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 16:40 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Connection closed] |
| 17:26 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has joined #code |
| 20:02 | <&McMartin> | I know that language as boolfuck, and it's an instructional tool for bitmask operations IME. |
| 22:54 | | Kindamoody is now known as Kindamoody[zZz] |
| 23:48 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
| --- Log closed Wed Jun 29 00:00:44 2022 |