3 ms·

> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's

> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.) This is the part that's going to sting. I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert their own pet tech here) can _by itself_ make your startup successful. Whereas the sad truth is that choosing the wrong tech can definitely _kill_ your shop, but choosing the "right" one will not ensure its survival...

npc12345 2y ago
[dead]
vertis 2y ago
The key here though is that choosing a bleeding edge tech is more likely to be a problem because it's fairly untested. I can tell you what ALL the problems with rails are. For the most part they won't even start to bite you until you hit scaling problems. By the time you hit scaling problems with Rails you can probably afford to pay engineers to solve the scaling problems, and/or port off at that point. I love sveltekit and use it a bunch for my own personal projects, but it's too immature to recommend to others. Instead I mostly point them at Next.js if they want a javascript stack and Rails if they don't. I have created and maintained apps based on both platforms for 6 and 16 years respectively and know exactly what I'm recommending to people.
- jkoudys 2y ago
  I was big on Rails scene when it was huge in 2008, and saw a big exodus from it. I found so many of the "Rails" problems were solved by learning two languages: ruby, and sql. People would go to crazy lengths to avoid looking at the queries they'd actually run. I can admit to not really learning ruby as a language by itself, and can now see how much better my old code would've been if I wasn't just blindly shoehorning Railscasts in there. Similar problems for people who learned angular but not typescript, laravel but not php, etc.
causal 2y ago
When software engineers start a business, it's easy for them to hyperfixate on technical decisions because those are the types of problems they understand well enough to optimize.
- jkoudys 2y ago
  Yep. The problem with the story of bikeshedding is that it assumes people know bike sheds but not nuclear reactors. There are plenty of cases of people who are great at nuclear reactor design but have no idea how workers should park their bicycles.
_heimdall 2y ago
I've seen a really interesting pattern play out a few times now. A startup needs to raise money and hitches onto the latest tech stack that grabs investors' attention. The startup raises on a valuation inflated based partly on the tech stack itself, meaning enough attention isn't given to the actual product or business model. Ultimately the startup runs into money problems when they can't live up to the tech stack hype and the valuation that went with it. I saw this first hand with a startup picking Plaentscale early on. There's nothing wrong with the product and it solves certain problems really well, but I saw one particular startup grab it early because it was getting a lot of attention and completely missed that the limitations of Planet scale ran smack in the face of what the startup wanted to build.
- samlambert 2y ago
  what limitations? PlanetScale has public companies running on top of it. If a startup found limitations then its a skill issue.
  - _heimdall 2y ago
    This was when foreign keys still weren't supported by Planetscale. The specific data model was heavily relational and queries were very inefficient without foreign key support. Distributed writes were also important, and if I remember right those weren't supported either though that's a really common limitation. Assuming a particular tool works for all situations because it works for some is a mistake though. Plenty of companies use all kinds of tools, they're picked to match the specific use case and there is no magic bullet.
    - spudlyo 2y ago
      > The specific data model was heavily relational and queries were very inefficient without foreign key support. I can't help but wonder if you're conflating the notion foreign keys (and the usefulness of having them be indexed) and foreign key constraints, which ensure data integrity at the expense of write performance. I have a narrow view of the performance of MySQL foreign key constraints and would be interested in learning of cases where they might actually improve certain queries.

npc12345 2y ago

[dead]

vertis 2y ago

The key here though is that choosing a bleeding edge tech is more likely to be a problem because it's fairly untested. I can tell you what ALL the problems with rails are. For the most part they won't even start to bite you until you hit scaling problems. By the time you hit scaling problems with Rails you can probably afford to pay engineers to solve the scaling problems, and/or port off at that point. I love sveltekit and use it a bunch for my own personal projects, but it's too immature to recommend to others. Instead I mostly point them at Next.js if they want a javascript stack and Rails if they don't. I have created and maintained apps based on both platforms for 6 and 16 years respectively and know exactly what I'm recommending to people.

jkoudys 2y ago
I was big on Rails scene when it was huge in 2008, and saw a big exodus from it. I found so many of the "Rails" problems were solved by learning two languages: ruby, and sql. People would go to crazy lengths to avoid looking at the queries they'd actually run. I can admit to not really learning ruby as a language by itself, and can now see how much better my old code would've been if I wasn't just blindly shoehorning Railscasts in there. Similar problems for people who learned angular but not typescript, laravel but not php, etc.

causal 2y ago

When software engineers start a business, it's easy for them to hyperfixate on technical decisions because those are the types of problems they understand well enough to optimize.

jkoudys 2y ago
Yep. The problem with the story of bikeshedding is that it assumes people know bike sheds but not nuclear reactors. There are plenty of cases of people who are great at nuclear reactor design but have no idea how workers should park their bicycles.

_heimdall 2y ago

I've seen a really interesting pattern play out a few times now. A startup needs to raise money and hitches onto the latest tech stack that grabs investors' attention. The startup raises on a valuation inflated based partly on the tech stack itself, meaning enough attention isn't given to the actual product or business model. Ultimately the startup runs into money problems when they can't live up to the tech stack hype and the valuation that went with it. I saw this first hand with a startup picking Plaentscale early on. There's nothing wrong with the product and it solves certain problems really well, but I saw one particular startup grab it early because it was getting a lot of attention and completely missed that the limitations of Planet scale ran smack in the face of what the startup wanted to build.

samlambert 2y ago
what limitations? PlanetScale has public companies running on top of it. If a startup found limitations then its a skill issue.
- _heimdall 2y ago
  This was when foreign keys still weren't supported by Planetscale. The specific data model was heavily relational and queries were very inefficient without foreign key support. Distributed writes were also important, and if I remember right those weren't supported either though that's a really common limitation. Assuming a particular tool works for all situations because it works for some is a mistake though. Plenty of companies use all kinds of tools, they're picked to match the specific use case and there is no magic bullet.
  - spudlyo 2y ago
    > The specific data model was heavily relational and queries were very inefficient without foreign key support. I can't help but wonder if you're conflating the notion foreign keys (and the usefulness of having them be indexed) and foreign key constraints, which ensure data integrity at the expense of write performance. I have a narrow view of the performance of MySQL foreign key constraints and would be interested in learning of cases where they might actually improve certain queries.