4 ms·

I'm starting to get a bit of fatigue for these projects that boil down to just "I asked Claude to re-write this code into a new language that's in vogue right n

I'm starting to get a bit of fatigue for these projects that boil down to just "I asked Claude to re-write this code into a new language that's in vogue right now!" I really don't understand why this is needed outside of an opportunity to show how impressive LLMs can be when working within large codebases, but even then people in the comments are finding bizarre implementation choices that a human developer wouldn't make. I'll stick with Postgres and its - gasp - C implementation for now, thanks.

verytrivial 3mo ago
[dead]
rjh29 3mo ago
In this case it's justified because Rust allows safe implementation of threaded code. Current Postgres is per-process. Switching to threading yields performance improvements.
- solid_fuel 3mo ago
  > Current Postgres is per-process. Switching to threading yields performance improvements. Please describe in detail what you believe this means and the mechanism by which switching from processes to threads improves performance.
  - rjh29 3mo ago
    There are hundreds of comment chains about this already, go troll somewhere else.
    - solid_fuel 3mo ago
      If you’re going to make a confident blanket claim, be ready to back it up - and asking for clarification is not trolling, by the way. You should be ready to engage in technical conversations if you want to make technical claims.
      - cowboylowrez 3mo ago
        There is an expectation that threads are more performant than processes all else being equal. Obviously there is some work involved to make "all else be equal", like maybe threads have less isolation from each other etc but if you can mechanically convert code to use threads where it used to use processes I can see the claim standing up.
        solid_fuel 3mo ago
        Threads generally have less memory overhead and context switching between them is theoretically faster, but as I suspect you know it is situational and not as simple as just s/process/thread/g. There are many tradeoffs, including the loss of memory isolation, and since Postgres is a network application which holds a rather important position in most architectures, proper memory isolation is very important. Switching to threads doesn't guarantee weaker isolation, just like it doesn't guarantee better performance, but those nuances are why "switching to threading yields performance improvements" is over simplified to the point of uselessness. It simply reeks of the same kind of ignorance that used to drive statements like "rust doesn't have vulnerabilities" and "rewrite it in javascript for web scale performance".
        cowboylowrez 3mo ago
        I do agree, but maybe there is a valid mechanical conversion thats applicable in the postgresql codebase? I do get what you're saying but on the other hand, if he's passing tests with his conversion then this is different than some hypothetical, I'm just saying I would believe his claim on this one. I'm not going to port my erp to it yet but the performance win could actually be there.
      - rjh29 3mo ago
        I'm not interested in a technical conversation with you; I was answering someone else. The top voted comment thread of this page, which dominates discussion, already covers everything you'd want to know.

verytrivial 3mo ago

[dead]

rjh29 3mo ago

In this case it's justified because Rust allows safe implementation of threaded code. Current Postgres is per-process. Switching to threading yields performance improvements.

solid_fuel 3mo ago
> Current Postgres is per-process. Switching to threading yields performance improvements. Please describe in detail what you believe this means and the mechanism by which switching from processes to threads improves performance.
- rjh29 3mo ago
  There are hundreds of comment chains about this already, go troll somewhere else.
  - solid_fuel 3mo ago
    If you’re going to make a confident blanket claim, be ready to back it up - and asking for clarification is not trolling, by the way. You should be ready to engage in technical conversations if you want to make technical claims.
    - cowboylowrez 3mo ago
      There is an expectation that threads are more performant than processes all else being equal. Obviously there is some work involved to make "all else be equal", like maybe threads have less isolation from each other etc but if you can mechanically convert code to use threads where it used to use processes I can see the claim standing up.
      - solid_fuel 3mo ago
        Threads generally have less memory overhead and context switching between them is theoretically faster, but as I suspect you know it is situational and not as simple as just s/process/thread/g. There are many tradeoffs, including the loss of memory isolation, and since Postgres is a network application which holds a rather important position in most architectures, proper memory isolation is very important. Switching to threads doesn't guarantee weaker isolation, just like it doesn't guarantee better performance, but those nuances are why "switching to threading yields performance improvements" is over simplified to the point of uselessness. It simply reeks of the same kind of ignorance that used to drive statements like "rust doesn't have vulnerabilities" and "rewrite it in javascript for web scale performance".
        cowboylowrez 3mo ago
        I do agree, but maybe there is a valid mechanical conversion thats applicable in the postgresql codebase? I do get what you're saying but on the other hand, if he's passing tests with his conversion then this is different than some hypothetical, I'm just saying I would believe his claim on this one. I'm not going to port my erp to it yet but the performance win could actually be there.
    - rjh29 3mo ago
      I'm not interested in a technical conversation with you; I was answering someone else. The top voted comment thread of this page, which dominates discussion, already covers everything you'd want to know.