Can we bring dynamically typed languages back into trend?

Julia is known for being a fast dynamic language. However, static typing is now the trend. Performance is not even the major reason for static typing anymore.

Meanwhile, I believe in the goodness of generic code and freedom enabled by full dynamic typing and generic design pattern, Maybe some of us share the same view.
Proponents of static typing say it reduces cognitive load, serve as documentation, provides safety, and require less tests which means less code for error.
Meanwhile, what arguments do we have for the dynamic typing? My best argument was that dynamic typing is good for generic code, which is good for multiple things.
Can we bring dynamic typing back?

I’m a little confused by this statement given that Python and JavaScript are both some of the most enormously popular languages, in the history of languages, maybe ever

5 Likes

These languages benefit from their legacy, but rarely does a new dynamically typed language comes up. JavaScript was, IIRC, a language developed hastily, but it was the only option so it stuck. It’s not just dynamically typed languages, languages like Java and C++ which aren’t good statically typed languages we should be competing with also benefit from its legacy. However, as a new language, we should be compared to modern statically typed languages like GO, Rust, etc…

3 Likes

We can just join the static trend if we can enforce a static hints enabled workflow with Cthulhu integration? · Issue #1915 · julia-vscode/julia-vscode · GitHub better implemented.

I feel that a majority of the more heated debates in this community forum stem from the assumptions in this statement; in my view, a fundamental point about the open-source ecosystem (including programming languages) is that there is no competition to be won, but instead to give good reasons for adoption.

29 Likes

JS is rapidly being replaced by TS, and god knows how much work has been poured into the dozen optional static type checkers for Python at this point (even if we ignore how Google is funding Mojo as a statically-typed Python replacement).

Feels very weird to me that inferred static typing was developed in the 1980s but was basically a Haskell thing until a few years ago, when everyone simultaneously decided it was the “correct” thing to do.

I would call them more type “lightly recommenders”

if python-style incremental typing actually enforced the types I bet usage would fall enormously

1 Like

Yes, because then they would no longer be incremental. Every major company is basically working on slowly migrating all their dynamic code over to using static typing, but doing that all at once would be hard and breaking. (Often, this is done by requiring every new PR to have inferrable types, or at least most of them.)

you must have quite the deep resume to make such a strong & broad statement

3 Likes

I recommend watching the talk Why static typing came back. The thesis of the talk is that static typing made a comeback because most of its perceived drawbacks have been addressed by newer languages. For example:

  • Verbosity → type inference
  • bad for heterogeneous data → generics, typeclasses
  • slow iteration → incremental compilers and LSP

At the end of the talk Feldman concludes that dynamic languages will not return to the mainstream (ever) because of insurmountable challenges regarding performance and static analysis. I agree with this conclusion, with some caveats.

First, dynamic languages are not inherently slower (otherwise this whole Julia thing wouldn’t make sense).

Second, there are problems that are not amenable to static analysis, namely, meta-programming problems: multistaged programming, computer algebra, AD, etc. So the idea that static languages are enough to model any problem might make sense for web developers (i.e. most developers including the intended audience for Feldman’s language), but it’s not true in general.

Dynamic languages will fade from the mainstream, not because they’re worse, but because their benefits (over the statically typed) are only manifest in domains that require metaprogrammability, which are rather niche.

9 Likes

I :heart: static languages, and hope Julia moves in the direction to better support static checking, including a mode to drop support for dynamism.

C++ (e.g. the STL, which decouples algorithms from containers better than Julia) is a great example of generic code in a static language.
Julia wouldn’t have to give up much genericness in giving up is dynamism. It would, however, have to give up the parts I don’t like and that make me pull my hair out.

7 Likes

I don’t think that’s true even there–most metaprogramming is done at compile-time and consists of simple AST rewriting.

1 Like

One thing about Julia type inference is that it’s a heuristic based type inference, designed for optimization for dynamically typed languages, instead of rule-based type inference, where the behaviors are more predictable. Also, Julia objects need not be type-inferred to have a correct behavior. Also, Julia design is that you actually do not need type stability everywhere, only in compute-intensive functions calls.

Dynamic languages are great for interactive and exploratory analysis, where you basically invent your algorithms on the fly while probing your data and figuring out what you want to do.

Basically what I and most people I know are doing.

I do not recognize any trend towards static languages, though I am sure it’s true in some domains. Among everyone I know, the trend is massively towards Python, not any static language.

9 Likes

This used to be true, but doing this with static typing is no longer especially difficult, because of how much type inference algorithms have advanced. To some extent, these algorithms are the reason Julia is even possible; Julia can infer types well enough to be “mostly static.”

Python is big, but AFAICT it’s not growing very fast anymore (see the StackOverflow surveys). TBF this probably doesn’t have to do with static typing (already provided by MyPy et al.); it’s just hard for a language to grow when the whole target audience is already using it.

The fastest-growing languages I can think of off the top of my head are Dart (just switched in 2.0), Zig, Rust, Kotlin, Crystal, and TypeScript, all of which have static types. Two of these, Crystal and TypeScript, are static dialects of an existing dynamic language, basically just “Ruby/JavaScript with types.” That gives us a clean comparison without many confounders; despite starting at a huge disadvantage, both TS and Crystal are just as popular as the originals, if not more.

This is true even though both are scripting languages designed for fast iteration and easy coding. As long as static type checking is optional and/or inferred, it doesn’t seem to have much of a negative impact on development time, but it can still substantially improve code quality.

1 Like

If that’s the case then we have JET.jl too.

It’s there and it kind of helps, but it’s also not as usable as MyPy or even built-in type checking in a static language (where the compiler will tell you where it failed to infer the type for a variable).

1 Like

The difficulty of writing code is only a part of the issue, how easy is it to run code? What is the workflow, the REPL experience in those languages?

I’m pretty sure noone I work with has ever heard of any of those languages, except Rust, and only because I am talking about it. The only languages of note are Matlab, Python, C++, Fortran and Javascript.

1 Like

From this observation alone you cannot tell that there is a trend towards static languages. You’d need to know where these people came from. If they mostly migrated from Java (or some other old, unergonomic statically typed langauge) then it is more of a sign that statically typed language are improving usability.

In my head good type inference brings statically and dynamically typed language very close together. The only remaining question is then: Is inferrability of the whole program mandatory or optional? And I personally will always opt for optional aka dynamical languages because it makes solving a problem the first time much much faster. After I solved a problem once, I can use that knowledge to come back and also make it type stable/inferrable/fast and what not. This option is just missing for statically typed languages.
What remains is the need for good tooling around types/inferrability on the dynamic language side and Julia can definitely improve here and already has tremendously. One thing I loved in Common Lisp where the “Compiler Notes” where you could get the compiler to tell you what it didn’t understand/couldn’t infer and what type annotations you could give it (latter part will be almost impossible in Julia I think, CL’s type system is much much simpler). So just having a global switch and macros for local use to warn you when something isn’t quite right would be great. Optionally, you could treat the warning as error and then you essentially have a statically typed language.

4 Likes

The implicit assumption is that one should participate in these arguments. This is assumption is false.

You can just as easily

  1. ignore all the trends,
  2. not participate in abstract static vs dynamic typing arguments, since they are meaningless without talking about concrete languages & related tooling, and have been meaningless for decades now,
  3. get work done in whatever language you like.

Topics like this are just adding to the noise and are disservice to the Julia community.

A good rule of thumb for most programmers who care about the quality of their work is to keep an eye what Microsoft is doing, and either ignore it or do the opposite.

Some things become a “trend” for sound technical reasons, but most trends are generated by astronomical quantities of money being poured into some technology. The joy of using free software includes the option to ignore this.

It was never taken away. We still have it. :sunglasses:

17 Likes