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

Community
185

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.

2 Likes
186

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.

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

GitHub - JuliaMultimedia/SimpleDirectMediaLayer.jl: SDL2 seems to be a direct low-level binding of the underlying C liibrary. The C library has documentation here:

What is missing?

7 Likes
187

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!

188

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
I would be happy if there was a completely “statically typed” version of Julia.

5 Likes
189

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

1 Like
190

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

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> 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?

1 Like
191

Compiling a static language program takes time too.

2 Likes
192

The only issue that inconveniences me significantly is the inability to redefine structs (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.

33 Likes
193

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

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:

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

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

1 Like
194

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

1 Like
195

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.

1 Like
196

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.

197

There is are easy ways around that. This gives you three options:
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 devs the package.

Then in the notebooks, the first cell simply is

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

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

@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.

3 Likes
198

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().

199

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.

1 Like
200

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.

1 Like
201

The situation is even worst than I described here.

1 Like
202

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)

203

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:

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

or this:

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

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?