Conversation

Notices

1. pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Feb-2025 19:16:13 JST pistolero
   # I don't know if "deletion is meaningless in this context" should
   # return an error or not. I'm going to gamble and say that "fail
   # successfully" is the appropriate course of action but include the
   # alternative version as a hedge.
   @impl true
   def delete_file(_), do: :ok
   #def delete_file(_), do: {:error, "This is fine."}
   • † top dog :pedomustdie: likes this.
   •  (mint@ryona.agency)'s status on Tuesday, 18-Feb-2025 19:20:31 JST 

     in reply to
     @p Isn't "failing successfully" the whole point of Erlang/Elixir?
     † top dog :pedomustdie: likes this.
   •  (mint@ryona.agency)'s status on Tuesday, 18-Feb-2025 19:21:38 JST 

     in reply to

     • 
     @p https://en.wikipedia.org/wiki/Erlang_(programming_language)?useskin=vector#"Let_it_crash"_coding_style
   • pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Feb-2025 19:37:22 JST pistolero

     in reply to

     • 
     @mint That style you can't actually use in Phoenix: it just sends back a 5xx error for things that should be a 4xx. You're supposed to have a lot of these little processes, all of which fit on half a page, and when one of them breaks, it's handled upstream.
      and † top dog :pedomustdie: like this.
   • pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Feb-2025 19:37:40 JST pistolero

     in reply to

     • 
     @mint I don't know about Elixir as a whole but there seems to be a lot of bullshit where, like, something is plucked from an implicit expected structure returned by one of the functions in a module, and you have to read the entire call stack because you can't just test it interactively because there are 20 lines of destructive context built up. I think there is a bug in one of the existing uploaders but I don't know if the bug is still there or if I'm reading it wrong.
     
     I don't think the way pattern-matching is used lends itself to code that is easier to read or write or debug or even spot the bugs in. I shit out all those MRFs and a lot of them have comments or commit messages indicating that the code is bad but I eventually just stopped making a note of that because it applies to all of them. Trying to write "good" code to fit into Pleroma has
     
     I say "the way pattern-matching is used" and I can't say for certain whether this has to do with the project or the APIs the project has to use or if every Elixir codebase looks like this. I pretty strongly suspect that this is the ecosystem/language's fault. Phoenix reeks of a design that was conceived by Rails fetishists, and Rails is one of the worst designs you can come up with.
     
     I want to conform to an interface, play nice with the internal tooling, and that's 95% of the effort. The other 5% of the effort is calling two upstream endpoints. I think these ratios are backwards.
      and † top dog :pedomustdie: like this.
   • pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Feb-2025 20:04:41 JST pistolero

     in reply to

     • 
     @mint Like, I can't actually use this API as-is because it's for shipping JSON around and it silently discards other parameters if you upload a file and it only lets you upload one (so much for the "multi" part of "multipart"): https://git.freespeechextremist.com/gitweb/?p=fse;a=blob;f=lib/pleroma/http.ex;h=052597191fcc90d48641217f6002418462893031;hb=HEAD#l61 . So I have to take a step down and just talk to Tesla and build the multipart request myself if I'm trying to make something you can drop into Pleroma instead of something that requires changes to Pleroma; fine, I don't mind, this is called "programming", I can do that.
     
     Tesla returns `{:ok, {status: whatever}}` as long as the request succeeds, and then you handle the status being 200 or 201 or 401 or what-have-you. That's sensible, that's what you want, you want the client library to tell you that there was an error if the server couldn't be reached or if it responds with non-HTTP shit and that it was fine as long as the round-trip worked out and then 2xx vs. 4xx is application logic.
     
     But just eyeballing it, if the S3 library they're using works that way, there's a bug where if the upstream server behaves weirdly, Pleroma won't have a clue that this happened because it just assumes the server didn't return anything weird: https://git.freespeechextremist.com/gitweb/?p=fse;a=blob;f=lib/pleroma/uploaders/s3.ex;h=6dbef90856c2fba0f9f5bddc52d56743cef7c81d;hb=HEAD#l40 . A little lower, delete_file() checks status_code so it looks like ExAws.request/1 returns an object that has a status code in it, so it *looks* like the put_file code assumes it has succeeded in cases where it hasn't. But it's hard to tell, because https://hexdocs.pm/ex_aws_s3/ExAws.S3.html#put_object/4 doesn't seem to say.
     
     In a lot of cases, Elixir seems like it's fighting Erlang; it's forcing some infelicities in control flow that end up erasing the niceness you'd get from pattern-matching.
      likes this.
   • pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Feb-2025 20:13:29 JST pistolero

     in reply to

     • 
     @mint The more I look at this, the more that I begin to think that Elixir is the product of a deranged mind and that the language's reach has exceeded its grasp.
     
     99% of the time that you start second-guessing the language, you're wrong and you just haven't bent your mind enough to see the language from its own perspective. It's like thinking there's a bug in the compiler when you're new to a language: the bug is almost certainly in your program, not in the compiler, and you don't understand the language well enough to have a mental model of the compiler. But when I think "No, Elixir's not terrible, you just need to think harder", I can't shake the memory of seeing ".DS_Store" come out of the zip file from the official distribution and the fact that they keep making minor releases of the language that are completely incompatible with previous versions and the entire deps thing is a goddamn fiasco and I think maybe I'm correct to second-guess the language/ecosystem when I have to hand off happy-path to another function and then handle a bunch of errors inline and then I look to see how other code handles these errors and it just pretends they didn't happen.
      and † top dog :pedomustdie: like this.
   • :blank: (i@declin.eu)'s status on Tuesday, 18-Feb-2025 21:05:53 JST :blank:

     in reply to

     • 
     @p @mint if there was a way to enforce good engineering, there might not have been a need to go past cobol
     
     would be funny if this exact issue was the reason a bunch of people are failing to upload their media and not knowing why
      likes this.
   •  (mint@ryona.agency)'s status on Tuesday, 18-Feb-2025 21:07:27 JST 

     in reply to

     • :blank:
     @i @p https://github.com/azac/cobol-on-wheelchair
     https://github.com/askadian/CobolJsonParser
     Building blocks for cobolverse are there.
   • pistolero (p@fsebugoutzone.org)'s status on Tuesday, 18-Feb-2025 22:08:26 JST pistolero

     in reply to

     • 
     • :blank:
     @i @mint
     
     > if there was a way to enforce good engineering, there might not have been a need to go past cobol
     
     That's like saying that proper engineering could have gotten us skyscrapers out of balsa wood. A programming language doubles as "substrate for building" and "medium of thought"; it's way more than just good engineering discipline.
     
     > would be funny if this exact issue was the reason a bunch of people are failing to upload their media and not knowing why
     
     I should probably report it but I'd have to dig through the docs more and I'd also have to check to see if it's changed: it might have been completely rewritten by now. (I had to link to the FSE repo, because if it *has* been rewritten then no one would know what I was talking about.)
      likes this.