3 ms·

You make an assumption here that the software is also constant or static. > There's a constant low-level flow of "we switched from X to Y and got Z% speedup" a

by dlisboa 11mo ago

You make an assumption here that the software is also constant or static. > There's a constant low-level flow of "we switched from X to Y and got Z% speedup" articles on HN, and while the details of the articles are often quite interesting, with rare exceptions I find that I read them and conclude that it was an error to ever have used X in the first place and the team should have been able to tell immediately that it wasn't going to be a good solution. The language X was probably a good solution at first. Then the company started to increase its product surface or acquired enterprise customers. Now you have new workloads that were not considered and the language is no longer suited for it. Most likely a decision is made to not introduce a second language to the company just for these new workloads as that complicates the architecture, not to mention hiring and managing, so you stay with language X and try to make do. Now you have language X doing more than it is suited for and response times often increase due to that. This isn't really a case of startup growing pains, just that software itself cannot know ahead of time every application it'll have. You can choose a "mostly fast for all use cases" language and bet that your applications will fit those general use cases, this means you win small but also lose small.

pdimitar 11mo ago
> The language X was probably a good solution at first. I would contest even that. Most of the time it's a fight or flight response by the devs, meaning that they just go with whatever they are most comfortable with. In the previous years I made good money from switching companies away from Python and Rails, to Elixir and Golang. The gains were massive and maintainability also improved a lot. Of course, this is not advocacy for these technologies in particular. Use the right tool for the job is a popular adage for good reasons. But my point is: people don't use the right tool for the job as often as many believe. Mostly it's gut feelings and familiarity. And btw I am not trashing on overworked CTOs opting for Python because they never had the time to learn better web tech. I get their pain and sympathise with it a lot. But the failing of most startup CTOs that I observed was that they fell into control mania and micro-management as opposed to learning to delegate and trust. Sadly that too is a function of being busy and overworked so... I don't know. I feel for them but I still want better informed tech decisions being made. At my age and experience I am extremely tired and weary of seeing people make all the same mistakes every time.
- Retric 11mo ago
  Between Python and Elixir or Golang, I’ll stick with Python for an exploratory side project. It’s just a better fit when you’re not quite sure what you’re building. You just gain more on the 99% of projects that never go anywhere than you lose on the one that you end up trying to turn into a real product. So calling them better web tech assumes a lot about the development process that isn’t guaranteed.
  - pdimitar 11mo ago
    You might be proving my point here because Elixir is amazing for exploration. You literally generate a project and then can immediately fiddle with it to your heart's content in a REPL. As said though, I don't judge people who go by familiarity. But one should keep an open mind, and learning some of the modern languages (like Elixir) is much less work than many believe. A better web tech in this case refers to having the potential to scale far above what Python can offer + have a very good developer experience. To me those two are paramount.
    - Retric 11mo ago
      You can do a similar Python REPL. So I’m really unsure what you mean here? I mean it’s a little better for displaying data structures but I never really found that particularly useful.
      - pdimitar 11mo ago
        Okay. Not contesting that. Use what you like. My point here was that one does not have to choose between "easy to use and iterate with" and "future-proof". These days you can have both. Elixir, Golang and Rust seem to offer those. Python in my experience only has the former, in terms of performance that inevitably ends up being a bottleneck at one point. It's also true that many projects will never hit that point. For those Python is just fine. But I prefer to cover my bases in the last years, and have not been disappointed by any of the 3 PLs above. RE: your edit, Elixir's REPL allows modifying the app in-place but I have not worked with Python in a long time and it might have that as well. Can't remember. Also you can temporarily change an app in production which made fixing certain elusive bugs almost trivial, many times. As much as I love Golang and Rust they got nothing on Elixir's ability to fix your app literally in real time. Then when you are confident in the fix, you make the actual code change, merge it and deploy.

by dlisboa 11mo ago

pdimitar 11mo ago

> The language X was probably a good solution at first. I would contest even that. Most of the time it's a fight or flight response by the devs, meaning that they just go with whatever they are most comfortable with. In the previous years I made good money from switching companies away from Python and Rails, to Elixir and Golang. The gains were massive and maintainability also improved a lot. Of course, this is not advocacy for these technologies in particular. Use the right tool for the job is a popular adage for good reasons. But my point is: people don't use the right tool for the job as often as many believe. Mostly it's gut feelings and familiarity. And btw I am not trashing on overworked CTOs opting for Python because they never had the time to learn better web tech. I get their pain and sympathise with it a lot. But the failing of most startup CTOs that I observed was that they fell into control mania and micro-management as opposed to learning to delegate and trust. Sadly that too is a function of being busy and overworked so... I don't know. I feel for them but I still want better informed tech decisions being made. At my age and experience I am extremely tired and weary of seeing people make all the same mistakes every time.

Retric 11mo ago
Between Python and Elixir or Golang, I’ll stick with Python for an exploratory side project. It’s just a better fit when you’re not quite sure what you’re building. You just gain more on the 99% of projects that never go anywhere than you lose on the one that you end up trying to turn into a real product. So calling them better web tech assumes a lot about the development process that isn’t guaranteed.
- pdimitar 11mo ago
  You might be proving my point here because Elixir is amazing for exploration. You literally generate a project and then can immediately fiddle with it to your heart's content in a REPL. As said though, I don't judge people who go by familiarity. But one should keep an open mind, and learning some of the modern languages (like Elixir) is much less work than many believe. A better web tech in this case refers to having the potential to scale far above what Python can offer + have a very good developer experience. To me those two are paramount.
  - Retric 11mo ago
    You can do a similar Python REPL. So I’m really unsure what you mean here? I mean it’s a little better for displaying data structures but I never really found that particularly useful.
    - pdimitar 11mo ago
      Okay. Not contesting that. Use what you like. My point here was that one does not have to choose between "easy to use and iterate with" and "future-proof". These days you can have both. Elixir, Golang and Rust seem to offer those. Python in my experience only has the former, in terms of performance that inevitably ends up being a bottleneck at one point. It's also true that many projects will never hit that point. For those Python is just fine. But I prefer to cover my bases in the last years, and have not been disappointed by any of the 3 PLs above. RE: your edit, Elixir's REPL allows modifying the app in-place but I have not worked with Python in a long time and it might have that as well. Can't remember. Also you can temporarily change an app in production which made fixing certain elusive bugs almost trivial, many times. As much as I love Golang and Rust they got nothing on Elixir's ability to fix your app literally in real time. Then when you are confident in the fix, you make the actual code change, merge it and deploy.