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.
> 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.
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.
My crossover point for where I'd rather be using a static language than a dynamic one for exploration is about a week in the modern era.
In 1999 I'd agree with you completely, but static languages have gotten a lot better.
There are some cases where libraries may entirely dominate such a discussion, e.g., if you know Ruby on Rails and you have a problem right up its alley then that may blow away anything you can get in a static language. But for general tasks I find static languages get an advantage even in prototyping pretty quickly nowadays. What extra you pay generally comes back many times over in the compiler's instant feedback.
And for context, I would have called Python my favorite language from about 2000 to probably 2015 or so. This preference wasn't from lack of familiarity. Heck, I don't even regret it; if I had 2000 to 2015 to do all over again I'm not sure I'd do much differently. Static languages kind of sucked for a good long time.
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.
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.
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.
Sure Elixir is fine to work with, the thing is in the back of my mind I’m thinking it’s way more likely to end up embedding Python libraries in Elixir code than the reverse. It’s those little bits of friction that I’m avoiding because the start of a project is play. Soon enough the perfectionist side of me may get involved, until then the goal is to maximize fun so I actually start.
Anyway I get your standpoint and even somewhat agree, it just doesn’t work for me.
> 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.