Yes, similar questions have been asked but always with the aim of finding out 'which one is better.'

I'm asking because I came up as a dev primarily in JavaScript and don't really have any extensive experience writing in statically typed languages.

In spite of this I definitely see value in learning C for handling demanding operations at lower levels of code (which I assume has a lot to do with static vs dynamic at the compiler level), but what I'm trying to wrap my head around is whether there are specific project contexts (maybe certain types of dynamic data-intensive operations?) involving things other than performance where it makes a lot more sense to go with Java or C# vs. something like Python.

  • 5
    The answer is "Yes". Each type of language - indeed each language - has its strengths and weaknesses and so is better suited to some tasks than others.
    – ChrisF
    Commented Aug 11, 2011 at 20:18
  • it's interesting that you use C as an example, since it's sort of the most weakly typed language you could concieve and still call it statically typed. C isn't fast because of the type system, type checks happen at compile time. C is fast because there are few or no security measures and checks to prevent you from shooting yourself in the foot. and because it compiles to native binaries.
    – sara
    Commented Jul 16, 2016 at 13:22
  • Welp. It finally happened. The front end web has been overrun by carpetbagger Crockford minions who hate JS because they believe in strict types uber alles. Commented Oct 18, 2023 at 0:16

5 Answers 5


Yes, definitely.
Dynamic typing has definite advantages in cases where you want to be able to treat everything as one single type. Serialization/deserialization is one of the classic examples. This is why so much Web programming is done in dynamically-typed scripting languages: they're well-suited to a task which involves a whole lot of converting all sorts of data to and from strings.

For application programming, on the other hand, static languages work much better because trying to treat everything as one single type is not frequently a requirement. You often want to have efficient data structures with data represented as itself and not getting converted to other types very frequently. This makes the features of dynamic typing a drawback instead of a benefit, which is why applications are almost exclusively written in statically typed languages.

  • 4
    @Erik: I'm not sure I'd even say that. Things change during development. Requirements can change, or you find that you're not implementing a requirement correctly, and the code needs to be updated. Being able to change one thing and use the resulting compiler errors to show you where to find everything else that needs to be changed provides a huge boost to convenience and speed of development that you lose in languages where that technique is not available. That's one of the reasons why you just don't see complicated apps developed in dynamic languages. Commented Aug 12, 2011 at 5:53
  • 9
    @Mason Wheeler: Very good answer.+1 I would add that static type checking also helps to find bugs earlier by having the compiler check type correctness. E.g. I debugged a 200-line Ruby program yesterday and there were two bugs related to type that I could only detect by running the program. I do not want to think what happens in a 100000-line project. So dynamic typing gives you more flexibility, which is good in the contexts you have described, at the price that you cannot find certain bugs at compile time. So statically typed is not only related to efficiency, but also to correctness.
    – Giorgio
    Commented Apr 21, 2012 at 11:11
  • 1
    @MasonWheeler Two years and a lot more C# and Java than I bargained for later I would now disagree with a couple things. Complex web apps are done entirely with dynamic languages. Compile vs. run time is meaningless when you can make changes that are visible immediately. And I've developed the opinion that all the fussing over types makes a lot more sense in a procedural language than it does in a language that's supposed to be driven by OOP where data shouldn't be changing hands constantly in the first place. Commented Jul 5, 2013 at 21:13
  • 1
    @Erik: *wince* First off, judging static typing as a concept by Java is like judging cars as a concept by the Pinto. And second, anything where changes can be "visible immediately" is, by definition, not a very complex program, because even with modern hardware, complex programs take a fair amount of time to prepare the code, whether it's a compiler or an interpreter (or a JIT compiler) doing the preparation. Even the most impressive web applications tend to be very simple programs backed by very complex databases, which is a whole different matter. Commented Jul 5, 2013 at 23:09
  • 1
    The ability to make complex abstractions is orthogonal to having a static vs dynamic type system, and also orthogonal to speed. There are static type systems out there that allow for incredibly powerful (albeit sometimes arcane) abstractions. Having changes that appear instantly is also independent of the type system: you can certainly build interpreters for statically typed languages.
    – Rufflewind
    Commented Jul 1, 2014 at 6:29

The way I look at it is, if you can work naturally within a statically typed language, then static typing is the way to go. In general, the purpose of a type system is to prevent you from performing operations with undefined semantics - like (string) "hello" + (bool) true. Having the extra level of safety preventing you from performing these operations can be a good way to prevent bugs in your code, even without extensive unit tests. That is, type-safety provides another level of confidence in the semantic correctness of your code.

But type systems are very hard to get right. I don't believe there is a perfect type system in nature at the time of this writing. (By "perfect type system", I mean a strict type system, that doesn't require verbose code annotations, that generates no false-positive type errors, and whose type errors are easy for the programmer to understand.) Further, it can be difficult to understand the really good type systems that do exist. When I was learning Haskell, I can't tell you the number of obscure type errors that I got while attempting to write what looked (to me) like correct code. Usually the code wasn't actually correct (which is a point in favor of the type system), but it took a lot of work to understand the error messages from the compiler, so that I could correct the underlying problems. In OO languages, you may eventually find yourself thinking "this argument should be contravariant with the input type, not covariant!", or (more likely) reverting to typecasts to escape from the bounds of the type system. Type systems can get much trickier than you'd think.

For what it's worth, it's my understanding that the difficulty in coming up with good type systems is part of what motivated Gilad Bracha to include pluggable type-system support in Newspeak.

  • WRT unit tests, I completely agree. You always see people saying "if you have good unit tests, they can verify type correctness for you." That's always reminded me of how Paul Graham (who strongly believes that dynamic typing is always a good thing) says that a language making you manually do the compiler's work for it is a flawed language. Sorta makes you stop and think... Commented Aug 11, 2011 at 21:47
  • I think many of the concerns about the 'dangers' of dynamically typed languages fail to take in account how we write this stuff. Much of Python and JS can be written console-style. Screw compile vs. run-time, I can try it out right now and see what happens. I think you are on to one very good point, however. Nothing makes me crazier in client-side web development than when all the supposedly good browser vendors give a confusing pass on horrible code while IE6 or 7 does the unexpected, which is to crap out when it's supposed to rather than just, well... sucking in a more typical fashion. Commented Aug 12, 2011 at 6:21
  • @mason-wheeler mismatch types are trival errors, and it's not that dynamic languages don't check the types, it's just at runtime. I'm my experience most static language's have the same level of coverage of unit tests, they aren't losing any tests from having the compiler check there types ahead of time, and dynamic languages aren't having to add specific tests to check types, the runtime system checks your types, if your unit test cover your method it would catch them.
    – jbtule
    Commented Aug 12, 2011 at 12:50

They're different tools, but it's not by performance. It's all about complexity.

Dynamic languages usually aim maximum flexibility, and it brings lack of validation and a sort of guarantee. Then, it's very powerful in small scale programs, but it becomes almost impossible to maintain large scale programs (complexity).

Static languages usually aim maximum validation. Their first goal is usually catching errors (or bugs) as early as possible. Many guarantees are made for the validation. Then it's harder to learn and start, but as programs goes larger, it provides better program validation with far less cost (coding efforts).

As a result, dynamic languages usually fit for small (I mean very small) programs such as dynamic web pages, web browser DSL (not for browser applications!) or shell scripting. Static languages suit better for system programmings or any other stuffs.

Above descriptions are something about very purely dynamic or static languages. Most real-life languages are in between them, and shows various characteristics.

See here for more details: https://softwareengineering.stackexchange.com/a/105417/17428

  • 1
    "dynamic languages usually fits for small (I mean very small) programs": In my experience you can use dynamic languages also for middle-sized applications (and, of course, there are people using them successfully for large applications). I agree that the larger the code base becomes, the more you can profit from static checks provided by static languages.
    – Giorgio
    Commented May 4, 2014 at 10:00
  • 2
    @Giorgio Well, that's maybe because I'm addicted on the static validation stuffs. It's so sweet to me, and I literally can't live without them even on small scale :p
    – Eonil
    Commented May 4, 2014 at 11:13
  • I see the advantages of static languages (and I have upvoted your answer). Recently I have been using Python and Common Lisp and I admit that in practice you get good results if you use a clean design and, especially in Python, if you write enough tests. These languages can be very effective to build a prototype that can then easily turned into your production code. But, yes, for the more complex projects I would like to have as much help as I can get, so I prefer a static language.
    – Giorgio
    Commented May 4, 2014 at 12:11

I currently program in static type languages (C# and F#), but I enjoy programming in dynamic languages (Smalltalk, Ruby). There are a lot of pros and cons that people associate with one type vs another that are more about the language than when you enforce types. For example, dynamic languages usually have a cleaner, more concise syntax, however F# and OCaml with their type inference system have as clean a syntax as any dynamic language. And with static typing, you have real automatic refactorings and autocomplete, but Smalltalk, with it's entire source code in a database and each method compiled separately, was the first language to really have serious automated refactorings, and it worked great. Ultimately, modern dynamic and static languages today are type safe, which is the most important aspect of your type system, and automatically testing for correctness is done by unit testing, which you'll be doing in both types of languages.

  • I have at times suspected that static typing is only a small part of the equation of what makes a language more or less flexible. I think what I'm also starting to realize is that a lot of devs prefer a comfy set of rails to guide them rather than having free reign to do absurdly dangerous things like overloading operators. VS makes me want to kick puppies sometimes but I've definitely been curious about F# and what you said about it has me even more curious. I assume this is something more than just the C# thing where you can cast to a more inclusive type implicitly. Commented Aug 12, 2011 at 5:21
  • @erik, Oh yes more than implict typing and var: F# Type inference
    – jbtule
    Commented Aug 12, 2011 at 12:40

It's 2015 now, which adds some interesting snippets to the conversation:

  1. Significant parts of the enterprise backend world is considering or starting to use Python (dynamic) in lieu of Java (strict static)
  2. The enterprise frontend world is seeing things like AngularJS v2, based on TypeScipt: a typed extension of Javascript.

So the backend guys are tired of the unnecessary straight-jacket of strict typing, while the frontend guys are tired of the chaos of dynamic typing.

Quite ironic: I wonder if they'll meet in the middle, or rush past each other with the sonic boom of an deadline passing over...? ;)

  • Unless you provide any proof, I would claim that in the worst case backend world is transitioning to Go, but god forbid any dynamic scripty stuff. The myth that a static programming language always has a lot of ceremony has long been debunked with more powerful inference systems and solid REPL implementations
    – Den
    Commented Jul 10, 2015 at 8:10
  • There's plenty of dynamically typed back ends in use on large scales. Django in particular is very popular in journalism and is running the back ends for the NYT, the Guardian, and the Washington Post. Walmart's running on Node. The only myth is the idea that you can't write for scale without static types. And after having spent some time thinking about some Java legacy code base disasters I've run into, I think people who are comfortable doing so are better off for it whether they're working with static or dynamic. Commented Jul 17, 2015 at 14:24
  • Indeed, I'd rather have a skilled Python team on my large enterprise project, instead of a poor Java one.Just to clarify my position: I posted the above answer as an assessment of Commented Jul 20, 2015 at 6:39
  • Indeed, I'd rather have a skilled Python team on my large enterprise project, than a poor Java one. Just to clarify: I posted the above answer as an observation on the trends I'm seeing in my client-base, industry network and general research. Traditionally strict backend is embracing less strictness, traditionally looser frontend, more. It's not even an opinion on which is "right" (if any) - not sure why I got downvoted. Perhaps the irony is lost... Commented Jul 20, 2015 at 6:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.