7 ms·

The most important metric for Startups is time to market, developer productivity, fast iteration times and developer ecosystem which is why most startups (and m

by mythz 9y ago

The most important metric for Startups is time to market, developer productivity, fast iteration times and developer ecosystem which is why most startups (and many of the most popular websites) still use dynamic languages today. Once their core feature-set is established and they've developed the product they want they can go back and optimize accordingly and rewrite parts of their code-base to use the most appropriate language, e.g. rewriting hot spots in C/C++/Rust/Go, highly concurrent features in Erlang/Go, etc. If code-maintenance becomes problematic they can explore annotating their code-base with Types, adopt linters or even rewrite into a statically-typed language. None of this is a mistake, languages/technologies are a tool to achieve your business objectives, if adopting a dynamic language lets you get an MVP quicker and add/change features based on Customer feedback quicker, then that's likely the best choice. End users don't care what language servers are written in and it's definitely not a mistake to start with a dynamic language, even today. Of course if you feel most productive with a statically-typed language that's a fine option as well which may result in less technical debt/rewrites later at the cost of initial velocity upfront.

jjnoakes 9y ago
End users absolutely care when the program or service is slow, unstable, drains your battery, is constantly offline, or has major security flaws. Now there is no guarantee that a dynamic language will have those issues more than a static language, but I for one sleep better at night knowing my compiler is doing so much more work for me.
- mythz 9y ago
  > End users absolutely care when the program or service is slow A Ruby API with a good caching strategy is faster than a C/C++ binary with none and it's much easier to implement sophisticated caching strategies in dynamic languages. > unstable, drains your battery, is constantly offline Servers don't drain battery. Unstable, constantly offline has no correlation and is not limited to dynamic languages > but I for one sleep better at night knowing my compiler is doing so much more work for me. Right, choose whatever helps you sleep at night, but your language/tech choices isn't always what helps everyone else sleep.
  - jjnoakes 9y ago
    A static language is less likely to throw a runtime type error, or coerce some value incorrectly, than a dynamic language. That does correlate with being unstable and offline. Servers don't drain battery, but they cost money, so inefficiency matters server-side as well. And comparing a fully-featured dynamic language implementation with a less-featured implementation in a fairly weak statically typed language isn't really a productive comparison, is it.
    - mythz 9y ago
      No bad developers create unstable software that's slow and offline all the time, not dynamic languages. The largest Internet sites were built on dynamic languages, they wouldn't have achieved their market position if they were slow, unstable or offline all the time - it's amateur hour to think it has any correlation with being implemented in a dynamic language. Again a good caching strategy makes every language fast and in the law of large numbers scalability is more important that script execution performance. Servers of failed Startups also consume less energy then successful ones - another great example for spending precious dev cycles optimizing on the wrong thing.
      - jjnoakes 9y ago
        Mose developers are average developers. If I have an average developer writing my mvp or adding user-defined features, I'd rather have a static type system to save them time. Otherwise they have to write more tests or fly by the seat of their pants, which may lead to all the issues I raised. Just because successful companies use dynamic languages doesn't mean dynamic languages produce successful companies. And plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve. Dynamic languages are only faster to develop in because they are more ubiquitous and familiar, not because they inherently decrease the time it takes to write software. And if you get to that point, where time is no longer a factor, then choosing dynamic just leaves more opportunities for inefficiency and runtine errors.
        9y ago
fauigerzigerk 9y ago
I believe that we tend to get causality wrong on this one. I don't think dynamic languages have some intrinsic property that makes us more productive or facilitate faster time to market. Rather, I believe that people who are concerned about the soundness, consistency and maintainability of their code, and hence favor powerful static type systems, are incapable of prioritising time to market.
- resf 9y ago
  Statically typed languages increase productivity by catching errors early, but decrease productivity by making users jump through hoops. e.g. at one end of the spectrum is Java, which everything has to be a class. Even if you want to write a function, it has to be expressed as a static method in a class. In Java it's just not possible to implement ideas in the most obvious way, it has to be done in the Java way. Conversely, TypeScript was designed to work with JavaScript (which is very dynamic), so it has a very capable structural type system. The productivity penalty is negligible.
  - mercer 9y ago
    What I love about TS is that it's up to me how much effort I want to put into the type system. I find that I end up using TS even for very small projects, because I can use it for only 'the important' bits. That said, my background is mostly Ruby/Python/JS/PHP, so for all I know this is true of many statically typed languages (but from what I read this is not the case). Still, for those with a background similar to mine I can highly recommend TS as a great starting point for more statically-typed code, precisely because it's opt-in if you want it to be.

by mythz 9y ago

jjnoakes 9y ago

End users absolutely care when the program or service is slow, unstable, drains your battery, is constantly offline, or has major security flaws. Now there is no guarantee that a dynamic language will have those issues more than a static language, but I for one sleep better at night knowing my compiler is doing so much more work for me.

mythz 9y ago
> End users absolutely care when the program or service is slow A Ruby API with a good caching strategy is faster than a C/C++ binary with none and it's much easier to implement sophisticated caching strategies in dynamic languages. > unstable, drains your battery, is constantly offline Servers don't drain battery. Unstable, constantly offline has no correlation and is not limited to dynamic languages > but I for one sleep better at night knowing my compiler is doing so much more work for me. Right, choose whatever helps you sleep at night, but your language/tech choices isn't always what helps everyone else sleep.
- jjnoakes 9y ago
  A static language is less likely to throw a runtime type error, or coerce some value incorrectly, than a dynamic language. That does correlate with being unstable and offline. Servers don't drain battery, but they cost money, so inefficiency matters server-side as well. And comparing a fully-featured dynamic language implementation with a less-featured implementation in a fairly weak statically typed language isn't really a productive comparison, is it.
  - mythz 9y ago
    No bad developers create unstable software that's slow and offline all the time, not dynamic languages. The largest Internet sites were built on dynamic languages, they wouldn't have achieved their market position if they were slow, unstable or offline all the time - it's amateur hour to think it has any correlation with being implemented in a dynamic language. Again a good caching strategy makes every language fast and in the law of large numbers scalability is more important that script execution performance. Servers of failed Startups also consume less energy then successful ones - another great example for spending precious dev cycles optimizing on the wrong thing.
    - jjnoakes 9y ago
      Mose developers are average developers. If I have an average developer writing my mvp or adding user-defined features, I'd rather have a static type system to save them time. Otherwise they have to write more tests or fly by the seat of their pants, which may lead to all the issues I raised. Just because successful companies use dynamic languages doesn't mean dynamic languages produce successful companies. And plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve. Dynamic languages are only faster to develop in because they are more ubiquitous and familiar, not because they inherently decrease the time it takes to write software. And if you get to that point, where time is no longer a factor, then choosing dynamic just leaves more opportunities for inefficiency and runtine errors.
      - 9y ago

fauigerzigerk 9y ago

I believe that we tend to get causality wrong on this one. I don't think dynamic languages have some intrinsic property that makes us more productive or facilitate faster time to market. Rather, I believe that people who are concerned about the soundness, consistency and maintainability of their code, and hence favor powerful static type systems, are incapable of prioritising time to market.

resf 9y ago
Statically typed languages increase productivity by catching errors early, but decrease productivity by making users jump through hoops. e.g. at one end of the spectrum is Java, which everything has to be a class. Even if you want to write a function, it has to be expressed as a static method in a class. In Java it's just not possible to implement ideas in the most obvious way, it has to be done in the Java way. Conversely, TypeScript was designed to work with JavaScript (which is very dynamic), so it has a very capable structural type system. The productivity penalty is negligible.
- mercer 9y ago
  What I love about TS is that it's up to me how much effort I want to put into the type system. I find that I end up using TS even for very small projects, because I can use it for only 'the important' bits. That said, my background is mostly Ruby/Python/JS/PHP, so for all I know this is true of many statically typed languages (but from what I read this is not the case). Still, for those with a background similar to mine I can highly recommend TS as a great starting point for more statically-typed code, precisely because it's opt-in if you want it to be.