Hacker News new | comments | show | ask | jobs | submit login
Why We Chose Typescript (redditblog.com)
385 points by darwhy on June 30, 2017 | hide | past | web | favorite | 385 comments



If you want runtime assertions with flow you can use flow-runtime [0].

Babylon merged TypeScript support yesterday [1]. This means that in the future it should be easier to setup Babel with TypeScript.

I agree with the decision to go with TypeScript. It has drastically better community support. Most third-party components won't have flow annotations. Flow would've been a lot more successful from the start if it had started out with DefinitelyTyped support. Heck, even now I'm still wondering why they don't do that.

[0] https://codemix.github.io/flow-runtime/#/

[1] https://github.com/babel/babylon/pull/523#issuecomment-31172...


Yep, if anyone can/wants to help out with this effort I would follow/review the issues/PRs in our typescript label https://github.com/babel/babel/pulls?q=is%3Apr+is%3Aopen+lab... (I help with Babel). We'll be working with the TS team to definetely get some better docs on how to setup both Babel and TS once we land the changes in Babel and release 7.0


I was wondering does this make it possible to use proposals which have support in babel but not yet in typescript (e.g. do expression) when writing typescript?


At this point, it make senses for someone to write a TypeScript definition to Flow definition converter. Given how similar the languages are, I feel like you might even get away with using hacky Regex-based transformation instead of using ASTs for a lot of libraries.

I never did understand why Facebook and Microsoft ended up competing on this front.


> I never did understand why Facebook and Microsoft ended up competing on this front.

They ended up competing, but they did not start competing. The projects were started in isolation from each other. The fact that they are written in different languages (Flow: OCaml, TS: TS) makes it hard to merge efforts.


Ah, useful things to know about!

flow-typed does exist, so that's something. https://github.com/flowtype/flow-typed.


Between Flow and Typescript, looks like the latter has all the momentum. But I see one way in which Flow could become relevant again: by becoming 100% compatible with plain JS.

I would love to have type checking, but I'm weary of solutions that aren't really JS, and could fall out of favor or lack good support in the future. I'm pretty sure I'm not the only one.

But Flow type annotations don't really need an incompatible syntax AFAIK; they could just use comments. This way, we wouldn't need to worry about the future of Flow. If the projects dies off or becomes redundant, we're just left with some useful comments - no need to rewrite or transpile our code to native JS.

PS I found an existing project which does this [1], but it requires an additional step and it isn't officially supported. It looks incredibly easy to make Flow work directly with pure JS with comments...

[1] https://github.com/Kegsay/flow-jsdoc



Thanks, but from a bit of research it's not clear to me: does this mean that it's possible to use TypeScript to type-check javascript files which include these annotations, without using .ts at all?


Yes, by using --allowJS and --checkJS switches (can also be set in tsconfig.json).


Thanks a lot - will try this!


The big thing I liked about Flow over TypeScript was the more accurate type checking. 2.4 looks like it has finally fixed that.


Sorry but what is the use case for Babel + TS? I thought you use either Babel or TS but not both together.


You can use Babel with TS. For example, for JSX you can tell TS to "preserve" the JSX, which means you can tell babel or some other compiler take care of that transformation[1]. You can also use babel with typescript to use the babel presets for stage-[0-4] plugins. You can use the webpack TS loader, awesome-typescript-loader, to work with babel[2].

[1] https://www.typescriptlang.org/docs/handbook/jsx.html [2] https://github.com/s-panferov/awesome-typescript-loader


One case I ran into: using css-loader/style-loader for my css. TS doesn't understand importing css files, so that's where Babel comes in.

In the end i decided to stick to 'old-fashioned' SCSS with an npm script; the downsides of adding Babel to my stack weren't worth the upsides of css modules. Difficult decision to make though.

I guess what I'm saying is that while there is a use case, so far it's been worth it to just stick to TS without Babel, much as I wish it'd be different.


You could use the webpack (which you might be using already) css loader and declare the css file as any.


Babel can now parse TypeScript source and turn it into an AST. It doesn't check types at this point.


Support for DefinitelyTyped is what I really appreciate about Kotlin-to-JS.


What has your experience with kotlin and js been? Kotlin appeals to me a lot more than typescript and seems more practical than reasonml.


No more experience than reading the docs and watching an old talk from Andrey Breslav [1] where he explains how a DSL for HTML generation could work in Kotlin.

I like what I see and look forward to experimenting with it once I have more free-time (currently in grad-school taking summer courses). Kotlin as a language is really compelling, so I've tried to at least stay informed about it.

[1] https://youtu.be/OSBNkqy0UAI


Down-voted because research into language features is useless, I suppose?


TypeScript's IRC channel on Freenode is an amazing, supportive place, too. In sharp contrast to #gonuts, which is a cesspool.


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


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


Having used many languages over the years, the biggest advantage I've seen to dynamically typed languages is that they're easier to learn.

Python and JavaScript are probably the most common "first languages" taught in school. The dynamic typing and lack of complex IDE, compilation, and build system make then easier to learn. Most founders only have a few years of programming experience. Most startups can't afford to hire anyone experienced. Given these constraints, using these languages makes sense.

Dynamic language aren't any faster in practice. You can write quick and dirty spaghetti code in anything. It's only the naive that consider building large, or potentially large, projects in languages without static typing and strong IDE support.

In time I've realized that dynamic typing doesn't give any real advantages. It allows you to reuse variables, something that should never be done. It allows you to put different objects in the same array without having anything in common, which also seems like a bad idea. What else do you get? The language still has types they're just not visible when your writing code. I would much rather have compile-time types so I can use auto complete


Having used many languages over the years, the biggest advantage I've seen to dynamically typed languages is that they're easier to learn.

I love Ruby because of its delightful standard library, its thoughtful syntax which makes manual refactorings easy, not because or in spite of its dynamic types.

I detest Java because of its verbose syntax, its love affair with XML, and because it isn't a good unix citizen. Not because of or in spite of its static type system.

I detest Javascript because of its non-existent standard library, its many, many design errors (slowly being fixed, I know). Not because of its particular type system.

All other things being equal, I would prefer my language of choice to have statically checked, expressive type system. Unfortunately, all other things have not been close to equal historically. Things are improving, and maybe these days it's possible to have your cake and eat it too.


In practice the Python language is so easy that you rarely have bugs related to types. And when you got it, you find it out pretty early.

Types are useful when you grow, but thinking that you can't do anything big and robust without it is ignoring all the people that actually do so.

Another thing is that the simplicity and power of Python leads to having a lot of libs that are actually clean and solid for a lot of stuff. If I need to create anything under 100000 vis/day, I'm 3 times faster than a Go or Java dev on the backend. Literally 3 times.

I also produce better results. With things like Django rest framework, I can get the same REST API, but all the edge cases will be way better handled, small error messages, multi type of auth, etc.

Those things exist because it's fast to code in Python. And yes, dynamic typing help with that a lot.

So yes, it's true I don't have as much code completion and I have to remember a bit more about the code, but it's an exchange I'm making.

When I want to scale up robustness, I use type hints with mypy and get a strong code completion on PyCharm.


3 times faster with zero proof? Java has similar REST frameworks, notably Jersey and Spring Boot. There's also the Play/Dropwizard crowd and Vert.x . Look at spring boot code vs flask, it's almost identical.

Java libraries, particularly those maintained by Google and other tech giants are some of the most solid code ever written. I doubt Python or any other language comes close to the quality of popular Java libraries.

I still don't see how dynamic typing helps with speed? Any Decent IDE will fill in the types for you so you don't even need to key then mostly


Actually develop in spring boot vs flask, and you'll see just how much faster it is to code in flask. Spring Boot has many peculiarities and boiler plate you have to deal with. Flask just works.

>I doubt Python or any other language comes close to the quality of popular Java libraries.

You complain about proof and then you throw out this line.


There is no proof of anything in any comments in this thread.


Hahaha yeah I just realized I've precipitated a classic flamewar, oops. I'll recuse myself from making further comments on this thread. :)


Couldn't have written this any better. Also add the need to write shed loads of "test code" in order to reduce the probability of runtime fatal errors that would have been caught by a compiler; and the fact that source code becomes very hard to understand and maintain due to lack of semantic clues from things like types and structure definitions.


Also add the need to write shed loads of "test code" in order to reduce the probability of runtime fatal errors that would have been caught by a compiler

People always say this, and I've never understood it. Can somebody provide an example of a test that you "have" to write in a dynamically typed language that you wouldn't with static typing? If you're referencing nonexistent properties, then any test that hits that line will fail, and such a test should exist regardless of whether you're using static types.


No, that's exactly the point: with a statically-typed language, you wouldn't need a test for a non-existent property reference. The compiler will choke on the bad reference, and any test that uses/references the module in which the code resides will fail to compile. In other words, just simply trying to compile the complete codebase serves as a baseline "type/sanity test". The compiler will simply not allow you to produce an application containing such code.


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


and that until 2005 reddit was written in Lisp


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.


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.


Dynamic language does not make you more agile, it makes changes more risky and refactoring harder.

However, large part is that for frontend, static languages are just getting there. You need not just language, but also libraries, tutorials, tooling, IDE and so on and so forth.

Typescript nor flow does not absolve you from the need to learn javascript and web in general. If you are working on your first bigger project and still learning good techniques, architecture and concepts, css, having to also learn typescript or flow syntax on top of it off-puts people.


This is partly why I'm so curious about languages like Racket, that let you start with easy, freewheeling dynamic typing, and then move, in parts, to Typed Racket. We just need to convince some big software engineering project to start down that road, so we can collect the data about the approach :-p


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.


> You can define mix-typed maps without a sweat: const defaults = { debug: false, title: 'Banana', width: 100 }

That's called a struct (or class) elsewhere.


An instance of mixed-type maps*

Elsewhere one would have to define a struct/class and them create an instance.

This becomes immensely helpful for the incredibly lazy with one off object definitions and wrapper types. If you introduce a class definition alongside an instance, you're now forced to manage two peices of code. The class definition and instance definition. In this case they're coupled which aides maintenance in my experience.


Specifically structural record types, and many statically typed languages don't have them. (not Java, not C++, not Haskell, not Rust, yes Swift, yes OCaml)


What I wanted to point out is that typically a C struct is what you need. The common case is static keys and static value types but dynamic values.

What are interesting use cases for more dynamic (i.e. non-fixed set of keys / types)?

I mean, if you need something super-abstract and flexible, you are unlikely to need a built-in convenient syntax to hardcode such values.


, yes Purescript :)

For those new to this, good search terms are "row polymorphism", "extensible records", and "polymorphic variants".


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


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.


I'm pretty sure that's just "administrative" and imposed by the syntax (e.g. think Java/C++ function declaration syntax), instead of being something the compiler can't infer. Thanks for clearing this up, though.


It was a design decision, yes. We could infer them if we wanted to, but we don't.


    let rec factorial n = 
        if n = 0 || n = 1 then 1 
        else n * factorial (n - 1)
F#


Haskell:

  factorial n =
    if n < 2 
      then 1
      else n * factorial (n - 1)
I think the OCaml version will look almost exactly like the F# one.


>> The only language I've ever used that can infer recursive functions <<

You don't need to have used other languages to see there's no problem -- just Google -- haskell recursive factorial type inference


Where can I find more info on the upcoming regex types?


Correction: might be coming.* It's a GitHub issue that's received a lot of attention. Apologies, my memory gets optimistically fuzzy when I swoon over a language. ;)

[0]: https://github.com/Microsoft/TypeScript/issues/6579


    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.


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


    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.


> It's just that dynamic languages outcompeted them.

All "trending" languages are statically typed (Rust, Go, Swift, Kotlin, ...) and all the popular JavaScrip-improved-languages are statically typed as well. Even further, many dynamically typed languages have pushed in recent years to add type annotations or even static typing (e.g. mypy).

Dynamic typing is the brainchild of the 90s for rapid initial development. Sustainability has been a big issue from the outset.


Dynamic typing is from 1958 Lisp. Your history is off a bit there, by some forty years.


The 90's also saw much commercial experimentation with visual environments (e.g. Visual Basic, Delphi, JBuilder) with round-trip conversion between the layout form and underlying code. They were promoted for R.A.D. (rapid application development -- remember that acronym?) but, like dynamically typed languages, they also had sustainability issues.

Of course, like dynamic typing and Lisp, visual environments also had Smalltalk from way back, but they were before big business became infatuated with the ideas.


How do products like Delphi have sustainability (maintainability ?) issues ? Delphi/Object Pascal is statically-typed, so you can't even build an application that has issues with the code-behind for a form.

You can see errors at run-time from mismatches between the code-behind and the forms, but this has nothing to do with the language. It's just the way that certain products like Delphi decided to handle such mismatches. You'll see these types of issues with any code that performs run-time serialization/deserialization of class instances. Our product, Elevate Web Builder, uses a similar architecture with its WYSIWYG form designer/forms (they use JSON instead of a custom key-value format), but it simply ignores properties in forms that don't exist in the actual code.


Lisp has nothing to do (in many ways) with the late 80s and 90s wave of dynamic languages.


JavaScript was definitely partly inspired by Scheme.


likewise ruby by lisp


I’d say Ruby’s closest sibling is Smalltalk personally.


People say this mainly because of the brace-enclosed blocks of code being functions. However, that is really just a syntactic sugar for lambda (and can even have explicit arguments: (lambda (x y) ...) <--> {|x,y| ... }.


there's the "everything is objects and messages sent to them" bit too, which is definitely from smalltalk. ruby took the good bits from several languages.


I've still not seen a single "sustainability issue" in Python code bases which seem to stem from dynamic typing as opposed to static typing.


I think Elixir is trending, and it's not statically typed, right?

That said, I do agree that static typing is in vogue.


Smart answer successful founders of Wikipedia took an existing wiki engine. Their aspirations were not in the software development area.

Highly dynamic languages like Python or PHP or Perl are easy to start with, so they're great for prototypes. Then either a serious rewrite follows, using a statically checked language, or scaffolding is erected to continue to make do with the dynamic code. Microservices help!


Erm, so splitting big Python projects into microservices is proof that dynamic typing is unsustainable?


No; but a single microservice is a smaller code base that a large monolith, so the problem . Also, you normally control the microservice's interface more strictly, and change it less often, and care about compatibility and versioning more, than for a typical internal API.


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


> 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…)


"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?


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.


> No, they wrote a faster runtime.

Which includes a statically-typed version of PHP, namely Hack, that they use for their code.

> No, they added type annotations.

Hack's type checking is much more sophisticated than mere “annotations”. That label might be better suited to PHP's type system.


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

Nobody is perfect. Mark Zuckerberg has had his fair share of controversies for example.

>No, in the past statically typed languages were the norm. C, C++, Java...

Not good examples for your argument. These are largely considered poorly statically typed. Compare to ML, Haskell, Ada, Rust, Swift for reference.


I'm going to throw this idea out there: companies can succeed independent of type checking.


> Dynamically typed languages for large code bases are terrible

was the original argument. Success/failure of entire companies has somehow been brought into it.


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


HN skews young, I'm sure they'll grow out of it.


"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?


Are you suggesting that there are no similarly successful companies that used Java, C# or C++?


Are you suggesting there are?

I asked for examples. Can you provide one?


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.


I think it's the fact LinkedIn uses Ember. Anything built with Ember is sluggish and bloated


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


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.


> 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. Dismissing stuff as “recent starts” is pretty cheap, anyway.


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.


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/


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.


> You even introduce a class of bugs doesn’t exist for statically typed languages.

Conversely, you're also able to write equivalent functionality with less code and with idioms you can't use in statically typed languages. It's an engineering trade off, the static typed handcuffs prevent you from making a certain kind of mistake but they also prevent you from writing certain kinds of code that are extremely powerful; many prefer the power over the handcuffs. Type bugs just aren't that painful.


I've had professional jobs writing both Python and Haskell. My Python code has to be far more verbose and complex than my Haskell, and the Python's harder to maintain too!

> Type bugs just aren't that painful.

You haven't learned the true power of a decent type system then.


Few seem to have learned the "true" power of a "decent type system". Which seems to be only Haskell...

And yes, Haskell is terse. Other popular statically typed languages (Go, Kotlin, TypeScript, Dart) are not.


While certainly Haskell lets you do more, you can get some interesting help from even the C type system. For instance, I was able to enforce "this can only be called from the main thread" with no runtime overhead.


You explained this once to me before and it was very cool. Did you ever write a blog post about it? I think it would be neat to link to in the future when these sort of discussions come up.


No, I need to do that.


> "decent type system". Which seems to be only Haskell...

Haskell, OCaml, Elm, Purescript, arguably Scala although I don't like it personalyl.


> You haven't learned the true power of a decent type system then.

Conversely you haven't learned the true power of dynamic types or like coding with handcuffs to keep you safe. What static types offer me is not as useful to me as what they forbid me from doing, so no it isn't an issue what what I don't know, but rather of what I do. And Haskell, no thanks, I'm not a masochist.

> and the Python's harder to maintain too!

That's an issue with Python, not with dynamic types. My Smalltalk code is a joy to maintain.


And what exactly do static types forbid you from doing? (For the sake of argument let's consider state of the art static type systems such as those found in Haskell, OCaml, Elm and Purescript)


State of the art is hardly relevant, what's relevant are languages in demand by employees that dynamic language are actually in competition with so no I don't accept that restriction for the sake of the argument as it's moving the goalpost. However plenty of meta-programming techniques including the use of dynamically interpreting message sends to methods that don't exist in the context of the receiver, i.e. Smalltalk's doesNotUnderstand or Ruby's method missing are but one example.

Look, I get it, you like static typing, how about accepting that we all don't; we value different things from a language, and extreme late binding in all things is something we value more than being protected from ourselves with a type system. Don't assert to others what they have or haven't learned just because their preferences differ from yours.


I think you're responding to an argument I didn't make.

You claimed "Type bugs just aren't that painful". Haskell allows you to make all sorts of bugs into type bugs, from SQL well-formedness, through certain concurrency guarantees, to guarantees that your HTTP routing is correct. So yes, type bugs can be very painful, and that's a good thing!


"All sorts" in a colloquial sense of "very many". Not literally all sorts.


Yeah, good clarification, thanks!


Using Haskell is more painful than any type bugs it might help fix, no thanks. One can write correct code without a type system to guarantee it for them, we're fine doing this rather than dealing with said pain in the ass type system. Haskell is not my idea of a good programming language, it's not what I want from a programming language, it's not conducive to how I want to program. It's an esoteric language for a reason, few people like it and it'll likely remain that way.


OK, if that's your opinion then fine. I just wanted to challenge your claim "type bugs just aren't that painful". On the contrary, they can be and should be!


You can't challenge a claim about how I feel about something, if I say something doesn't hurt, nothing you can say will convince me it does. Pain is subjective, keep that in mind when trying to tell others how they feel about something.


> you're also able to write equivalent functionality with less code

The amount of code one writes says more about the language than whether or not it's statically typed.

To me, adding "bigint" or "bool" to the occasional variable and function declaration isn't "more code", it's an extremely terse way of avoiding different code (e.g. type assertions).


That's not what I mean by more code, by taking advantage of dynamic typing you can write more generic code than is even possible with generics in a statically typed language; code that works for any type, whereas a static language either forbids you or forces you to write multiple versions of the function. You can't write a single Max function in C# that works for any type supporting >=, it simply can't be done. This is typical of static languages, they forbid perfectly good code because it "might" be used inappropriately or because the type system can't guarantee it won't.


> by taking advantage of dynamic typing you can write more generic code than is even possible with generics in a statically typed language; code that works for any type, whereas a static language either forbids you or forces you to write multiple versions of the function.

If you can write code that works for some combination of types, it's because those types present a common interface that could be specified in a sufficiently-expressive static type system, either via something like OOP interfaces or something like Haskell typeclasses.

> You can't write a single Max function in C# that works for any type supporting >=, it simply can't be done.

You can, in fact, do so for any type supporting the IComparable<T> interface. That the operators are defined independently is a C# type-system quirk, not a fundamental limitation of static type systems.


> that could be specified in a sufficiently-expressive static type system

Ah the mythical sufficiently-expressive static type system, I'm concerned with type systems that are in use in real jobs, not vaporware ones that could exist if only. Dynamic language support it now.

> You can, in fact, do so for any type supporting the IComparable<T> interface.

Which requires forethought on the designers of said library, I'd rather have duck typing which works without requiring correct future planning with interfaces.


Nothing is stopping languages from allowing both. For example, it could have some form of compound type declaration.

Meanwhile, how often is code made worse because you have to write multiple Max implementations? And I doubt that there's many instances where such repetition is necessary, or can't be mitigated with wrapper functions.


> Nothing is stopping languages from allowing both

Nothing stops pigs from flying either... hypothetically, but they don't, and languages don't, so debating what they could do is rather pointless, they don't.

> how often is code made worse because you have to write multiple Max implementations

Similar situations occur quite often.

> I doubt that there's many instances where such repetition is necessary, or can't be mitigated with wrapper functions.

That they have to be mitigated is the point, I don't have to do stuff like this at all in a dynamic language, things just work.


Congratulations, you have worked out that there are no perfect languages. I don't understand what point you're trying to make, other than you prefer one set of trade-offs to another.


> other than you prefer one set of trade-offs to another. reply

So you can understand the point being made, congratulations, it's what engineering is all about.


The biggest advantage of dynamically typed languages is the ease of using deeply nested data structures with mixed data types. This is just a pain in languages like Java and Scala where the Any type is often reverted to.


As long as the number of mixed types is finite, unions/variants give you the same ease of use with static guarantees.


A rudimentary end2end test should catch most type related bugs. A type system aids in refactoring, not so much actually catching bugs.


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.


Since most of the stuff I work on are prototypes that might never see the light of day, I love dynamic languages like JS. I always find it confusing why more implicit casts aren't allowed when I have to use things like Python or C#.

If print() in Python includes a string and an int, I think the interpreter should be able to implicitly cast my int to string in order to make it all work. As it stands, I have to go back in and cast it myself, which kills productivity.

Any idea as to why implicit casts aren't more supported in strictly typed languages?

I'd prefer a warning on runtime than having to go back to the code.


> Any idea as to why implicit casts aren't more supported in strictly typed languages?

That's the difference between weakly and strongly typed. If you take a strongly typed language, and add implicit casting, you get a weakly typed language.

How this is resolved (or if at all) depends a lot on the language. For example, in C++ it is straightforward to define implicit conversions (which can become confusing). In Python on the other hand, it is generally up to the receiver to call some kind of conversion function, like str(), which will use an object protocol (like __str__) on the instance. This is what print("foo", 1) does, or "foo %s" % 1.


And still there is no proof, that ease of deployment and maintainability is enhanced through static typing.


Static types are better and cheaper at catching type related bugs than a myriad of end-to-end tests that check dynamic types.


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


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.


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.


Even pigs fly, given enough thrust.


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.


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.


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.


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.


Can you source some of these? Genuinely curious.


You mean sources for languages used in the implementation of various websites?

- Wikipedia is mostly PHP https://github.com/wikimedia/mediawiki

- Wordpress is PHP https://github.com/WordPress/WordPress

- Facebook started in PHP https://www.quora.com/What-programming-languages-are-used-at...

- YouTube started in Python https://www.quora.com/Is-YouTube-still-written-in-Python

- GitHub is Ruby https://github.com/showcases/projects-that-power-github

- Reddit is mostly Python https://www.reddit.com/wiki/faq#wiki_what_is_reddit_written_...


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.


Yes, exactly. Thanks very much. Do you know if Facebook/ Youtube are still in PHP / Python?


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.


instagram, dropbox, etc


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 because I know the pain of linkless comments)


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.


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.


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.


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.



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


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


Your preferences helps you, other developers have their own language and tooling preferences they choose to help make them more productive.

> Just because successful companies use dynamic languages doesn't mean dynamic languages produce successful companies.

Talented resources is usually an ingredient that's shared amongst most successful companies and there is no shortage of talented developers preferring dynamic languages. Dynamic languages like python are also extremely popular in complicated fields like science, AI and machine learning, etc.

> And plenty of those companies had plenty of scaling issues and growing

Inefficient software can be written in any language and scaling issues are more often the result of poor architecture and unoptimal implementation than language performance. A successful company with growing pains is also more valuable than a failed company without.

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

That's incredibly naive. Developer iteration times are much faster in dynamic languages, tools that enable live programming, Hot reloading, faster run/build cycles have a direct impact on developer productivity and are commonly born from dynamic languages. A rich developer ecosystem is also an important factor in being able to quickly adopt well-written tested and hardened libraries which popular dynamic languages have aplenty which is a direct result of being able to attract a large pool of talented developers, languages that can do this are more popular than ones that don't, irrespective of their type systems.


> other developers have their own language and tooling preferences

Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible.

> there is no shortage of talented developers preferring dynamic languages

There is also no shortage of talented developers preferring static languages. And given the two, I know which developer I prefer. Especially since I've never worked with an infallible developer, even in the upper echelons.

> Developer iteration times are much faster in dynamic languages

I disagree, I find I'm about as productive in either, but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either.

> tools that enable live programming, Hot reloading, faster run/build cycles have a direct impact on developer productivity

Those features are orthogonal to the type system.


> Of course if you prefer a language, use it, but don't argue that your preference has any bearing on how well your language helps you avoid issues like runtime type errors that other languages don't experience. You either have to write more unit tests, or pray, or be infallible.

I've not once mentioned my preference. My preference and where I spend the majority of my time developing server libraries and Services C# which I consider the most well-balanced modern statically-typed language available.

But I'm not naive enough to think everyone would be better off developing in C#, most startups prefer dynamic languages with good reasons stemming from being quicker to market, faster iteration times, more malleable in implementing customer requirements and having a rich pool of talented resources available. There are a lot of smart people sharing the same opinion, like Alan Kay:

> If you’re using early-binding languages as most people do, rather than late-binding languages, then you really start getting locked in to stuff that you’ve already done. You can’t reformulate things that easily.

- http://mythz.servicestack.net

Smalltalk was first released 45 years ago and it still has live programming features like being able to re-program its IDE while it's running that I've never seen any static language been able to do. There's a whole class of software I can't imagine being built in a static language, like Wordpress rich extensibility and plugin ecosystem, I've implemented a few Wordpress sites and custom plugins which would've taken an inordinate amount of time in a statically typed language. I've spent a few years developing PHP and I very much dislike PHP based on its language merits, but I have an appreciation of what it's been able to be built with it.

There are other classes of software that are extremely hard to implement in a statically typed language like React which IMO is revolutionary in developing complex UIs.

I also think it's infeasible for tools like Webpack to have been written in a typed language, where its able to import any kind of asset in the source files that use them, being able to easily chain loaders together, running incremental watched builds that transpile source code, generate source maps, inline images, cache-breakers, etc. Webpack's Hot reloading feature would also take significantly more effort to develop in a statically-typed language. Tools like this are born from dynamic languages because it's simply much easier to do which would've taken significantly more effort in a statically-typed language.

I also develop and maintain http://techstacks.io (Server in C#, not that it matters) and see the amazing number of successful products being built with dynamic languages, not in-spite of them. From what I've seen a large majority of successful SV startups use dynamic languages.

Languages and technology should be a tool to achieve your objectives, many technology choices involves trade-offs, dismissing and throwing shade on successful companies usage of dynamic languages prevents you from seeing the benefits they have in using them, what advantages they have and which scenarios where they'd offer the most compelling value. The reason why many amazing software and talented engineers use dynamic languages isn't because they don't know statically-typed languages exist - it's a mistake to write-off other people's choices because they don't share your same views.


> I've not once mentioned my preference.

That's fine, no one was talking about you specifically.

> I'm not naive enough to think everyone would be better off developing in C#

That's good. Neither am I, so I'm not sure why it is being mentioned.

> There are a lot of smart people sharing the same opinion, like Alan Kay

Smart people also have the opposite opinion. It doesn't mean anything; that part is all subjective.

> There's a whole class of software I can't imagine being built in a static language

A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed.

> There are other classes of software that are extremely hard to implement in a statically typed language like React

Define "extremely hard". Would you consider Elm "extremely hard", for example? And why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally.

> throwing shade on successful companies usage of dynamic languages

All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea.

I have no qualms about which companies use which programming languages, as long as the result is a quality product from my (the user's) point of view.

If they get that quality through dynamic languages, good for them. I think they worked harder than they should have, and I think they are spending more money on server infrastructure than necessary, but that's their choice.

But I don't believe for a second that the quality, performance, or the end user experience was improved because a dynamic language was chosen. And this discussion (at least, where I chimed in) was precisely the point where the end user experience was called into question.


> A static language can have an "only known at runtime" type that lets you do the same thing as the default in a dynamic language, when it is needed.

In almost all cases runtime "holes" in static type languages provides a sub par development experience that's worse than both dynamic and static typing, it's definitely not a strategy for developing the same class of software on and it's not comparable to using a first class dynamically typed language. The places where it works is in static type systems are used to annotate a dynamic runtime like TypeScript, Hack and (less so) Dart.

> All I'm "throwing shade on" is the idea that users don't care about quality, and that static languages have no inherent quality advantages over dynamic languages. I disagree with either idea.

Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality.

> why can't that model be used in other statically-typed languages? I think it's only a matter of time, personally.

It doesn't exist because it's simpler, requires significantly less effort and is more naturally suitable to implement in a dynamic language. In these classes of software choosing a static language is the wrong choice that will always yield inferior results due to their lack of dynamic capabilities and interested resources who naturally gravitate around dynamic language ecosystem. No doubt many devs will still try using their preferred static language but they will all fail to achieve anywhere near the level of success, featureset and penetration of equivalent dynamic language implementations.

Of course as it's software, given enough resources anything is possible, like Apple is able to do with Swift Playgrounds but they're in the unique position of being able to change Swift's language and runtime to introduce the capabilities needed to make Swift Playgrounds feasible - which is major strategic project for Apple which I still hold would require significantly less effort using a dynamic language. Google has the same benefits with what they're able to do with Dart where their flutter project offers a compelling live programming experience for developing native mobile Apps. Both would be considerably harder if they weren't able to change the language and runtime to make it easier for them, e.g. snapshots would be nigh impossible without language/runtime support.

Likewise their exists classes of performance and mission critical software that's not suitable for dynamic languages, but it's not always a mistake to start with a dynamic language first to prototype quickly then rewrite once the system requirements have been identified and solidified.


> Suggesting dynamic languages are "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is throwing shade with no basis in reality.

What I suggested, if you go back and read my initial comment, was that static type systems give you a higher chance of improving performance, efficiency, and quality. I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues.

And there's plenty of basis in reality.

> It doesn't exist

It does exist.

> requires significantly less effort and is more naturally suitable to implement in a dynamic language

Maybe since dynamic languages are popular. I'm not convinced that dynamic typing made this easier, or if it just so happens that most people know dynamically-typed languages.

But that's beside the point completely.

The point was pretty simple (I thought...): Quality is visible to the end user, and all other things being equal, a static type system has a higher chance of resulting in quality software.

Now in the real world, of course, all other things aren't equal (otherwise everyone would just use statically typed languages). But choosing a dynamically typed language for those other reasons (your developers are more familiar with it, it has more libraries that you need) should be a conscious choice made knowing full well that you are opening your self up to a class of errors that you could have automatically avoided. If that trade-off is worth it to you (it is worth it to many) so be it. But the trade-off is still there, and when it does cause quality issues, users will notice.

I'm not saying using a dynamic language is a mistake and I'm not saying using a dynamic language guarantees the quality of the result will be lower (nor am I saying a static language guarantees the quality will be higher, although I believe it helps a lot), so arguing against those points is falling on deaf ears.


> Your opinion...

I've provided a number of examples, you've provided exactly none.

> I never said dynamic languages guarantee those issues, or that static languages guarantee the absence of those issues.

Your comments are full of snide comments against dynamic languages:

> That does correlate with being unstable and offline.

> plenty of those companies had plenty of scaling issues and growing pains that just throwing a cache in front of didn't solve

> choosing dynamic just leaves more opportunities for inefficiency and runtine errors.

> You either have to write more unit tests, or pray, or be infallible.

> but in a dynamic language I have to write more unit tests or pray, and I don't like wasting my time on either.

> and all other things being equal, a static type system has a higher chance of resulting in quality software.

Which is categorically False. Software quality refers to how well it adheres to its fitness of purpose and how it competes with competing alternatives. Users generally prefer to use software which are easier to use and provides them the most value where by being able to iterate quickly holds the most value, which is arguably an inherent benefit in dynamic languages and why they're a popular choice amongst startups. Especially when you're competing in a new market category, velocity is of utmost importance.

In fact almost all successful companies that I can think of that were competing in a new software category were developed using dynamic languages including: Facebook, YouTube, Instagram, Spotify, Dropbox, GitHub, Pintrest, Reddit, AirBnB, Uber, Slack, Khan Academy, Coursera, Twitch, Hulu, Kick Starter, Patreon, Trello, etc. Results are overwhelmingly in favor of building new products in a dynamic language. I struggle to think of any recent successful Startups that were able to out compete their competitors and achieved their dominance starting out with a static language. The major ones I can think of predominantly built with typed languages are: LinkedIn (2002), Netflix (1997), Ebay (1995), Amazon (1994). The most recent one I can think of is Stack Exchange (2009) (which I know of because I used to work there :). Of course once they've established market dominance and implemented their core feature-set many go back and focus on optimizing their system of which many identify and rewrite hotspots in more appropriate languages. Which remains a strong case for starting out with a dynamic language first.

> But the trade-off is still there, and when it does cause quality issues, users will notice.

There's a trade-off on whether adopting a static language is worth it, of which most successful SV Startups don't agree with - and their users are better off for it.


> Your comments are full of snide comments against dynamic languages

They are not snide, nor are they "against" anything any more than saying "the sun is yellow" is "against" the color blue.

Half or more of the things you quoted aren't even about dynamic languages, and the other half are true (or do you care to refute them? For example, if you don't write tests to take the place of static typing, and you aren't praying, then you are either infallible (ha!) or you are lying).

> Which is categorically False

Believe what you want; it's clear you aren't interested in opening your eyes. So be it!

And that big list of companies has nothing to do with the discussion. Of course they use dynamic languages. Almost everyone does, because they are popular and because some tasks seem easier in them. But there are still quality issues that could have been prevented.


> They are not snide, nor are they "against" anything any more than saying "the sun is yellow" is "against" the color blue.

> Believe what you want; it's clear you aren't interested in opening your eyes. So be it!

You forgot "Calling the Kettle Black". But I'm more than comfortable with my experience with multiple languages in each style enough to be able to identify their strengths and weaknesses and which scenarios each are better suited to, of which I've listed several examples which are better suited to dynamic languages. Likewise there are many that are not.

> if you don't write tests to take the place of static typing

Tests are essential to software quality and static typing does not absolve you from writing tests. Static Typing enforces Type correctness, it does not enforce program correctness.

> And that big list of companies has nothing to do with the discussion.

It has everything to do with which language yields the most benefits and whether Startups have made a mistake in adopting them, I posit they haven't and Empirical evidence suggests that they're a more suitable choice for Startups.

> Of course they use dynamic languages.

Of course.

> Almost everyone does,

Ok.

> because they are popular and because some tasks seem easier in them.

It's because they provide more value than not.

> But there are still quality issues that could have been prevented.

For which they often provide more benefits then they give up, which is entirely the point, that adopting dynamic languages is not a mistake.

My proposition was that dynamic languages offer better velocity which lets you get to market quicker. Static Typing helps with type correctness and maintenance of large code-bases and it's a perfectly fine strategy to rapidly prototype with a dynamic language first then rewrite identified hotspots and problem areas in a more appropriate language. Script execution performance is often not the bottleneck, a good caching strategy can make any language fast, areas which don't benefit from caching, i.e. high writes / high concurrency would benefit from a rewrite and in a growing user-base, scalability is more important than script execution performance.


> Tests are essential to software quality and static typing does not absolve you from writing tests.

No one said they did. You have to write fewer tests with static typing, not zero tests.

> My proposition was that dynamic languages offer better velocity which lets you get to market quicker

Velocity is subjective - perhaps for the developers in question dynamic languages are quicker to market, but I argue that is more because of familiarity and popularity, and less because of dynamic typing.

For example, developers I work with are just as proficient in both types of languages, and get to market just as fast with static typing, and in the long run they don't need to rewrite or chase typing bugs or spend more money on scaling inefficient software.


> No one said they did. You have to write fewer tests with static typing, not zero tests.

Typing is not a substitute for tests, you test for desired functionality in both. Albeit there's a stronger culture for testing in dynamic languages given they're more of a necessity.

> Velocity is subjective

No, Velocity can be measured.

> but I argue that is more because of familiarity and popularity, and less because of dynamic typing.

That's no argument, it's a weak and sheltered assumption showing a lack of first-hand experience. Don't presume to know that of which you don't know.

> For example, developers I work with are just as proficient in both types of languages, and get to market just as fast with static typing,

Of course you can't know that for sure, but it sure fits your thwarted view of them quite nicely. If that were true most Startups whose existence are hinged on their ability to get to market would not be overwhelmingly be in favor of using dynamic languages. Your goals as a technologist should be to adopt an unbiased view, identify strengths and weaknesses of each tool so you're able to make informed decisions about which use-cases are best solved by either. Your unknowledgeable and disparaging remarks on them wreaks that you're more interested in trying to confirm your own biases than you are on from ever being able to benefit from them in any capacity. Learning the idioms and being proficient in multiple languages will make you a better programmer, you'll learn elegant techniques, new perspectives and be able to identify friction that you can apply back in your primary language. You'll also be more productive in the large number of use-cases where they're naturally better suited. Add one to your toolbox today!


> in dynamic languages given they're more of a necessity

Sounds like you came around.

> No

Not everyone agrees that dynamic languages lead to faster velocity. Velocity is a function of many things (environment, culture, tooling, existing code bases, developer skill and familiarity with a language, how low you set your quality bar for your mvp, etc) and as I mentioned a few times now, different developers have a better velocity when working in statically typed languages.

"Improved velocity" is not an inherent property of dynamic languages, it depends on many other factors as well. I'm not sure why you keep ignoring that point (well I have an idea why...)

> it's a weak and sheltered assumption showing a lack of first-hand experience

It's not an assumption, it's an observation that I think extends beyond my direct experience.

I've trained many developers who were huge dynamic language proponents much in the way you are right now: any mention of an advantage found in a static type system sent them off into vague or straw-man arguments about how productive they found themselves in their dynamic languages, how flexible it made them, and how handcuffed they thought they'd be if they tried a statically-typed language.

In reality, they had never taken the time to learn any of the decent statically-typed languages, and when I probe as to why, the reason is usually because it takes more effort and because those languages aren't as popular (and sometimes a fear of the unknown).

Once they get up to speed, they find themselves just as productive, writing fewer tests, and producing higher quality software.

Of course it helps that the culture around me fosters that kind of thing: we write or provide tooling, and we have the senior developer resources to help other developers where a quick stack overflow answer won't solve their immediate problem, but as I said a few times now, those points are all orthogonal to mine.

> [Long string of ad hominem remarks]

I'm not sure why you think you know me, my experience, or what I'm proficient in, but you are mistaken (and if you had read the comments you replied to more carefully you might have realized that).

Since that's not a productive way to discuss a topic, I'll leave things here. If you wish to change the way you converse, I may be back, but it's unlikely.

Good luck in your endeavors.


I wanted to leave it, but it's full of misguided assumptions, so I'll keep try it short.

> Sounds like you came around.

No my experience hasn't changed, I've delivered solutions in multiple languages (with a majority of them in static languages) and am familiar with realities and cultures in each. I'm a proponent of technology and adopting the best language/tool for each use-case. I could list all the areas where dynamic > static and vice-versa but you're not interested in learning where they provide the most value so I wont bother. Using a single language/tool for everything is an inefficient use of developer resources. When I started out I also used to hold an affinity to my preferred language, but that eroded over time as I became aware of where my preferred language and ecosystem deficiencies and where their strengths lie, my primary concern is adopting the best technology that creates the most value with the least time and effort where I regularly use and explore different languages and frameworks to gain experience in them so I can identify their strengths, techniques, approaches and which areas they excel at.

> Not everyone agrees that dynamic languages lead to faster velocity.

An overwhelming majority of successful Startups do, you've yet to show any evidence suggesting otherwise, just biased hearsay. The most valuable Internet properties and successful startups are built on dynamic languages so your disparaging remarks suggesting they're "slow, unstable, drains your battery, is constantly offline, or has major security flaws" is a completely false straw-man that amateurs would say - those are not a function of language or in anyway represent the value created or talented engineers using them. If you actually believe this, it shows you don't have any first-hand knowledge or experience using them so I can only assume your remarks are used to reaffirm your own technology confirmation biases, either way that's how it comes across when delivered as a baseless slur. Personally I would've liked to see some examples and empirical evidence backing up your theories, because as it stands none of them hold any water.


You continue to argue against points that were never made and you claim my position is something which it is not. At this point I have to assume you are doing it intentionally, but either way, I'm not interested in being misrepresented constantly.


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


I'm very satisfied with the new typing [0][1] module. It's part of the standard library since Python 3.5 and it provides type annotations similar to those of Typescript. It's still missing some features (IMO), but it's also under active development, so I guess more useful features will come.

  from typing import List

  Vector = List[float]

  def scale(scalar: float, vector: Vector) -> Vector:
      return [scalar * num for num in vector]

  def greeting(name: str) -> str:
      return 'Hello ' + name

[0] https://github.com/python/typing [1] https://docs.python.org/3/library/typing.html


what would you say are the limitations of Python type annotations? From the pycon demos I've seen it seems pretty functional and complete.


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


> I basically can't figure a way to annotate a function that takes an int/float/decimal/etc.

It seems like you should be able to just annotate it with float?

... when an argument is annotated as having type float , an argument of type int is acceptable ...

https://www.python.org/dev/peps/pep-0484/#the-numeric-tower


Hmm. I wasn't aware of that; still, it seems to not work for Decimal objects.


You don't need comment based annotations since there are real annotations since python 3.5


I can't tell if you're neglecting the fact that most production Python is Python 2 on purpose or not


While true, my codebase regrettably needs to run in Python 2.7.


I mostly found the type annotations to be sufficient, though the tooling look leaves something to be desired.


Annotations at least help the IDE dig through the mess faster. That's ... something. I guess.


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


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.


Is Typescript necessary for front-end Javascript?

In the many years I've done front-end with Javascript, type-related bugs were very, very rare. Textbook logic as why to use strong types make absolute sense. Yet in the real world, I've had to fight with logic, DOM, UX, framework incomprehension and other types of bugs - not types. Type issues were anomalies among bugs. When they came up, they were the easiest to fix.

Am I alone here? Anyone in the community have concrete examples of type-related bugs that took so much time to required using something like Typescript? Can anyone quantify that?


> In the many years I've done front-end with Javascript, type-related bugs were very, very rare.

Wow, really? My experience has been the complete opposite.

Most of the bugs that slip into production have been dumb type errors. Things like accessing a property on an null/undefined value, or on an object that doesn't have that property and unfortunately JS just returns `undefined` instead of complaining (these silent ones can live longer before being spotted).

It's because of these kind of bugs that i've found many JS codebases tend to become brittle to the slightest change, and very difficult to refactor into a good shape. And why i'm seeking statically typed languages like TypeScript on that front at the moment.


But that's really a symptom of a "big ball of mud" design (non-design, really), where everything has dependencies scattered all over the system, and to change anything you have to consider everything.

Type checking can help you with a few kinds of problems you'll have trying to make changes in those kinds of systems, but you still have piles of problems and it doesn't do anything to help improve the underlying issue.

Static types can help you with some small problems, but that doesn't mean much when the problems you have are big.


> But that's really a symptom of a "big ball of mud" design (non-design, really)

Yep, that's exactly the problem :)

The thing is that, without ease of refactoring, it's very difficult to change that big ball of mud into something prettier. In fact, i'd say that without ease of refactoring it's kind of inevitable to fall into that big ball of mud "design" in the long run.

(Note: static type systems are not the only tools to help with refactoring. Good test coverage, style guidelines, a well documented / simple architecture, are of course very helpful too.)


Exactly. Static types ( I've used flow not typescript, but similar ) and good unit tests allow ridiculously easy and merciless refactoring of enormous swaths of code in an extremely short period of time with incredibly high confidence.

Integration tests ( not to be confused with functional tests / i.e.: selenium ) that test multiple classes in concert via input / expected output give the most bang for the buck, because you know your code works as a whole.


Static types are especially useful in big ball of mud design because you can refactor it (like change the shape of a canonical object) and mechanically fix all write/read sites without running the code.

Not sure how that's a small problem unless you never refactor code.


It's more likely that OP finds such errors just as frequently but because they are relatively straightforward to fix he doesn't weigh them as much as edge case debugging.

I've heard this same argument from a coworker working on a different project recently working on React/ES6 stack - I check their TFS history and find 3 such fixes in last 2 weeks (and they have reviews before checking in to TFS).


There's a lot of type bugs in my code as I type it, and while I'm writing the unit tests, but I've been keeping track for the last year or so when they happen in QA or Prod and they are quite rare for us (as part of an evaluation of if we should move to Flow/TS).

But there was a heavy correlation between type bugs and the kind of code being written. Our transactional frontend apps? Most bugs are browser css issues, weird environment specific edge cases, misunderstandings of the backend, memory leaks, etc.

In apps that are data heavy though, or backend JS apps, its a whole other story. Type bugs all day every day (though a part of it is because we don't do many and they aren't high profile here, they're very light on tests).

So we moved the later to using tests. While it helps a lot, we did end up with a different kind of issues: broken type definition issues and bugs in the type system. Turns out a very large portion of DefinitelyTyped definitions (especially those of the more obscure libs) are broken and you can't trust them, but you lose a lot of time fixing runtime bugs the type system forced you to make. And while they never hit production, there's more bugs than expected in TS itself, and it takes a while to figure out if I'm doing something wrong before I go look at the bug tracker (the issues I hit have almost always been reported already, but I don't expect them). Fortunately that last category rarely cause issues in production.


> while I'm writing the unit tests

With types you can test quite less. You still should but test code is the worst code, it turns legacy so quickly.


If you're only writing good tests, there's very few tests you wont write: eg, if I test that my function returns the string "Foo", I don't need to test that it returns a string.

And even in sound (er) type systems like Haskell or Elm, I'd (probably. There are ways...) have to write that test.

In JS with Flow or TS though, there's very few (good) unit tests you don't need to write anyway. If your tests are filled with "expect(foo()).toEqual(expect.any(string))", the team needs to be coached on writing proper unit tests regardless of types.

Though the topic that most teams don't know how to write effective unit tests and that type systems help those teams is a totally separate one.


Isn't refactoring TS also unpredictable? since its type system its no sound.


The short answer is: it depends. With TS you can choose how much type "soundness" you want. The --strict option is very useful[1], but even having it enabled you can still choose to explicitly type something as `any`, and bypass the typechecker if you want.

Something to note though: the example given in the article is not showing any problem in TS. That's how its structural type system works. Both Animal and Bird classes don't have any properties, so the type of their instances is the same as `{}`. If you change the Bird class to something like:

  class Bird extends Animal {
    song: string
  }
Then the line that tries to push a `new Animal` into an Array<Bird> will not type-check, because the types are invalid :)

[1]: https://www.typescriptlang.org/docs/handbook/compiler-option...


Unfortunately I feel that this type of example expresses what not to do with type systems -- favoring composition over inheritance goes a long way to not finding yourself in a brittle type hierarchy and especially in a JavaScript environment where composition is so easily used (and with typescript, still type checked)


One solution to the any typing problem is to use tslint with no-any. It's a bandaid, but it's better than nothing.


Type errors might not be the biggest issue up-front when writing new frontend code, but refactoring JS becomes really hard as the LOCs grow. Typescript (static typeing in general) really helps with this as you can get instance feedback about how you're changing interfaces between parts of the system.

Another reason i've enjoyed TS is the editor intellisense support. It's really helpful when using a library to get type info in your editor instead of having to google when you forget what a function returns, for example. This is also helpful when you're coming back to code you wrote a long time ago, or a colleague wrote it, and you don't know what particular variables/function arguments/object properties are at a given spot in the code.


Oh yeah, that's another great point (although you're still stuck with the fact that somebody can access object properties by key).


Couldn't you solve this with privates, either via a naming convention or with symbols, as well as using getters?


Not really. If I declare that an object has property xyz obj.xyz and obj['xyz'] are both valid ways of addressing it.


Absolutely. Typing is a real timesaver as it adds so much to how much an ide can help you.


Like others, my experience was also complete opposite.

The app I did was a financial related app so we do some good amount of number crunching. From calculations, to transfers, and storage.

You won't believe how many type errors we had throughout the stack. It's definitely because of JavaScript's inability to do type checking.

One workaround people did was to do the type checking in the first few lines of the function call, which is how people that still do raw JavaScript, do it today.

    function add(a,b) {
      if (typeof a !== 'number') { ... }
      if (typeof b !== 'number') { ... }

      return a + b;
    }

This eventually creeps throughout in the code and introduces this code smell.

This above can be solved by just using TypeScript.


For me it is not about catching bugs that would make it into production; I agree those are relatively rare. It is about catching simple mistakes while I'm in the middle of coding or refactoring. These are mistakes that even without the warnings would probably not even make it into a commit, but the warnings directly in my editor in real-time are an even shorter round-trip than test executions. It results in less fumbling around to find the actual cause of some failure.


I have seen quite a few of those - mostly in returning promise vs actual value from function in some special case.

The other class of errors was with objects that reference other objects - e.g. function takes `loggedUser` parameter which is expected to have property `finishedLevels` or some such and someone sends it `bestFriend` object that kinda looks similar but does not have 'finishedLevels` property.

Most importantly, you have to code differently when writing without typing. It felt as if my hands were cut of at first - I was often in "I would solve this easily in Java just by making interface that would communicate list of needed methods, but cant in javascript because there is no such thing as interface". This is also the likely reason why you do not see many bugs - you probably learned to avoid all those patterns and idioms.

Even more importantly, it really helps with refactoring if you can rename function/variable or change number of its parameters and have all the places (and exactly them) that call that place return error. I can refactor much more aggressively when working with java vs javascript. In java, I spend a lot of time changing existing stuff, when I am tired to do hard work. In javascript it is special thing you do when you are well rested and fully focused.


One major argument is that TypeScript gives you arity checking on function calls, especially as you're refactoring. Seems like a simple thing, but after using TypeScript I realized how much time I wasted solving things like that.


> Am I alone here?

I am not a Javascript person, but my personal experience has been similar.

FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.

Lately I have warmed up to statically typed languages, but among all the bugs I have run across in dynamically typed languages, unexpected/invalid/wrong types were very, very rare.

The benefit of good type system - IMHO - is not that it keeps you from putting string where a number is required. That kind of problem happens, but is usually easy to fix. But a type system that helps you distinguish between, e.g., numbers that are temperatures and numbers that are air pressure measurements is worth having around.

EDIT: I admit, C's type system is exactly the most sophisticated one I've seen.


> FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.

How is that a non-issue? If you don't have unit tests covering your entire code base you wouldn't notice a bug like that until it broke in production.

Having type checks let's you catch obviously wrong things like accessing a Promise return value directly rather than interacting with it as a Promise (i.e. then or async/await).


> How is that a non-issue?

In C, there is a distinction between a value and a pointer to some value. In Javascript, as far as I understand, everything is a reference, so the specific mistake the C compiler caught would be impossible to make in Javascript in the first place. (Then again, C does not have concept of promises.)

I am not saying type checks are bad or useless. In fact, over the years, I have grown to appreciate every little bit of advice a static analyzer can give me. But among the bugs I have produced using dynamically typed languages, few had to do with using the wrong type.


> C's type system is exactly the most sophisticated one I've seen.

Oh-oh, too late to edit.

Of course, what I meant to say was: C's type system is NOT exactly the most sophisticated one I've seen. ;-) I like C a lot, but type safety was not its top priority.


Is it "necessary"? Of course not. Lots of people have done without. I do find that it makes it more productive and easier to debug, especially if you're making something like a SPA with complex functionality.

Also, the point isn't so much that there is one major, hard-to-fix bug, but that there are lots of small ones that you never encounter.


I agree. Type-related bugs of the kind that TS can catch are indeed rare and trivial. However, TS does help with documentation, intellisense and refactoring. Personally, I will usually go with Babel/JS, since I don't find that the benefits of static typing outweigh the costs.


I find the costs of static typing very low. What costs do you have in mind?


Everything required to add that to regular Javascript: transpilation, extra markup and understanding and mastering a new tool. Another layer to manage and debug if you will.


Assuming you use ES6+ in production, so you need a build step anyways, would you still say TS adds costs that aren't worth it to you? And if so, which costs? I mean that in full honesty, as I generally find myself conflicted whenever I start a new project: TS or ES2015+?


Now browsers support most of ES6, so you only need build step for deployments, and can have fast reloads without a build step when developing.


Oh. But these days most JS projects are in some task runner anyway.


> Javascript, type-related bugs were very, very rare.

That's because you're not seeing them. I bet that if you plug your frontend to an error-reporting tool (e.g. Sentry) you will be overwhelmed to see all the corner-cases you are overseeing.


but how much of these edge cases are really happening?


Sentry and tools like it are reporting errors that are happening in production to real users.


Ah okay, so it's not reporting theoretical edge cases but real errors?


Yes


Javascript without type info is nearly impossible to refactor effectively.


Catching wrong-type bugs is, for me, relatively low on the list of reasons I enjoy using Typescript. A few of my higher items would be: strictNullChecking, intellisense, and refactoring.


Agree the academia-touted benefit of type-checking isn't that helpful in practice. But types help with documentation and tooling (completion, data-mapping etc).

Types are (apparently) crucial for large projects. However, the #1 benefit is speed, which I don't think Typescript can provide.

Sorry I can't quantify any of that.

EDIT I am curious why this was downvoted.


The number one benefit is that it makes it painful to write certain classes of error prone and hard to read code.


It's hard to take these kind of posts seriously when Reddit mobile site is one of the worst performing SPAs I've ever used.


The reddit mobile page is a (bad) joke and the app is far inferior to 3rd party offerings (personally I use Sync).


+1 Sync Pro


What are your specific criticisms?


After I wait eight seconds for the page to load, I see your lovely reminder that I should "View Reddit in the app because I deserve the best." At the very least, you could have the decency to harass me about your app while I'm already waiting.

Also, I can load the desktop version of the site in under a second on my phone. IMO y'all should've stuck with some good old fashion HTML and CSS, especially since there's nothing dynamic about Reddit's content.

Hell, you guys could probably get away with responsive styles alone, but I get it. As a business, you find it optimal to piss off your users into downloading an app so you can send them push notifications, dig into their contacts, and find out where they're eating tacos.


> IMO y'all should've stuck with some good old fashion HTML and CSS, especially since there's nothing dynamic about Reddit's content.

Agreed.

I use mobile tethering as my home internet. Currently reddit loads in under 1 second per page usually. The new JS-heavy profile page usually takes 5 seconds or more to load (assuming I'm willing to enable JS to see whatever crap is on one when I bump into them -- usually I'm not...) Note that that's with full bandwidth. When I hit my data cap, I'm throttled to 8KB/s... The current design of reddit is one of the few sites that I can actually reliably load quickly under those conditions! They should seriously think twice about throwing away something that works that well.


Personally, I find the entire experience to be incredibly slow. Loading the front page takes multiple seconds, there is a noticeable delay between tapping a link and any form of response, and back navigations are often unexpectedly slow.

Non-SPA related, I also think that many of the touch targets are too small, or work in unexpected ways. Tapping a username collapses a comment, even though there's an arrow next to it. Tapping an image associated with a link doesn't follow the link, it expands the image (even if it is an article link). Tapping the title takes you to the comments, not the article. The only way to get to the content is to click the itty bitty domain title beneath the title. All of these behaviors are different than how the desktop view behaves. For a site that calls itself the front page of the internet, it's getting harder and harder to get to actual content.


Install the app! It solves these usability problems. No? ... waits 5 seconds... HEY INSTALL THE APP. HEY, HAVE YOU HEARD OF THE APP?


That's funny. Reddit took over my [desktop] web surfing precisely because of how much faster/cleaner it is than any other comparable website. Beaten only by HN.


HN is usability and speed taken to the extreme. I mean it the personification of Unix philosophy 'do one thing and do it right'. So no bloats.


I am going add my experiences here, in hopes someone from Reddit sees them, but they are more or less the same as everyone else's criticisms.

The reddit mobile site takes 13 seconds to load on my Nexus 6 over wifi. Then it has the nagware ad to try to get me to install the app, which only has a tiny 'go to mobile site' link directly underneath the large 'continue [to download]' button. Once reddit has finally loaded, every link will then first ask you if you want to view the link the app, before allowing you to continue. Meanwhile the UI, while cleaner, is debatably worse off UX wise as everything is now small and laggy.

So to summarize, it is terribly unperformant app, filled with dark patterns and dubious UI improvements.


On Chrome on iOS on iPhone 6, posts take too long to load, and having more than 3 gifs expanded at once crashes my browser. Also manual pagination instead of infinite scroll is a little annoying.

Works very well otherwise.


[flagged]


We've banned this account for repeatedly breaking the HN guidelines.


I've worked with TypeScript on and off for a couple of years now. I don't like it.

The compilation step is a major pain. Even after using it for several months straight, I feel like I'm in a constant battle with the compiler. It's slow and difficult/annoying configuration problems keep coming up from time to time. It slows down my debug cycle and the compilation delay makes me lose my train of thought. I used to love using console.log() to quickly test an assumption in JavaScript; you cannot do this with TypeScript (it's not practical given the 5 to 20 seconds compile time); you have to use the debugger every time and step through stuff (even when you have a very good idea about which specific variable you want to check) - It's extremely cumbersome.

I have gone back and forth from dynamically typed languages to statically typed languages many times for years and I've spoken with engineers who used to be Java developers for many years, then switched to Javascript, then TypeScript and they shared the same thoughts as I did. TypeScript is slow and restrictive in a way that is unnecessary. It's got Microsoft all over it.

Also it forces all developers to use bulky commercial IDEs like WebStorm because you rely more on code completion to help you figure out the right types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript plugin is not good enough unfortunately.

At my previous work, even developers who said that they liked TypeScript secretly didn't like it because they used the 'any' type Everywhere.

I wonder if the people who are making this decision have actually tried TypeScript themselves for any decent amount of time on a decent sized project. I don't think they know what they're getting into.

I decided not to renew a lucrative contract at a finance firm as a front-end developer in part because I did not enjoy using TypeScript every day.


> It's slow and difficult/annoying configuration problems keep coming up from time to time. It slows down my debug cycle and the compilation delay makes me lose my train of thought. I used to love using console.log() to quickly test an assumption in JavaScript; you cannot do this with TypeScript (it's not practical given the 5 to 20 seconds compile time);

Have you ever used `tsc --watch`? First build can take long but modification and rebuild takes < 1s.

> you have to use the debugger every time and step through stuff (even when you have a very good idea about which specific variable you want to check) - It's extremely cumbersome.

You don't "have to" use the debugger if you prefer `console.log` all the way. However in the debugger there is a "watch" tab for inspecting specific variables.

> Also it forces all developers to use bulky commercial IDEs like WebStorm because you rely more on code completion to help you figure out the right types. You can say goodbye to Atom, Sublime and the rest... Atom's TypeScript plugin is not good enough unfortunately.

VSCode? https://code.visualstudio.com/


Using console.log is not practical with TS because I only get one chance per debug cycle to log the value of the variable which I think is of interest. If that doesn't give me any insight, I have to log another variable. This is fine with JavaScript because it takes me about 2 seconds to add a console.log and check it. With TypeScript, the cycle takes about 10 to 15 seconds, so it's not efficient to do that, so yes, I end up having to fiddle with the debugger, add watchers and hover over individual variables... I kind of have to deal with the debugger's clunky UI every time which is slower. If source maps don't work correctly (as was the case for a lot of projects), then the debugger is even more of a pain.

I've worked on TS on large existing projects as part of large teams. In my last project, we did have some sort of file system watcher but it still took > 10 seconds on average to compile. Launching the project from scratch took longer than 1 minute. From time to time, I did have to relaunch the whole app; usually for a different reason every time.


I have been working now for 2 years with Typescript on a heavy SPA in combination with ASP.Net / AngularJS 1.5 components, and absolutely love it. I have zero compiler issues. We started with plain javascript but switched to Typescript later on, and it still amazes me how many small mistakes we made that have been preventing by just adding typing. Automatic Refactoring and Find Usages alone are worth 10x the small delay in compilation.

The biggest gripe I have is that Chrome debugging is hell, because sometimes it will recognized the typescript, sometimes only the javascript. I have hit Ctrl-P many times to "establish" mappings between files running in IIS Express and local files. Miss and hit.

I use console.log all the time so I don't understand your comment in that regard. It works perfectly fine with Typescript.


Ah yes I had forgotten about the source map issues. My point is there is almost always something wrong with it depending on the project. The source maps issues are pretty serious.


Not having the same code on paper and on machine so to speak does make debugging typescript a little hard. It's a little bit of a black-box.

I code typescript for Angular 2/4, and although yeah, the aforementioned debugging pains are annoying, the time saved on having types to enable linting and strong predictable variable comparisons, is much greater.

Also, needing console.logs everywhere should be discouraged. Your code should be clear enough that you don't need a console.log debug line to print the boolean result of a comparison, for example. This is the whole point of typescript like I said, to make variable comparision and management easier so that you don't need that console.log line...


I don't mean leaving console.log everywhere, just when debugging, when you want to check the value of a specific variable quickly without having to click around in the debugger.

Developers from statically typed backgrounds just don't seem to understand this use case. It's the quickest way to find an issue when you have a good idea of where the problem might be.


I suppose. I come from the C and C++ world, before I moved onto webdev (quite rare for a young millennial like me to be dinkling around with static C-related languages, I've been told by older colleagues), so I guess that I don't see it from the most understanding point of view.


I also used a fair bit of C/C++ in the past, the debugging process feels very different to me. It's definitely much slower but in that case it's worth it because of the flexibility you get out of it.

When you use Javascript for a few years, your habits change and you get used to really quick debug iterations. With Typescript, you get slower debug iterations but you don't get any extra flexibility beyond what Javascript itself offers. No pointers, no threads, no low-level access to system calls, no custom memory allocation, no performance gains... It doesn't have any of the features that make C/C++ an awesome language.


No, we understand that use case.

It's just usually indicative of code that can only be understood by running it.

Good statically typed code can be understood by reading it.


This is the first negative comment I've ever heard about TypeScript, which makes it really interesting. I thought it was all praise.


You don't need years of trials. One thing that people forget is that types are a parallel ecosystem more times than not i.e. DefinitelyTyped. So you do not have that lock-step that is praised. So imagine wanting to use a brand new webextension api - stop, add it to types. Want to upgrade a dependency - stop, the types are not working/incorrect/incomplete e.g. https://github.com/DefinitelyTyped/DefinitelyTyped/issues/17...

AFAICS the Typescript types ecosystem is bigger simply because Typescript has been advertised to devs coming from a background of a statically typed lang, and they cannot imagine not using types, thus they drown in them.

Flow on the other hand appeals to those that want types primarily in their own codebase, and come from inferred/dynamically typed langs, where you gradually add static types starting with key sensitive parts in your codebase e.g. Erlang http://learnyousomeerlang.com/types-or-lack-thereof


I think some developers have had a grudge with Javascript since the dawn of time and just cannot move past it. They'd rather move mountains than try to adapt to the environment.

Definitelytyped is frustrating; sometimes they have the type definitions sometimes not. Often the definitions are out of date and new ones are not available. Sometimes I feel that it's better not to use it at all... That way I don't have to think about it.


You don't have to add types to start using a new library or web extension. At most you have to add 'declare var foo: any;' or cast a builtin to any if the type declaration doesn't have the property you need. Typesript always lets you use the any type as an escape hatch if you don't have types.


What about using the TypeScript toolchain as a JavaScript static analyis tool without actually writing in TypeScript? (tsc can still verify your js files are minimally 'correct' through type-inference, for example).

More

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

Search: