Hacker News new | past | comments | ask | show | jobs | submit login

> when types weren't an option we weren't going towards the cliff

Erm yes we were. Untyped Python wasn't magically tolerable just because type hints hadn't been implemented yet.




How come all those unicorns were built with intolerable Python/Ruby, not Java/C#/Go?

https://charliereese.ca/y-combinator-top-50-software-startup...


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#.


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.


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.


This distinction makes no sense. Can you explain why types would be more relevant?


Actually I don't think types are relevant here. People are choosing based on other weighted factors like toolchain, ecosystem, products, and culture.


Are you a bot?


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.


> 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.


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


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




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: