3 ms·

How come all those unicorns were built with intolerable Python/Ruby, not Java/C#/Go? https://charliereese.ca/y-combinator-top-50-software-startups/ https://cha

by hbrn 2y ago

How come all those unicorns were built with intolerable Python/Ruby, not Java/C#/Go? https://charliereese.ca/y-combinator-top-50-software-startups/ https://charliereese.ca/y-combinator-top-50-software-startup...

junyjujfjf 2y ago
They are likely leveraging Django/Rails which treads the beaten path for Startups. Startups are also more likely to do monoliths. For Enterprise & microservices, you will start to see more Java/Go/C#.
- liontwist 2y ago
  This distinction makes no sense. Can you explain why types would be more relevant?
  - junyjujfjf 2y ago
    Actually I don't think types are relevant here. People are choosing based on other weighted factors like toolchain, ecosystem, products, and culture.
    - liontwist 2y ago
      Are you a bot?
- hbrn 2y ago
  I would expect dynamic type crowd to embrace microservices first, given how everybody says that dynamic codebases are a huge mess. Regardless, to me enterprise represents legacy, bureaucracy, incidental complexity, heavy typing, stagnation. I understand that some people would like to think that heavy type-reliance is a way for enterprise to address some of it's inherent problems. But I personally believe that it's just another symptom of enterprise mindset. Long-ass upfront design documents and "designing the layout of the program in types first" are clearly of the same nature. It's no surprise that Typescript was born at Microsoft. You want your company to stagnate sooner? Hyperfixate on types. Now your startup can feel the "joys" of enterprise even at the seed stage.
  - josephg 2y ago
    Eh. The amount of work it takes to specify your types in a typescript program is tiny. Type inference does almost all of the work. And the benefit of that work is largely felt in maintenance & onboarding, since the code is easier to read when you’re new and come back to later. Refactoring large JavaScript programs is a nightmare. The real enterprise death doesn’t come from types. It comes from tasteless over use of classes - especially once you have a complex web of long lived objects that and all reference each other. Significant portions of code in these codebases ends up dedicated to useless tasks like lifecycle management instead of the actual work of your application. It’s kind of the code version of corporate beaurocracy - classes everywhere devoted to doing BS jobs. It’s not complicated people. Just write the code that tells the computer what you want it to do. No more. Unnecessary encapsulation and premature abstraction will kill your velocity dead.
sethammons 2y ago
My previous unicorn rose despite the initial tech, not because of it
- hbrn 2y ago
  I gave you a selection of top 50 startups out of thousands funded by YC. You're giving me one anecdote.
IshKebab 2y ago
Proper engineering isn't that much of a concern when you have 0 customers, and by the time you have some it's too late to change. Besides nobody is claiming that it's impossible to build a successful products with dynamic typing. It's just not as good. You can build a successful product with zero comments in your codebase, doesn't mean it's a good idea.
- hbrn 2y ago
  > It's just not as good Again, the evidence (as limited as it is) suggests otherwise. You are more likely to succeed if you're going with dynamic language and not doing "proper engineering". This has been widely accepted before type-checker era, and I see no reason why it would be different now. Utilize type checker when it's free, but don't waste time on type puzzles. "Proper engineering" doesn't get you to product-market fit faster. All it does is tickle your ego.

by hbrn 2y ago

junyjujfjf 2y ago

They are likely leveraging Django/Rails which treads the beaten path for Startups. Startups are also more likely to do monoliths. For Enterprise & microservices, you will start to see more Java/Go/C#.

liontwist 2y ago
This distinction makes no sense. Can you explain why types would be more relevant?
- junyjujfjf 2y ago
  Actually I don't think types are relevant here. People are choosing based on other weighted factors like toolchain, ecosystem, products, and culture.
  - liontwist 2y ago
    Are you a bot?
hbrn 2y ago
I would expect dynamic type crowd to embrace microservices first, given how everybody says that dynamic codebases are a huge mess. Regardless, to me enterprise represents legacy, bureaucracy, incidental complexity, heavy typing, stagnation. I understand that some people would like to think that heavy type-reliance is a way for enterprise to address some of it's inherent problems. But I personally believe that it's just another symptom of enterprise mindset. Long-ass upfront design documents and "designing the layout of the program in types first" are clearly of the same nature. It's no surprise that Typescript was born at Microsoft. You want your company to stagnate sooner? Hyperfixate on types. Now your startup can feel the "joys" of enterprise even at the seed stage.
- josephg 2y ago
  Eh. The amount of work it takes to specify your types in a typescript program is tiny. Type inference does almost all of the work. And the benefit of that work is largely felt in maintenance & onboarding, since the code is easier to read when you’re new and come back to later. Refactoring large JavaScript programs is a nightmare. The real enterprise death doesn’t come from types. It comes from tasteless over use of classes - especially once you have a complex web of long lived objects that and all reference each other. Significant portions of code in these codebases ends up dedicated to useless tasks like lifecycle management instead of the actual work of your application. It’s kind of the code version of corporate beaurocracy - classes everywhere devoted to doing BS jobs. It’s not complicated people. Just write the code that tells the computer what you want it to do. No more. Unnecessary encapsulation and premature abstraction will kill your velocity dead.

sethammons 2y ago

My previous unicorn rose despite the initial tech, not because of it

hbrn 2y ago
I gave you a selection of top 50 startups out of thousands funded by YC. You're giving me one anecdote.

IshKebab 2y ago

Proper engineering isn't that much of a concern when you have 0 customers, and by the time you have some it's too late to change. Besides nobody is claiming that it's impossible to build a successful products with dynamic typing. It's just not as good. You can build a successful product with zero comments in your codebase, doesn't mean it's a good idea.

hbrn 2y ago
> It's just not as good Again, the evidence (as limited as it is) suggests otherwise. You are more likely to succeed if you're going with dynamic language and not doing "proper engineering". This has been widely accepted before type-checker era, and I see no reason why it would be different now. Utilize type checker when it's free, but don't waste time on type puzzles. "Proper engineering" doesn't get you to product-market fit faster. All it does is tickle your ego.