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 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.
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.
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.)
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.
I 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.
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.
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.
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.
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).
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?
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.
The implicit assumption is that one should participate in these arguments. This is assumption is false.
You can just as easily
ignore all the trends,
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,
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.