# What don't you like about Julia for "serious work"?

**URL:** <https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591>\
**Category:** Community\
**Created:** [February 4, 2021, 5:49am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591 "2021-02-04T05:49:56Z")\
**Posts on this page:** 20\
**Page:** 9

<div class="post-metadata">

**Author:** ![Tarny\_GG\_Channie](https://avatars.discourse-cdn.com/v4/letter/t/3bc359/32.png) [@Tarny\_GG\_Channie](https://discourse.julialang.org/u/Tarny_GG_Channie)\
**Post date:** [December 4, 2023, 10:34pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/185 "2023-12-04T22:34:19Z")

</div>

Using Julia is like. touring a construction site. You can see a bunch of features being developed and not ready. Use python and it’s like a market.

Well, I want a simple pygame-like interface where I can control the update rate of my game? Not so fast. Not so simple. Not ready. Dig into SDL? Oh, good luck digging into the docs.

Flux has problems too when you don’t stick to the normal stuffs. It’s under construction!

I don’t really know how do I go further. It’s still in progress. Things aren’t ready.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [December 5, 2023, 12:27am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/186 "2023-12-05T00:27:59Z")

</div>

> [@stevengj](#):
>
> That “culture” led to ~~a PR~~ [two](https://github.com/JuliaLang/julia/pull/52252) [PRs](https://github.com/JuliaLang/julia/pull/52260) to improve the `randn` documentation within hours of the complaint being raised …

I think the preferred culture is one where our testing and interface frameworks can catch problems before someone complains rather than a culture where we react when someone complains.

> [@Tarny\_GG\_Channie](#):
>
> Well, I want a simple pygame-like interface where I can control the update rate of my game? Not so fast. Not so simple. Not ready. Dig into SDL? Oh, good luck digging into the docs.

GameZero.jl seems well documented with a multitude of videos on the topic.

> **[GitHub - aviks/GameZero.jl: Zero overhead game development library for the...](https://github.com/aviks/GameZero.jl)**
>
> Zero overhead game development library for the Julia programming language - GitHub - aviks/GameZero.jl: Zero overhead game development library for the Julia programming language

[![](https://global.discourse-cdn.com/julialang/original/3X/8/3/83c2e892321fbc06baf89498c97b84f3ced0eae1.jpeg "Game development in Julia with GameZero.jl | Workshop | JuliaCon 2021") ](https://www.youtube.com/watch?v=ar7wCVlncKE)

[![](https://global.discourse-cdn.com/julialang/original/3X/1/7/173d92c2db522d307f6cdc6d75b71144eb36a2e3.jpeg "[04x09] Intro to Game Development using GameZero | GameZero.jl, Julia & VS Code [Julia Desktop Apps]") ](https://www.youtube.com/watch?v=SSYV8gC2UkQ)

[GitHub - JuliaMultimedia/SimpleDirectMediaLayer.jl: SDL2](https://github.com/JuliaMultimedia/SimpleDirectMediaLayer.jl) seems to be a direct low-level binding of the underlying C liibrary. The C library has documentation here:

> **[SDL2/FrontPage](https://wiki.libsdl.org/SDL2/FrontPage)**
>
> The Simple Directmedia Layer Wiki

What is missing?

---

<div class="post-metadata">

**Author:** ![Tarny\_GG\_Channie](https://avatars.discourse-cdn.com/v4/letter/t/3bc359/32.png) [@Tarny\_GG\_Channie](https://discourse.julialang.org/u/Tarny_GG_Channie)\
**Post date:** [December 5, 2023, 1:41am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/187 "2023-12-05T01:41:35Z")

</div>

Gamezero has the user define the update function, but not the game loop itself, which is problematic in a sense that YOU CAN’T FIND OR CONTROL how long it takes between updates!

---

<div class="post-metadata">

**Author:** ![Aexetan](https://avatars.discourse-cdn.com/v4/letter/a/7feea3/32.png) [@Aexetan](https://discourse.julialang.org/u/Aexetan)\
**Post date:** [April 9, 2024, 7:06pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/188 "2024-04-09T19:06:42Z")

</div>

I really like Julia, but I use Fortran more. I don’t need dynamic typing for scientific calculations. For example, I always know in advance which types to use in calculations and almost always in advance the dimension of vectors and matrices.

Long first start compared to statically compiled languages.

Much higher memory usage compared to statically compiled languages.

These benchmarks are impressive [GitHub - JuliaArrays/StaticArrays.jl: Statically sized arrays for Julia](https://github.com/JuliaArrays/StaticArrays.jl)  
I would be happy if there was a completely “statically typed” version of Julia.

---

<div class="post-metadata">

**Author:** ![homocomputeris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/homocomputeris/32/8933_2.png) [@homocomputeris](https://discourse.julialang.org/u/homocomputeris)\
**Post date:** [April 9, 2024, 7:17pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/189 "2024-04-09T19:17:14Z")

</div>

Dependence on spaces: `[1a -2]`, `[1 a -2]`, `[1 a-2]` are all different things if you make a typo.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [April 9, 2024, 7:28pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/190 "2024-04-09T19:28:44Z")

</div>

> [@Aexetan](#):
>
> Long first start compared to statically compiled languages.

I would usually compare this to compilation time in statically compiled languages, but I suppose it depends what we are comparing.

> [@Aexetan](#):
>
> I would be happy if there was a completely “statically typed” version of Julia.

This seems unlikely to occur anytime soon. We can bind variables to types, but this seems to be the furtherest we will go anytime soon.

```julia
julia> function foo()
           x::Int = 5
           x = 6.0
           return x
       end
foo (generic function with 1 method)

julia> foo()
6

julia> foo() |> typeof
Int64

```

At some point, this becomes not Julia. I’m curious about what parts of Julia do you like?

Maybe try Chapel?

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [April 9, 2024, 8:45pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/191 "2024-04-09T20:45:05Z")

</div>

Compiling a static language program takes time too.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 10, 2024, 5:39am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/192 "2024-04-10T05:39:09Z")

</div>

The only issue that inconveniences me significantly is the inability to redefine `struct`s (eg with Revise.jl).

Yes, I am aware that solving this is a large undertaking and there is work in progress, and compared to how great Julia is, effectively I am complaining about the in-flight meal options on a space rocket that I got for free and it is getting faster day by day thanks to the efforts of others. But still.

> <https://github.com/timholy/Revise.jl/issues/18>
>
> Since \`struct\`s cannot be redefined, attempting to do so currently gives a \`fail…ure to evaluate changes\` warning.
> 
> I wonder if this can be worked around by triggering a reload of the entire module in this case.

---

<div class="post-metadata">

**Author:** ![sairus7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sairus7/32/10816_2.png) [@sairus7](https://discourse.julialang.org/u/sairus7)\
**Post date:** [April 19, 2024, 12:29am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/193 "2024-04-19T00:29:02Z")

</div>

> [@Tamas\_Papp](#):
>
> compared to how great Julia is, effectively I am complaining about the in-flight meal options on a space rocket that I got for free and it is getting faster day by day thanks to the efforts of others

You can have your meal on the rocket,  
If you carry it in your pocket. 🙂

To redefine structs I start my script files with include and explicit import, and then just re-run whole script each time I change the definition:

```julia
include("./src/MyPackage.jl")
import .MyPackage as my
my.Foo(1) # and so on

```

However, sometimes this works strange together with debugger and Revise.

---

<div class="post-metadata">

**Author:** ![liuyxpp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/liuyxpp/32/9870_2.png) [@liuyxpp](https://discourse.julialang.org/u/liuyxpp)\
**Post date:** [April 19, 2024, 12:40am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/194 "2024-04-19T00:40:14Z")

</div>

But the whole point is exactly how to avoid re-run the whole script when structs are redefined…

---

<div class="post-metadata">

**Author:** ![sairus7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sairus7/32/10816_2.png) [@sairus7](https://discourse.julialang.org/u/sairus7)\
**Post date:** [April 19, 2024, 1:40am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/195 "2024-04-19T01:40:28Z")

</div>

Sounds like a nonsense - you can decide to delete or rename a struct, but forget to clear or change some obsolete method calls that continued to work unnoticed in the current REPL, but not in a fresh one. You would expect errors as desired behaviour for obsolete code.

And maybe use reactive programming (like in Pluto) to resolve code depencency graph and get rid of persistent state.

---

<div class="post-metadata">

**Author:** ![zamk](https://avatars.discourse-cdn.com/v4/letter/z/ecd19e/32.png) [@zamk](https://discourse.julialang.org/u/zamk)\
**Post date:** [April 19, 2024, 5:59am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/196 "2024-04-19T05:59:27Z")

</div>

As mentioned above, compile times are so long which makes it almost impossible to use interactively. Let’s say you have a Pluto notebooks which uses two or three libraries including Plots library, compilation (or precompilation) takes a few minutes.

---

<div class="post-metadata">

**Author:** ![abraemer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/abraemer/32/51403_2.png) [@abraemer](https://discourse.julialang.org/u/abraemer)\
**Post date:** [April 19, 2024, 6:41am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/197 "2024-04-19T06:41:32Z")

</div>

There is are easy ways around that. This gives you three options:  
[https://plutojl.org/en/docs/packages-advanced/](https://plutojl.org/en/docs/packages-advanced/)  
Personally, when using Pluto for package development, I just make a folder `notebooks` next to `src` and put all my Pluto notebooks in there together with an environment that includes all dependencies and additionally `dev`s the package.

Then in the notebooks, the first cell simply is

```julia
begin
    import Pkg
    Pkg.activate(".")
    using ...
end

```

Usually I also use PlutoLinks.jl and make a cell with

```julia
@revise using ThePackageIWantToDevelop

```

so the notebook refreshes the next time I change something in the package.

Edit: Actually in recent Julia versions precompilation should be cached. So when you restart a notebook it should use the precompiled libraries even though it creates a new environment. Well, unless some package was updated in the meantime which is often the case for larger depency lists.

---

<div class="post-metadata">

**Author:** ![danielwe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/danielwe/32/35657_2.png) [@danielwe](https://discourse.julialang.org/u/danielwe)\
**Post date:** [April 19, 2024, 3:20pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/198 "2024-04-19T15:20:53Z")

</div>

> [@abraemer](#):
>
> in recent Julia versions precompilation should be cached. So when you restart a notebook it should use the precompiled libraries even though it creates a new environment.

When using Pluto’s default isolated environments, my experience is that precompilation always starts from scratch whenever I have run an unrelated Pkg operation (such as `]update` in the global env) since the last Pluto session, even if the Pkg operation did not trigger periodic depot cleanup. This is the number one pain point of Pluto for me. Wondering if it would be better if Pluto created a persistent environment for each notebook somewhere like `.cache/` or `.julia/plutoenvironments/` rather than using `mktempdir()`.

---

<div class="post-metadata">

**Author:** ![roflmaostc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/roflmaostc/32/30123_2.png) [@roflmaostc](https://discourse.julialang.org/u/roflmaostc)\
**Post date:** [April 19, 2024, 4:14pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/199 "2024-04-19T16:14:55Z")

</div>

More of a Pluto issue but I encounter similar things.  
Feels like sometimes unpredictably it would run precompilation.

Since the beginning of the semester I’m always distributing the same notebooks with exact the same dependencies but on some machines it would cause precompiling from scratch or only some packages.

Since those are not my computers I can’t debug thoroughly but from observations I could not make much clue.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [April 19, 2024, 6:06pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/200 "2024-04-19T18:06:47Z")

</div>

It’s just commonly observed in Pluto because it create more environments than others typically do. But the issue is definitely present in Julia generally, I encounter random re-precompilations in regular plain envs from time to time as well.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [April 19, 2024, 6:31pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/201 "2024-04-19T18:31:55Z")

</div>

The situation is even worst than I described here.

> [@Excess precompilations](https://discourse.julialang.org/t/excess-precompilations/113144):
>
> These 4 steps each one precompiles the code 1- using GMT from normal REPL 2- using GMT from VSC REPL (???) 3- ] test GMT 4- From pythoncall, jl.seval("using GMT") Looking at the .julia\compiled\v1.10\GMT there are now 4 precompiled caches. I know the difference between 1 and 3 (was explained in a previous topic), but why the others? More in particular, why VSC REPL needs to recompile? Directory of C:\Users\j\.julia\compiled\v1.10\GMT 04/18/2024 12:33 PM 63,159,296 EoU0j\_fJuKl.dll…

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [April 20, 2024, 10:45am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/202 "2024-04-20T10:45:11Z")

</div>

Are you using more than 10 different versions of the same package (or transitive dependency?) You could try setting the env variable `JULIA_MAX_NUM_PRECOMPILE_FILES` ([docs](https://docs.julialang.org/en/v1/manual/environment-variables/#env-max-num-precompile-files))

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [April 20, 2024, 11:39am UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/203 "2024-04-20T11:39:17Z")

</div>

> [@ericphanson](#):
>
> You could try setting the env variable `JULIA_MAX_NUM_PRECOMPILE_FILES` ([docs](https://docs.julialang.org/en/v1/manual/environment-variables/#env-max-num-precompile-files))

I’ll try and see, thanks! Maybe Pluto docs should recommend changing this variable? @fonsp

There are many different “unexpected re-precompilation” scenarios though. For example, sometimes I get this:

```julia
pkg> up
<...>
pkg> precompile
<precompiles some deps again>

```

or this:

```julia
pkg> precompile
<...>
julia> using SomePkgFromThisEnv
<precompiles some deps again>

```

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [April 20, 2024, 12:45pm UTC](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591/204 "2024-04-20T12:45:30Z")

</div>

Ideally I would like that `using` never triggered precompilation of anything (if the package is already installed).

A curiosity: without type piracy, is it possible for packages to create a circular set of invalidations?

[Previous page](https://discourse.julialang.org/t/what-dont-you-like-about-julia-for-serious-work/54591.md?page=8)