# Can we bring dynamically typed languages back into trend?

**URL:** <https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333>\
**Category:** Community\
**Created:** [October 24, 2023, 3:11am UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333 "2023-10-24T03:11:24Z")\
**Posts on this page:** 15\
**Page:** 4

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [November 5, 2023, 10:26pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/62 "2023-11-05T22:26:48Z")

</div>

> [@Mason](#):
>
> The idea is mostly for library authors, and would not (and could not) be a globally applicable thing. It would be for marking certain functions, or calling contexts where everything must be static.

It certainly sounds good, but I don’t know (does anyone know?) if it’s possible\[1\] to per-library or module/context enforcing static type given that:

- The Library can have callbacks
- We still have world splitting so libraries can suddenly lose some property due to code loaded after it
- Type piracy is legal as far as the language is concerned
- The library may call other code that lost property due to one of the above.

I’m just inspired by your reply and discussion we had a few days back, thinking out loud, not expecting we know until we give it an honest try.

* * *

1. without breaking the language

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [November 5, 2023, 11:12pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/63 "2023-11-05T23:12:49Z")

</div>

> [@jling](#):
>
> - The Library can have callbacks
> - We still have world splitting so libraries can suddenly lose some property due to code loaded after it
> - Type piracy is legal as far as the language is concerned
> - The library may call other code that lost property due to one of the above.

I think to many people who want some sort of static function annotation system, these points you raise aren’t points _against_ having such a system, but instead seen as _positive_ reasons why they want to be able to say “no, this function should fail to compile if type inference fails”.

---

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [November 6, 2023, 3:48am UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/64 "2023-11-06T03:48:46Z")

</div>

> [@algunion](#):
>
> - Compiles to Python

At last, a way to combine the performance of Python with the flexibility of Haskell

(No offense meant, it sounds great, I just find the idea of compiling to Python funny 😁)

---

<div class="post-metadata">

**Author:** ![algunion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/algunion/32/51630_2.png) [@algunion](https://discourse.julialang.org/u/algunion)\
**Post date:** [November 6, 2023, 8:16am UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/65 "2023-11-06T08:16:43Z")

</div>

> [@ParadaCarleton](#):
>
> performance of Python

> [@ParadaCarleton](#):
>
> I just find the idea of compiling to Python funny

It has nothing to do with performance. Compiling to Rust is about that. Compiling to Python is about accessing a very rich package ecosystem in the area of ML/DL…

The value of Python no longer derives from the language itself (for a very long time now).

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [November 6, 2023, 8:34am UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/66 "2023-11-06T08:34:40Z")

</div>

for sure but these are practical barriers because IF we have such a system and the pkg inference properly for developer, but doesn’t for user, now you have un-testable errors that only stops user code?

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [November 6, 2023, 10:56pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/67 "2023-11-06T22:56:35Z")

</div>

That’s a different notion of effect system. Here, the compiler tracks certain properties of functions to enable certain optimizations. While this has some relation to typing functions with their effects, [algebraic effects](https://www.sciencedirect.com/science/article/pii/S1571066115000705) in addition provide a user-facing API to inject side-effects into functional code – as an alternative to monads. In particular, some effects require resumable one-shot (cooperative concurrency) or full continuations (non-deterministic choice). (Delimited) Continuations are currently not supported by the Julia runtime and thus algebraic effects would be difficult to implement in full generality.

---

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [November 7, 2023, 4:16pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/68 "2023-11-07T16:16:31Z")

</div>

> [@algunion](#):
>
> The value of Python no longer derives from the language itself (for a very long time now).

Oh, I totally get that, I’m just so used to compilers targeting C, MLIR, or LLVM that it seemed unusual.

Although, how does compiling to Python improve compatibility compared to a Python FFI? The main thing I’d want to do that I can’t do with a simple FFI is use and extend Python classes, and I don’t know if that would be helped by Python compilation. Unless you’re just talking about IronPython, but then doesn’t that exclude using most Python libraries?

---

<div class="post-metadata">

**Author:** ![gdalle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gdalle/32/27854_2.png) [@gdalle](https://discourse.julialang.org/u/gdalle)\
**Post date:** [November 7, 2023, 6:43pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/69 "2023-11-07T18:43:04Z")

</div>

> [@rdavis120](#):
>
> the workflow could be similar to the rust analyzer workflow where it helps you to see in real-time the inferred types

To come back to this, a rather recent Cthulhu version enables precisely that.

> <https://github.com/JuliaDebug/Cthulhu.jl/pull/469>
>
> Depends on https://github.com/julia-vscode/julia-vscode/pull/3328 for showing ty…pes inline, however can be merged in before.
> 
> This pr show types in the source code when using the repl in VSCode, e.g. \`@descend f(1)\` with warnings on gives
> !\[image\](https://github.com/JuliaDebug/Cthulhu.jl/assets/19725290/77fd3e0a-7554-46ab-98d1-2ec3593b3e9e)
> And without warnings 
> !\[image\](https://github.com/JuliaDebug/Cthulhu.jl/assets/19725290/dd12a9a5-6dc1-4cf1-8ccb-0638a96db7fa)
> 
> There a couple improvements I still want to make to this pr: 
> 
> \- \[x\] Adding a way to toggle the vscode integration (should this be implemented the same way the warn toggle works?)
> \- \[x\] Removing the duplication of tests in TypedSyntax (I tried putting the tests into a separate file and using \`include\` but then the \`m = @which TSN.unnamedargs(Matrix{Float32}, Int; a="hello")\` test started failing claiming \`mi\` was \`nothing\`) 
> \- \[x\] Adding a way to automatically show types in VSCode for any called functions in an open file without having to descend into them.
> 
> As an example of how to change the colour of the hints in VSCode, I'm using the Monokai theme with the following in my \`settings.json\`
> \`\`\`json
> "workbench.colorCustomizations": {
> // Name of the theme you are currently using
> "\[Monokai\]": {
> // Overrides for specific kinds of inlay hints
> "editorInlayHint.typeForeground": "#66D9EF",
> "editorInlayHint.typeBackground": "#00000000",
> "editorInlayHint.parameterForeground": "#f8f8f2", // defaults from https://github.com/microsoft/vscode/blob/2e335d2df2001439b09483e7fcff8379ac1a7a16/extensions/theme-monokai/themes/monokai-color-theme.json#L41-L42
> "editorInlayHint.parameterBackground": "#75715E",
> // Colours for unstable types when warnings are on
> "editorInlayHint.foreground": "#e13030",
> "editorInlayHint.background": "#00000000",
> }
> }
> \`\`\`

---

<div class="post-metadata">

**Author:** ![algunion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/algunion/32/51630_2.png) [@algunion](https://discourse.julialang.org/u/algunion)\
**Post date:** [November 7, 2023, 9:04pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/70 "2023-11-07T21:04:56Z")

</div>

> [@ParadaCarleton](#):
>
> Oh, I totally get that, I’m just so used to compilers targeting C, MLIR, or LLVM that it seemed unusual.
> 
> Although, how does compiling to Python improve compatibility compared to a Python FFI? The main thing I’d want to do that I can’t do with a simple FFI is use and extend Python classes, and I don’t know if that would be helped by Python compilation. Unless you’re just talking about IronPython, but then doesn’t that exclude using most Python libraries?

There are lots of other good stuff that comes from this - namely, the F# bindings (e.g. type safety) to lots of Python libraries. Also, it uses _typeshed_ in the back.

The main goal of translating F# to Python has nothing to do with performance: it is just a nice way to leverage the F# features and type safety in the Python ecosystem.

Maybe some other people might no need additional reasons than it is fun and can be done 🙂

---

<div class="post-metadata">

**Author:** ![rdavis120](https://avatars.discourse-cdn.com/v4/letter/r/b5a626/32.png) [@rdavis120](https://discourse.julialang.org/u/rdavis120)\
**Post date:** [November 10, 2023, 1:54pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/71 "2023-11-10T13:54:00Z")

</div>

> [@gdalle](#):
>
> [https://github.com/JuliaDebug/Cthulhu.jl/pull/469](https://github.com/JuliaDebug/Cthulhu.jl/pull/469)

Thanks! This is a really useful new feature.

---

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [November 11, 2023, 2:40am UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/72 "2023-11-11T02:40:14Z")

</div>

> [@ParadaCarleton](#):
>
> I think this is a good opportunity to explain–lots of people are confused about the difference between explicit typing (huge pain, the C approach) and static typing.

[Wanted to offer a better explainer of this, which I found here.](https://erik-engheim.medium.com/dynamically-typed-languages-are-not-what-you-think-ac8d1392b803) Lots of languages like Haskell offer static typing with fewer annotations than you’ll find in Julia code (because Haskell’s design generally makes it easier to infer types than Julia’s).

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [November 11, 2023, 9:50am UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/73 "2023-11-11T09:50:05Z")

</div>

There is another (often overlooked?) difference between dynamic and static types:

- Dynamic typing means that run-time _values_ have types

- Static typing assigns types to _syntactic expressions_, e.g., variables, but not their values.

In many statically typed languages, no type information is available at runtime. Thus, when dynamic dispatch is needed it has to be opted-in explicitly in order to keep some runtime information around, e.g., Rust’s trait types `Box<dyn SomeTrait>` keeping around the vtable to dispatch to the corresponding trait implementation at runtime.  
Besides giving the compiler important information in order to generate more efficient code, tracking the types of syntactic expressions enables dispatch (static that is) on return type:

```haskell
ghci> :t pure
pure :: Applicative f => a -> f a
ghci> (2*) . pure 3 $ 4 -- uses pure from Applicative instance for functions
6
ghci> [1, 2] ++ pure 3 -- uses pure from Applicative instance for lists
[1,2,3]

```

In contrast, in Julia you can always query the runtime type of any value using `typeof` and furthermore, this will always return a concrete types (as abstract types don’t have values, i.e., cannot be instantiated):

```julia
julia> v = Vector{Any}() -- concrete vector that can hold values of any type
Any[]

julia> push!(v, 1.0); push!(v, 2) -- add some values
2-element Vector{Real}:
 1.0
 2

julia> eltype(v) -- vector claims to hold abstract types
Any

julia> typeof.(v) -- yet, each value has a concrete type!
2-element Vector{DataType}:
 Float64
 Int64

```

Modern languages often blur the lines, e.g., as Julia when using static type information to de-virtualize dynamic dispatch\[1\], or static languages when keeping around runtime type-information. Imho, the basic distinction wether types exist at runtime (dynamic) or purely at compile time (static) is still valid and helpful.  
In this respect, Julia is definitely a dynamically typed languages (with clever optimizations base on partial static type information).

* * *

1. Interestingly, basically the same idea of compiling different versions of generic functions is called monomorphization in static languages

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [November 11, 2023, 6:28pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/74 "2023-11-11T18:28:09Z")

</div>

“Dynamic vs static typing” is often framed like they’re mutually exclusive properties, but when we say

- dynamic typing means values have types
- static typing means expressions have types

it seems they’re just two different language features, both of which could be present in a single language.

---

<div class="post-metadata">

**Author:** ![ParadaCarleton](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paradacarleton/32/20005_2.png) [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)\
**Post date:** [November 11, 2023, 7:41pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/75 "2023-11-11T19:41:01Z")

</div>

> [@jar1](#):
>
> it seems they’re just two different language features, both of which could be present in a single language.

Definitely. To some extent Julia does this; if it can figure out a way to assign a type to each expression, it will. This is more obvious in some other languages (like TypeScript or type-checked Python) that allow both.

---

<div class="post-metadata">

**Author:** ![bertschi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bertschi/32/33462_2.png) [@bertschi](https://discourse.julialang.org/u/bertschi)\
**Post date:** [November 12, 2023, 10:03pm UTC](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333/76 "2023-11-12T22:03:05Z")

</div>

> [@jar1](#):
>
> “Dynamic vs static typing” is often framed like they’re mutually exclusive properties, but when we say
> 
> - dynamic typing means values have types
> - static typing means expressions have types
> 
> it seems they’re just two different language features, both of which could be present in a single language.

Well, they are not mutually exclusive, but the defaults are very different, i.e., what to do if the compiler fails to assign unambiguous types to all expressions:

- Static: Reject the program, e.g., giving some typing error
- Dynamic: Let it run anyways and see what will happen at runtime

Also, the type-inference of the Julia compiler is comparably simple as it mainly needs to work out the types starting from some specific call, i.e., with specific concrete types as input, and can just give up, i.e., infer `Any`, if in doubt. In contrast, for a statically typed language it would be rather annoying to reject all but the simplest programs and accordingly type systems have become considerably more complex, handling parametric types, trait bounds, higher-kinded types and what not.

[Previous page](https://discourse.julialang.org/t/can-we-bring-dynamically-typed-languages-back-into-trend/105333.md?page=3)