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

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.

    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.

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