14 ms·

> Using a typed language in our frontend has already paid dividends: our code has fewer type-related bugs, we are more confident making large refactors, and our

> Using a typed language in our frontend has already paid dividends: our code has fewer type-related bugs, we are more confident making large refactors, and our inline documentation is focused around concepts instead of object shapes and function parameters. Sounds like they learned from their mistake of using Python on the server-side. Dynamically typed languages for large code bases are terrible.

TekMol 9y ago
Dynamically typed languages for large code bases are terrible The success of Wikipedia, Wordpress, Facebook, Youtube, GitHub etc etc etc and last but not least Reddit seem to prove otherwise.
- minitech 9y ago
  > seem to prove otherwise Prove how? They could have succeeded in spite of dynamic typing, not because of it. Facebook defined a new programming language to add static typing to HHVM. The process of plugging into WordPress is infamous in its disorganization. There’s a lack of good statically-typed languages, so it’s natural for many popular things to be built in dynamically-typed ones, but that doesn’t make the dynamic typing approach better.
  - TekMol 9y ago
    Prove how? By means of natural selection. They could have succeeded in spite of dynamic typing, not because of it. You think the otherwise smart and successfull founders of these projects all made the wrong choice when it came to selecting the right tool for the job? Facebook defined a new programming language No, they wrote a faster runtime. to add static typing to HHVM No, they added type annotations. There’s a lack of good statically-typed languages No, in the past statically typed languages were the norm. C, C++, Java... It's just that dynamic languages outcompeted them.
    - minitech 9y ago
      > You think the otherwise smart and successful founders of these projects all made the wrong choice when it came to selecting the right tool for the job? Not at all! I think dynamic typing hurts code, but there are: - not always alternatives - many other slightly suboptimal choices that it’s quite possible to succeed in spite of > No, they wrote a faster runtime. I’m referring to Hack, which is in fact another language with static typing. (Type annotations are static typing with compromises, and you can see what’s being gone for.) > No, in the past statically typed languages were the norm. C, C++, Java... Those are not remotely good. Some examples closer to being good are Rust, a step in the right direction that’s still unfolding, and Haskell, a wonderful language hampered by a slow compiler and a lack of decent packages. (And probably several less popular languages, but popularity is an important factor…)
      - Turing_Machine 9y ago
        "Those are not remotely good. Some examples closer to being good are Rust, a step in the right direction that’s still unfolding, and Haskell, a wonderful language hampered by a slow compiler and a lack of decent packages. (And probably several less popular languages, but popularity is an important factor…)" Wait: so you are arguing that startups should use languages that are either incomplete (Rust) or that have slow compilers and poor library support (Haskell), or possibly some other "good" language that doesn't actually even exist?
        minitech 9y ago
        I’m saying that dynamically-typed programming languages are the best choice right now, but that it’s not because they’re dynamically-typed; existing fare for statically-typed languages is just worse. Probably should have clarified that earlier since it looks like I agree with the statement that choosing Python was “a mistake”; sorry. I don’t. Vehemently.
    - dragonwriter 9y ago
      If type annotations support a static verifier, they implement static typing (which, after all, is just having a static verifier that uses some combination of annotations and inference to validate types.)
  - coldtea 9y ago
    >Prove how? They could have succeeded in spite of dynamic typing, not because of it. Then maybe the burden of proof is on you? If you started your career recently, it's easy to be caught up into this "static typing" as some kind of the only way.
    - andreasgonewild 9y ago
      And until you have gone back and forth a couple of times, building moderately complex systems; it's difficult to appreciate the advantages that static checking bring to the table. Sure, it's possible to achieve the same effect with unit tests; but having half of those tests written and rewritten for you by the compiler definitely helps. Back in the days, I wanted to buy into the Python/Ruby hype as much as anyone; but having implemented several complex systems in Python/Ruby, I'm not that excited about the idea anymore; once they pass a certain point, agile begins to feel more like Jello.
    - minitech 9y ago
      > Then maybe the burden of proof is on you? I’m saying that the parent doesn’t prove its point, and I’m not attempting to prove its parent’s point. > If you started your career recently, it's easy to be caught up into this "static typing" as some kind of the only way. I didn’t, and the bulk of what I’ve built has been in languages with dynamic typing. See https://news.ycombinator.com/item?id=14675577 https://news.ycombinator.com/item?id=14675577. Dismissing stuff as “recent starts” is pretty cheap, anyway.
  - Turing_Machine 9y ago
    "They could have succeeded in spite of dynamic typing, not because of it." Yes, they could have. Evidence for your hypothesis would be the existence of similarly successful companies that used compiled statically-typed languages from the beginning. Are there any recent ones?
    - tome 9y ago
      Are you suggesting that there are no similarly successful companies that used Java, C# or C++?
      - Turing_Machine 9y ago
        Are you suggesting there are? I asked for examples. Can you provide one?
  - kchoudhu 9y ago
    I'm going to throw this idea out there: companies can succeed independent of type checking.
    - rdtsc 9y ago
      That's really going out on the limb though... But you're right. Moreover I noticed obsession with a particular language is often a hallmark of a junior engineer or a recent grad. This this idea of "If you don't use Go/Node.js/etc you'll totally fail".
      - kchoudhu 9y ago
        HN skews young, I'm sure they'll grow out of it.
    - minitech 9y ago
      > Dynamically typed languages for large code bases are terrible was the original argument. Success/failure of entire companies has somehow been brought into it.
  - PunchTornado 9y ago
    The same can be said about any company to justify your opinions, like Linkedin, they use Java and Scala and their page speed is so slow. Compared to Facebook they are like a 1900' tractor. A facebook page opens in less than a second, a Linkedin page in 5.
    - mudbutt 9y ago
      I think it's the fact LinkedIn uses Ember. Anything built with Ember is sluggish and bloated
- maxxxxx 9y ago
  I bet a lot of their business logic is written in Java or C++. As far as I know Facebook has a lot of C++ and Youtube's video handling is probably also not written in Javascript.
- threeseed 9y ago
  That's not proof though. You can have a successful website with a terrible code base and vice versa. The quality of your code base largely affects the ability to roll out new features with limited regressions.
- tqkxzugoaupvwqr 9y ago
  They all started with dynamically typed languages because that was what the founders knew best when they started working on their project. Yes, you can build successful projects with dynamically typed languages but it is a pain to refactor when you grow. You even introduce a class of bugs doesn’t exist for statically typed languages. You don’t see them redo everything only because the cost would be to big. Some developed their custom tooling to handle the language they are stuck with, see Facebook.
  - dragonwriter 9y ago
    > You even introduce a class of bugs doesn’t exist for statically typed languages. As type systems vary, almost every statically-typed language allows some errors of the class statically-typed languages, in general, can prevent, so this is not really true. What is true is that on the continuum from no static validation to something like Idris or Agda, you accept more statically-avoidable type errors the closer you are to the former rather than the latter.
  - joshuamorton 9y ago
    A rudimentary end2end test should catch most type related bugs. A type system aids in refactoring, not so much actually catching bugs.
    - raquo 9y ago
      Static types are better and cheaper at catching type related bugs than a myriad of end-to-end tests that check dynamic types.
    - dom0 9y ago
      Type systems can enforce so much more, depending on the language. They make reasoning about the code far easier for both human and machine. They enable efficient optimization. They allow far superior static analysis. They allow superior IDE assistance. They improve code navigability (ag/grep). There are countless advantages to static typing, and most of the disadvantages simply don't exist in modern languages any more. Meanwhile, dynamic languages haven't evolved significantly, except to add type annotations, which are like types, just almost always less powerful and not enforced by default. Dynamic languages excel at fast initial development and "gimmicky" code (wildfire monkey patching, introspection, dynamic code generation etc.), and to get there you pay dearly. Practically all other properties suffer; stability, maintainability, performance, memory usage, ease of deployment, distribution and so on and so forth. That doesn't mean that dynamic languages have no place, or applications developed using them are somehow generally inferior to those written in statically typed languages; choice of language is only one mosaic stone of many. But it is also a foundation stone, and dictates many constraints, both technical, and social.
- staticassertion 9y ago
  Can you source some of these? Genuinely curious.
  - minitech 9y ago
    You mean sources for languages used in the implementation of various websites? - Wikipedia is mostly PHP https://github.com/wikimedia/mediawiki https://github.com/wikimedia/mediawiki - Wordpress is PHP https://github.com/WordPress/WordPress https://github.com/WordPress/WordPress - Facebook started in PHP https://www.quora.com/What-programming-languages-are-used-at-Facebook https://www.quora.com/What-programming-languages-are-used-at... - YouTube started in Python https://www.quora.com/Is-YouTube-still-written-in-Python https://www.quora.com/Is-YouTube-still-written-in-Python - GitHub is Ruby https://github.com/showcases/projects-that-power-github https://github.com/showcases/projects-that-power-github - Reddit is mostly Python https://www.reddit.com/wiki/faq#wiki_what_is_reddit_written_in.3F https://www.reddit.com/wiki/faq#wiki_what_is_reddit_written_...
    - staticassertion 9y ago
      Yes, exactly. Thanks very much. Do you know if Facebook/ Youtube are still in PHP / Python?
      - noir_lord 9y ago
        Facebook still uses PHP for a lot of templating/page generation, they use a bunch of stuff on the back not least HHVM which was great because it forced/focused the PHP team in a bunch of areas, php7 is a huge I improvement over 5 on just about every metric. It's not amazing as a language still but it's much much better and the ecosystem has really improved, modern PHP leveraging good composer components is pretty good. Even some good static analysis tooling these days.
    - icey 9y ago
      GitHub is _mostly_ Ruby -- there's Go, Python, C, and I think some Haskell in production on the website (there used to be some Erlang in there too, but iirc that's gone now). The Visual Studio and Unity extensions are written in C#. The new GitHub Desktop is written entirely in Typescript.
- make3 9y ago
  instagram, dropbox, etc
  - minitech 9y ago
    It might say something that the creator of Python is working at Dropbox and currently on a project to add static typing to it… (https://github.com/python/mypy/commits/master https://github.com/python/mypy/commits/master because I know the pain of linkless comments)
- dom0 9y ago
  Most of these languages are pretty terrible to run at scale. Also, all of the examples you cite a rather the "in spite of" kind. Wikipedia? Struggles to maintain the code base, lest to speak of significant new development. Wordpress? Afterwit of web security. Facebook? Facebook literally developed a new PHP implementation (edit: actually, two) and then turned that into a separate language (which is statically typed) because that's easier than to clean up their PHP code base. YouTube? Maybe some help pages are still on Python. The application most likely isn't at all. GitHub? Goes down every few days with 500s after buggy code was deployed.
  - 0xADEADBEE 9y ago
    The majority of YouTube is in Python 2.7 and actually served as the impetus for GrumPy [1], a transpiler to convert Python to Go. [1] https://github.com/google/grumpy/ https://github.com/google/grumpy/
- specialist 9y ago
  Even pigs fly, given enough thrust.
  - deleted 9y ago
    [deleted]
- blitmap 9y ago
  I am a HUGE coffeescript fan. What I liked about flow was seemingly unobtrusive typing/type hinting. I am not a fan of type-strict languages because I spend more time thinking about types and contracts around them than milestones/design goals. Anyway, to each their own. I want "Unobtrusive Typing" to be a thing.
  - Joeri 9y ago
    Plain Javascript is valid typescript. You can add types where you need them, via type declarations or jsdoc comments. Typescript is easy to use in a partial way, the type system only gets complicated if you turn on all the strictness settings and have to explicitly annotate every type, even in dynamic code.
- marksomnian 9y ago
  Eevee's Law: Facebook and Wikipedia could have been written in Brainfuck, as long as they can find enough smart people to mangle it. The fact that a major site is written in a language doesn't say anything about the quality of the language.
- h1d 9y ago
  You are mixing the financial and technical successes... Look at the mess of wordpress code. It's an abomaly and security history proves how it was never a technical success.
make3 9y ago
Actually I really wish there was an option similar to typescript for Python. There are promising things.. but the annotations, for example, are just not there yet
- dom0 9y ago
  Annotations at least help the IDE dig through the mess faster. That's ... something. I guess.
- ATsch 9y ago
  what would you say are the limitations of Python type annotations? From the pycon demos I've seen it seems pretty functional and complete.
  - deathanatos 9y ago
    * pylint / pep8 doesn't parse comment-based annotations, and thus flags imports that are in use as "unused" * numbers.Real / Union[float,int] do not work correctly; I basically can't figure a way to annotate a function that takes an int/float/decimal/etc. (mypy doesn't think "int" is a valid "Real", and it doesn't think you can add two Union[float,int] objects.) (mypy has nonetheless been very helpful, and overall I would recommend it.)
    - slaymaker1907 9y ago
      You don't need comment based annotations since there are real annotations since python 3.5
      - deathanatos 9y ago
        While true, my codebase regrettably needs to run in Python 2.7.
      - make3 9y ago
        I can't tell if you're neglecting the fact that most production Python is Python 2 on purpose or not
bhntr3 9y ago
https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/
ATsch 9y ago
> their mistake of using python on the server side I could not disagree with this sentiment more. As always, reality is more nuanced than this. There seems to be a common theme of startups succeeding with dynamically typed languages, and adding static typing later. However calling the original decision a "mistake" is neither fair nor accurate. After all, you don't buy a big mansion out of college because you are going to have a family one day. What is right for you today might not be right for you today. Companies change as they grow, and switching from move-fast-and-break-things to slow and steady mode is just one of those things alongside all others. Dynamic languages were great at bringing these companies where they are now: it allowed them to be agile and fast to market with a small team. Are they going to benefit from switching? Yes, absolutely. But was the original decision a mistake just because the priorities and cost/benefit curves have changed now? I really doubt it.
- bayesian_horse 9y ago
  And there still is no prove that statically typed languages are somehow more productive or scaleable. It's just taken as an article of faith.
  - Sorreah 9y ago
    It's hard to "prove" anything in discussions like this. Having been thrown in a few million loc projects, all written rather badly, I found it way easier to figure out what was going on in the ones with static types. At the very least, if you're inheriting an unknown codebase static types are in my experience a 10x speedup when measuring time to actually getting productive.
- thomasz 9y ago
  >There seems to be a common theme of startups succeeding with dynamically typed languages, and adding static typing later. However calling the original decision a "mistake" is neither fair nor accurate. People forget how old reddit is. Most good options in this space for statically compiled languages did not exist back then, so there wasn't really a decision to make. It even predates rails.
coldtea 9y ago
>Sounds like they learned from their mistake of using Python on the server-side. Dynamically typed languages for large code bases are terrible. Yeah, those pesky dynamic languages only power some of the biggest sites on earth...
- jypepin 9y ago
  its not always about the size of the site, but the size of the code base, the amount of the services and most of all, the amount of engineers working on it.
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.
rdtsc 9y ago
Mistakes? A dynamic language with fast protyping and a vibrant community helped them build a successful business. Sounds like a lesson of success to me. Had they started building it in C++ or Haskell they might still be building it with 0 customers onboard while some other company which used Python would be dominating the market.
fny 9y ago
TypeScript is not your run of the mill static language. TypeScript was the first time I ever used a static language without feeling like it was getting in the way or I was losing the power of a dynamic language. So no, they didn't learn their mistake from using Python, they were just coaxed into using an incredible language since, barring masochism, you must compile from something into JavaScript nowadays, and TypeScript is an absolute pleasure. - Type inference for the laziest. Hands down better than Scala, Swift, or Rust. The only language I've ever used that can infer recursive functions: function factorial(n: number) { if (n == 0 || n == 1) return 1; else n * factorial(n - 1) } - You can define mix-typed maps without a sweat: const defaults = { debug: false, title: 'Banana', width: 100 } - And as a bonus you can suck the type out for later use: type Settings = typeof defaults - You can mix types without the compiler demanding umpteen incantations. - Gloriously simple union types. - Regex types are coming! (e.g. all strings that look like a URL) - You can type the API of some hidden dynamically-typed insanity if needed. - You get a REPL for free, and it's pretty easy to debug production code if you haven't mangled all your names. - Haven't figured how to type something? Want to prototype something quickly? No worries! Your code will still compile.
- mrkgnao 9y ago
  > infer recursive functions Any of the mainstream functional languages (which are most likely to have type inference) can infer the types of all functions, unless you use funky language extensions that make type inference undecidable. Rust has a Hindley-Milner system, so it should be able to "infer recursive functions" too (but I can't say for sure since I don't use it).
  - fny 9y ago
    I've tried in Rust, and it requires a return definition, as do most mainstream functional languages. Also, mainstream functional languages aren't truly mainstream: I'd struggle to find devs who could help me in consulting gigs.
    - igouy 9y ago
yogthos 9y ago
I never understood why people fetishize writing monolithic applications myself. In practice, any large application can be broken down into isolated components that you can reason about independently. It seems like people often use a static typing as a crutch instead of spending the time to design their applications properly, and break them up into small reusable components that are easy to maintain. My team has been working with Clojure for the past 6 years, and we've built and maintain a number of large applications. Dynamic typing is absolutely not a problem for us. I find that immutability plays a far bigger role when it comes to maintaining large applications. When you work with immutable data, it becomes possible to safely reason about parts of the application in isolation. This is a key factor in making large apps maintainable.
- Chyzwar 9y ago
  This is only possible if you can precisely draw business domain boundaries. Micro-services add large operational overhead. If you slice you application in wrong way you will suffer... IMO it is better to start from monolith and then extract services.
  - yogthos 9y ago
    There aren't any micro-services in our applications. However, drawing business boundaries is much easier to do in Clojure than most languages I've used. You have a common set of data structures that all functions operate on. To create a piece of domain logic, I simply need to create a namespace, and put the related functions there. This style of code is highly composable. Since majority of functions are doing generic transformations, the domain specific logic is expressed by chaining these functions in a particular way to get a desired transformation. When I need a different kind of transformation, then I just chain the functions in a different order. My experience is that the business logic naturally bubbles up to a thin layer at the top.
flavio81 9y ago
"Dynamically typed languages for large code bases are terrible." Perhaps this is what you believe based on your experience or opinions on internet. However large code bases, complex systems, have been used successfully, for example for: - Driving the Deep Space 1 (DS1) NASA spacecraft for 3 days without manual input. - Search for airline ticket reservations encompassing almost all the airports in the world and most airline companies, not to mention all the diverse routes available. Really complex stuff. (ITA software, currently in use across the globe) These big, complex applications were written in a dynamically typed language.
- dom0 9y ago
  You should perhaps mention that your examples are also written in a Lisp dialect which is a rather different thing from your average 90s script language.

TekMol 9y ago

Dynamically typed languages for large code bases are terrible The success of Wikipedia, Wordpress, Facebook, Youtube, GitHub etc etc etc and last but not least Reddit seem to prove otherwise.

minitech 9y ago
> seem to prove otherwise Prove how? They could have succeeded in spite of dynamic typing, not because of it. Facebook defined a new programming language to add static typing to HHVM. The process of plugging into WordPress is infamous in its disorganization. There’s a lack of good statically-typed languages, so it’s natural for many popular things to be built in dynamically-typed ones, but that doesn’t make the dynamic typing approach better.
- TekMol 9y ago
  Prove how? By means of natural selection. They could have succeeded in spite of dynamic typing, not because of it. You think the otherwise smart and successfull founders of these projects all made the wrong choice when it came to selecting the right tool for the job? Facebook defined a new programming language No, they wrote a faster runtime. to add static typing to HHVM No, they added type annotations. There’s a lack of good statically-typed languages No, in the past statically typed languages were the norm. C, C++, Java... It's just that dynamic languages outcompeted them.
  - minitech 9y ago
    > You think the otherwise smart and successful founders of these projects all made the wrong choice when it came to selecting the right tool for the job? Not at all! I think dynamic typing hurts code, but there are: - not always alternatives - many other slightly suboptimal choices that it’s quite possible to succeed in spite of > No, they wrote a faster runtime. I’m referring to Hack, which is in fact another language with static typing. (Type annotations are static typing with compromises, and you can see what’s being gone for.) > No, in the past statically typed languages were the norm. C, C++, Java... Those are not remotely good. Some examples closer to being good are Rust, a step in the right direction that’s still unfolding, and Haskell, a wonderful language hampered by a slow compiler and a lack of decent packages. (And probably several less popular languages, but popularity is an important factor…)
    - Turing_Machine 9y ago
      "Those are not remotely good. Some examples closer to being good are Rust, a step in the right direction that’s still unfolding, and Haskell, a wonderful language hampered by a slow compiler and a lack of decent packages. (And probably several less popular languages, but popularity is an important factor…)" Wait: so you are arguing that startups should use languages that are either incomplete (Rust) or that have slow compilers and poor library support (Haskell), or possibly some other "good" language that doesn't actually even exist?
      - minitech 9y ago
        I’m saying that dynamically-typed programming languages are the best choice right now, but that it’s not because they’re dynamically-typed; existing fare for statically-typed languages is just worse. Probably should have clarified that earlier since it looks like I agree with the statement that choosing Python was “a mistake”; sorry. I don’t. Vehemently.
  - dragonwriter 9y ago
    If type annotations support a static verifier, they implement static typing (which, after all, is just having a static verifier that uses some combination of annotations and inference to validate types.)
- coldtea 9y ago
  >Prove how? They could have succeeded in spite of dynamic typing, not because of it. Then maybe the burden of proof is on you? If you started your career recently, it's easy to be caught up into this "static typing" as some kind of the only way.
  - andreasgonewild 9y ago
    And until you have gone back and forth a couple of times, building moderately complex systems; it's difficult to appreciate the advantages that static checking bring to the table. Sure, it's possible to achieve the same effect with unit tests; but having half of those tests written and rewritten for you by the compiler definitely helps. Back in the days, I wanted to buy into the Python/Ruby hype as much as anyone; but having implemented several complex systems in Python/Ruby, I'm not that excited about the idea anymore; once they pass a certain point, agile begins to feel more like Jello.
  - minitech 9y ago
    > Then maybe the burden of proof is on you? I’m saying that the parent doesn’t prove its point, and I’m not attempting to prove its parent’s point. > If you started your career recently, it's easy to be caught up into this "static typing" as some kind of the only way. I didn’t, and the bulk of what I’ve built has been in languages with dynamic typing. See https://news.ycombinator.com/item?id=14675577 https://news.ycombinator.com/item?id=14675577. Dismissing stuff as “recent starts” is pretty cheap, anyway.
- Turing_Machine 9y ago
  "They could have succeeded in spite of dynamic typing, not because of it." Yes, they could have. Evidence for your hypothesis would be the existence of similarly successful companies that used compiled statically-typed languages from the beginning. Are there any recent ones?
  - tome 9y ago
    Are you suggesting that there are no similarly successful companies that used Java, C# or C++?
    - Turing_Machine 9y ago
      Are you suggesting there are? I asked for examples. Can you provide one?
- kchoudhu 9y ago
  I'm going to throw this idea out there: companies can succeed independent of type checking.
  - rdtsc 9y ago
    That's really going out on the limb though... But you're right. Moreover I noticed obsession with a particular language is often a hallmark of a junior engineer or a recent grad. This this idea of "If you don't use Go/Node.js/etc you'll totally fail".
    - kchoudhu 9y ago
      HN skews young, I'm sure they'll grow out of it.
  - minitech 9y ago
    > Dynamically typed languages for large code bases are terrible was the original argument. Success/failure of entire companies has somehow been brought into it.
- PunchTornado 9y ago
  The same can be said about any company to justify your opinions, like Linkedin, they use Java and Scala and their page speed is so slow. Compared to Facebook they are like a 1900' tractor. A facebook page opens in less than a second, a Linkedin page in 5.
  - mudbutt 9y ago
    I think it's the fact LinkedIn uses Ember. Anything built with Ember is sluggish and bloated
maxxxxx 9y ago
I bet a lot of their business logic is written in Java or C++. As far as I know Facebook has a lot of C++ and Youtube's video handling is probably also not written in Javascript.
threeseed 9y ago
That's not proof though. You can have a successful website with a terrible code base and vice versa. The quality of your code base largely affects the ability to roll out new features with limited regressions.
tqkxzugoaupvwqr 9y ago
They all started with dynamically typed languages because that was what the founders knew best when they started working on their project. Yes, you can build successful projects with dynamically typed languages but it is a pain to refactor when you grow. You even introduce a class of bugs doesn’t exist for statically typed languages. You don’t see them redo everything only because the cost would be to big. Some developed their custom tooling to handle the language they are stuck with, see Facebook.
- dragonwriter 9y ago
  > You even introduce a class of bugs doesn’t exist for statically typed languages. As type systems vary, almost every statically-typed language allows some errors of the class statically-typed languages, in general, can prevent, so this is not really true. What is true is that on the continuum from no static validation to something like Idris or Agda, you accept more statically-avoidable type errors the closer you are to the former rather than the latter.
- joshuamorton 9y ago
  A rudimentary end2end test should catch most type related bugs. A type system aids in refactoring, not so much actually catching bugs.
  - raquo 9y ago
    Static types are better and cheaper at catching type related bugs than a myriad of end-to-end tests that check dynamic types.
  - dom0 9y ago
    Type systems can enforce so much more, depending on the language. They make reasoning about the code far easier for both human and machine. They enable efficient optimization. They allow far superior static analysis. They allow superior IDE assistance. They improve code navigability (ag/grep). There are countless advantages to static typing, and most of the disadvantages simply don't exist in modern languages any more. Meanwhile, dynamic languages haven't evolved significantly, except to add type annotations, which are like types, just almost always less powerful and not enforced by default. Dynamic languages excel at fast initial development and "gimmicky" code (wildfire monkey patching, introspection, dynamic code generation etc.), and to get there you pay dearly. Practically all other properties suffer; stability, maintainability, performance, memory usage, ease of deployment, distribution and so on and so forth. That doesn't mean that dynamic languages have no place, or applications developed using them are somehow generally inferior to those written in statically typed languages; choice of language is only one mosaic stone of many. But it is also a foundation stone, and dictates many constraints, both technical, and social.
staticassertion 9y ago
Can you source some of these? Genuinely curious.
- minitech 9y ago
  You mean sources for languages used in the implementation of various websites? - Wikipedia is mostly PHP https://github.com/wikimedia/mediawiki https://github.com/wikimedia/mediawiki - Wordpress is PHP https://github.com/WordPress/WordPress https://github.com/WordPress/WordPress - Facebook started in PHP https://www.quora.com/What-programming-languages-are-used-at-Facebook https://www.quora.com/What-programming-languages-are-used-at... - YouTube started in Python https://www.quora.com/Is-YouTube-still-written-in-Python https://www.quora.com/Is-YouTube-still-written-in-Python - GitHub is Ruby https://github.com/showcases/projects-that-power-github https://github.com/showcases/projects-that-power-github - Reddit is mostly Python https://www.reddit.com/wiki/faq#wiki_what_is_reddit_written_in.3F https://www.reddit.com/wiki/faq#wiki_what_is_reddit_written_...
  - staticassertion 9y ago
    Yes, exactly. Thanks very much. Do you know if Facebook/ Youtube are still in PHP / Python?
    - noir_lord 9y ago
      Facebook still uses PHP for a lot of templating/page generation, they use a bunch of stuff on the back not least HHVM which was great because it forced/focused the PHP team in a bunch of areas, php7 is a huge I improvement over 5 on just about every metric. It's not amazing as a language still but it's much much better and the ecosystem has really improved, modern PHP leveraging good composer components is pretty good. Even some good static analysis tooling these days.
  - icey 9y ago
    GitHub is _mostly_ Ruby -- there's Go, Python, C, and I think some Haskell in production on the website (there used to be some Erlang in there too, but iirc that's gone now). The Visual Studio and Unity extensions are written in C#. The new GitHub Desktop is written entirely in Typescript.
make3 9y ago
instagram, dropbox, etc
- minitech 9y ago
  It might say something that the creator of Python is working at Dropbox and currently on a project to add static typing to it… (https://github.com/python/mypy/commits/master https://github.com/python/mypy/commits/master because I know the pain of linkless comments)
dom0 9y ago
Most of these languages are pretty terrible to run at scale. Also, all of the examples you cite a rather the "in spite of" kind. Wikipedia? Struggles to maintain the code base, lest to speak of significant new development. Wordpress? Afterwit of web security. Facebook? Facebook literally developed a new PHP implementation (edit: actually, two) and then turned that into a separate language (which is statically typed) because that's easier than to clean up their PHP code base. YouTube? Maybe some help pages are still on Python. The application most likely isn't at all. GitHub? Goes down every few days with 500s after buggy code was deployed.
- 0xADEADBEE 9y ago
  The majority of YouTube is in Python 2.7 and actually served as the impetus for GrumPy [1], a transpiler to convert Python to Go. [1] https://github.com/google/grumpy/ https://github.com/google/grumpy/
specialist 9y ago
Even pigs fly, given enough thrust.
- deleted 9y ago
  [deleted]
blitmap 9y ago
I am a HUGE coffeescript fan. What I liked about flow was seemingly unobtrusive typing/type hinting. I am not a fan of type-strict languages because I spend more time thinking about types and contracts around them than milestones/design goals. Anyway, to each their own. I want "Unobtrusive Typing" to be a thing.
- Joeri 9y ago
  Plain Javascript is valid typescript. You can add types where you need them, via type declarations or jsdoc comments. Typescript is easy to use in a partial way, the type system only gets complicated if you turn on all the strictness settings and have to explicitly annotate every type, even in dynamic code.
marksomnian 9y ago
Eevee's Law: Facebook and Wikipedia could have been written in Brainfuck, as long as they can find enough smart people to mangle it. The fact that a major site is written in a language doesn't say anything about the quality of the language.
h1d 9y ago
You are mixing the financial and technical successes... Look at the mess of wordpress code. It's an abomaly and security history proves how it was never a technical success.

make3 9y ago

Actually I really wish there was an option similar to typescript for Python. There are promising things.. but the annotations, for example, are just not there yet

dom0 9y ago
Annotations at least help the IDE dig through the mess faster. That's ... something. I guess.
ATsch 9y ago
what would you say are the limitations of Python type annotations? From the pycon demos I've seen it seems pretty functional and complete.
- deathanatos 9y ago
  * pylint / pep8 doesn't parse comment-based annotations, and thus flags imports that are in use as "unused" * numbers.Real / Union[float,int] do not work correctly; I basically can't figure a way to annotate a function that takes an int/float/decimal/etc. (mypy doesn't think "int" is a valid "Real", and it doesn't think you can add two Union[float,int] objects.) (mypy has nonetheless been very helpful, and overall I would recommend it.)
  - slaymaker1907 9y ago
    You don't need comment based annotations since there are real annotations since python 3.5
    - deathanatos 9y ago
      While true, my codebase regrettably needs to run in Python 2.7.
    - make3 9y ago
      I can't tell if you're neglecting the fact that most production Python is Python 2 on purpose or not

bhntr3 9y ago

https://danluu.com/empirical-pl/ https://danluu.com/empirical-pl/

ATsch 9y ago

> their mistake of using python on the server side I could not disagree with this sentiment more. As always, reality is more nuanced than this. There seems to be a common theme of startups succeeding with dynamically typed languages, and adding static typing later. However calling the original decision a "mistake" is neither fair nor accurate. After all, you don't buy a big mansion out of college because you are going to have a family one day. What is right for you today might not be right for you today. Companies change as they grow, and switching from move-fast-and-break-things to slow and steady mode is just one of those things alongside all others. Dynamic languages were great at bringing these companies where they are now: it allowed them to be agile and fast to market with a small team. Are they going to benefit from switching? Yes, absolutely. But was the original decision a mistake just because the priorities and cost/benefit curves have changed now? I really doubt it.

bayesian_horse 9y ago
And there still is no prove that statically typed languages are somehow more productive or scaleable. It's just taken as an article of faith.
- Sorreah 9y ago
  It's hard to "prove" anything in discussions like this. Having been thrown in a few million loc projects, all written rather badly, I found it way easier to figure out what was going on in the ones with static types. At the very least, if you're inheriting an unknown codebase static types are in my experience a 10x speedup when measuring time to actually getting productive.
thomasz 9y ago
>There seems to be a common theme of startups succeeding with dynamically typed languages, and adding static typing later. However calling the original decision a "mistake" is neither fair nor accurate. People forget how old reddit is. Most good options in this space for statically compiled languages did not exist back then, so there wasn't really a decision to make. It even predates rails.

coldtea 9y ago

>Sounds like they learned from their mistake of using Python on the server-side. Dynamically typed languages for large code bases are terrible. Yeah, those pesky dynamic languages only power some of the biggest sites on earth...

jypepin 9y ago
its not always about the size of the site, but the size of the code base, the amount of the services and most of all, the amount of engineers working on it.

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.

rdtsc 9y ago

Mistakes? A dynamic language with fast protyping and a vibrant community helped them build a successful business. Sounds like a lesson of success to me. Had they started building it in C++ or Haskell they might still be building it with 0 customers onboard while some other company which used Python would be dominating the market.

fny 9y ago

TypeScript is not your run of the mill static language. TypeScript was the first time I ever used a static language without feeling like it was getting in the way or I was losing the power of a dynamic language. So no, they didn't learn their mistake from using Python, they were just coaxed into using an incredible language since, barring masochism, you must compile from something into JavaScript nowadays, and TypeScript is an absolute pleasure. - Type inference for the laziest. Hands down better than Scala, Swift, or Rust. The only language I've ever used that can infer recursive functions: function factorial(n: number) { if (n == 0 || n == 1) return 1; else n * factorial(n - 1) } - You can define mix-typed maps without a sweat: const defaults = { debug: false, title: 'Banana', width: 100 } - And as a bonus you can suck the type out for later use: type Settings = typeof defaults - You can mix types without the compiler demanding umpteen incantations. - Gloriously simple union types. - Regex types are coming! (e.g. all strings that look like a URL) - You can type the API of some hidden dynamically-typed insanity if needed. - You get a REPL for free, and it's pretty easy to debug production code if you haven't mangled all your names. - Haven't figured how to type something? Want to prototype something quickly? No worries! Your code will still compile.

mrkgnao 9y ago
> infer recursive functions Any of the mainstream functional languages (which are most likely to have type inference) can infer the types of all functions, unless you use funky language extensions that make type inference undecidable. Rust has a Hindley-Milner system, so it should be able to "infer recursive functions" too (but I can't say for sure since I don't use it).
- fny 9y ago
  I've tried in Rust, and it requires a return definition, as do most mainstream functional languages. Also, mainstream functional languages aren't truly mainstream: I'd struggle to find devs who could help me in consulting gigs.
  - igouy 9y ago

yogthos 9y ago

I never understood why people fetishize writing monolithic applications myself. In practice, any large application can be broken down into isolated components that you can reason about independently. It seems like people often use a static typing as a crutch instead of spending the time to design their applications properly, and break them up into small reusable components that are easy to maintain. My team has been working with Clojure for the past 6 years, and we've built and maintain a number of large applications. Dynamic typing is absolutely not a problem for us. I find that immutability plays a far bigger role when it comes to maintaining large applications. When you work with immutable data, it becomes possible to safely reason about parts of the application in isolation. This is a key factor in making large apps maintainable.

Chyzwar 9y ago
This is only possible if you can precisely draw business domain boundaries. Micro-services add large operational overhead. If you slice you application in wrong way you will suffer... IMO it is better to start from monolith and then extract services.
- yogthos 9y ago
  There aren't any micro-services in our applications. However, drawing business boundaries is much easier to do in Clojure than most languages I've used. You have a common set of data structures that all functions operate on. To create a piece of domain logic, I simply need to create a namespace, and put the related functions there. This style of code is highly composable. Since majority of functions are doing generic transformations, the domain specific logic is expressed by chaining these functions in a particular way to get a desired transformation. When I need a different kind of transformation, then I just chain the functions in a different order. My experience is that the business logic naturally bubbles up to a thin layer at the top.

flavio81 9y ago

"Dynamically typed languages for large code bases are terrible." Perhaps this is what you believe based on your experience or opinions on internet. However large code bases, complex systems, have been used successfully, for example for: - Driving the Deep Space 1 (DS1) NASA spacecraft for 3 days without manual input. - Search for airline ticket reservations encompassing almost all the airports in the world and most airline companies, not to mention all the diverse routes available. Really complex stuff. (ITA software, currently in use across the globe) These big, complex applications were written in a dynamically typed language.

dom0 9y ago
You should perhaps mention that your examples are also written in a Lisp dialect which is a rather different thing from your average 90s script language.