4 ms·

``` First of all, it does not take "that much machine" to serve a fair number of clients. Ever since I wrote about the whole Python/Gunicorn/Gevent mess a coup

``` First of all, it does not take "that much machine" to serve a fair number of clients. Ever since I wrote about the whole Python/Gunicorn/Gevent mess a couple of months back, people have been asking me "if not that, then what". It got me thinking about alternatives, and finally I just started writing code. ``` Another day, another questionable premise for a blog post. No, @rachelbythebay, the question is not "if not that, then what", and the answer is not reinventing the wheel. The question is just "what ___" -- what do you plan on doing, what does your software need to do, what does it need to support? Use the right tool for the right job. If you have a language you're proficient in and with an ecosystem that supports you developing something rapidly, it's borderline malpractice not to start there. When you need to optimize, optimize then. Maybe that means you carve out a subcomponent into a new service, and you choose a language purpose built for speedily doing what you need. Maybe it means a lot of things, but it doesn't mean you throwing out the baby with the bathwater and setting out to recreate the baby, the bathtub, and the bathwater from scratch to answer the question of why your tub is overflowing. I wish this blog post was about solving real engineering problems instead of writing code to provide mediocre answers to poor questions.

Aeolun 6y ago
> If you have a language you're proficient in and with an ecosystem that supports you developing something rapidly, it's borderline malpractice not to start there. I think the point of this post is that most new programmers do not know things can be faster than their monstrous JS blob. The solution to slow requests is more servers instead of fixing the code.
- WilliamEdward 6y ago
  In what way is this helpful to newcomers at all? It uses a ton of heavy jargon and no example code.
  - chris_wot 6y ago
    It’s not aimed at introductory programmers. It’s aimed at more experienced programmers to suggest to them that they can show new programmers what’s possible.
    - epicide 6y ago
      The author never really expresses the intent of the writing, so the reader is left to assume it is meant for them -- experienced programmer or no.
      - andrewflnr 6y ago
        People don't need to explicitly audience-tag every single thing they write. I don't know if "entitled" is the right word, but it's really an annoying demand. Most times, if you can understand something, or are willing to Google the jargon, then you're part of the audience, and that's plenty of precision.
        epicide 6y ago
        I can Google medical terms until I pass out, but that doesn't make me the intended audience for a medical research paper. Besides, I'm not suggesting (or "demanding") that all articles explicitly state their target audience. Just that this one does a poor job of indicating it. So I think it's a poor argument when the parent comment (to which I was responding) assumes an exclusive target audience: "not introductory programmers... more experienced programmers". You could argue that one was supposed to assume that from context. However, I didn't make that assumption whilst reading, so I especially wouldn't expect "introductory programmers" to pick up on that either.
        kragen 6y ago
        You can probably understand most medical research papers after reading a few dozen medical Wikipedia articles and taking an introductory stats class. Math and physics research is a little more difficult.
      - 6y ago
- Doxin 6y ago
  > I think the point of this post is that most new programmers do not know things can be faster Related to this: programmers who know an ORM or two but never learn SQL proper. At my job I refactored a giant, slow, memory hungry reporting task into a single sql query. It used to take 10s of minutes to collate 1000s of datapoints. Now it takes 10s of miliseconds to collate a factor 10 more data. Never mind after I added some indexes to speed the thing up. Knowing about the layer below the abstraction you're working at can be rather useful at times.
  - yowlingcat 6y ago
    What's telling here is that you refactored the individual task into a single query, and nothing outside of that. That's fantastic! You scoped your work into a small unit and derived a significant impact. You maximized your impact to effort ratio. Notably, you did NOT decide to write your own dialect of SQL to "scratch an itch". Knowing the layer below the abstraction you're working at can be useful at times, but only in relation to understanding the context of how all the layers fit together and making effective, pragmatic decisions. Pointless rewrites are anything but. Good on you for avoiding that impulse and doing the right thing.
- yowlingcat 6y ago
  It's fascinating that you see the misguided impulse being prematurely adding more servers rather than fixing the code. I would agree with that, but I would also see the premise of this blog post as a similar misguided impulse -- rather than fixing the code, writing a completely new part of infrastructure from scratch in a new language because the old one wasn't good enough. Unless you've exhausted reasonable attempts to optimize existing code inside the language the original code was written in, I believe that following this impulse would be (as I alluded to in my original comment) borderline malpractice.

Aeolun 6y ago

> If you have a language you're proficient in and with an ecosystem that supports you developing something rapidly, it's borderline malpractice not to start there. I think the point of this post is that most new programmers do not know things can be faster than their monstrous JS blob. The solution to slow requests is more servers instead of fixing the code.

WilliamEdward 6y ago
In what way is this helpful to newcomers at all? It uses a ton of heavy jargon and no example code.
- chris_wot 6y ago
  It’s not aimed at introductory programmers. It’s aimed at more experienced programmers to suggest to them that they can show new programmers what’s possible.
  - epicide 6y ago
    The author never really expresses the intent of the writing, so the reader is left to assume it is meant for them -- experienced programmer or no.
    - andrewflnr 6y ago
      People don't need to explicitly audience-tag every single thing they write. I don't know if "entitled" is the right word, but it's really an annoying demand. Most times, if you can understand something, or are willing to Google the jargon, then you're part of the audience, and that's plenty of precision.
      - epicide 6y ago
        I can Google medical terms until I pass out, but that doesn't make me the intended audience for a medical research paper. Besides, I'm not suggesting (or "demanding") that all articles explicitly state their target audience. Just that this one does a poor job of indicating it. So I think it's a poor argument when the parent comment (to which I was responding) assumes an exclusive target audience: "not introductory programmers... more experienced programmers". You could argue that one was supposed to assume that from context. However, I didn't make that assumption whilst reading, so I especially wouldn't expect "introductory programmers" to pick up on that either.
        kragen 6y ago
        You can probably understand most medical research papers after reading a few dozen medical Wikipedia articles and taking an introductory stats class. Math and physics research is a little more difficult.
    - 6y ago
Doxin 6y ago
> I think the point of this post is that most new programmers do not know things can be faster Related to this: programmers who know an ORM or two but never learn SQL proper. At my job I refactored a giant, slow, memory hungry reporting task into a single sql query. It used to take 10s of minutes to collate 1000s of datapoints. Now it takes 10s of miliseconds to collate a factor 10 more data. Never mind after I added some indexes to speed the thing up. Knowing about the layer below the abstraction you're working at can be rather useful at times.
- yowlingcat 6y ago
  What's telling here is that you refactored the individual task into a single query, and nothing outside of that. That's fantastic! You scoped your work into a small unit and derived a significant impact. You maximized your impact to effort ratio. Notably, you did NOT decide to write your own dialect of SQL to "scratch an itch". Knowing the layer below the abstraction you're working at can be useful at times, but only in relation to understanding the context of how all the layers fit together and making effective, pragmatic decisions. Pointless rewrites are anything but. Good on you for avoiding that impulse and doing the right thing.
yowlingcat 6y ago
It's fascinating that you see the misguided impulse being prematurely adding more servers rather than fixing the code. I would agree with that, but I would also see the premise of this blog post as a similar misguided impulse -- rather than fixing the code, writing a completely new part of infrastructure from scratch in a new language because the old one wasn't good enough. Unless you've exhausted reasonable attempts to optimize existing code inside the language the original code was written in, I believe that following this impulse would be (as I alluded to in my original comment) borderline malpractice.