Julia 1.10 (opens in new tab)

There is simply too many rough edges and usability problems as it is now, and at the current pace it will take maybe 10 or 15 years to address them.

On the other hand, the major use case for Julia is to have a fast, dynamic language. And it seems to me the time horizon for Python to become fast, or Rust or C++ to become dynamic is indefinite, so Julia is still the best bet in that space.

https://juliahub.com/case-studies/

And don't get me started on how nice JuMP.jl is for mathematical optimization.

All my data are in a database, Julia need to become more db oriented , that is it

It takes some time to precompile packages, but once that's done I'm seeing the first plot pop up in fractions of a second.

Compliments to the Julia team! I'm looking forward to trying out this new version.

Looking forward to update my Julia installation.

    using Plots
    plot(sin)

https://github.com/FluxML/Flux.jl

On top of that there are many higher level libraries such as Transformers.jl

https://github.com/chengchingwen/Transformers.jl

There is https://github.com/rejuvyesh/PyCallChainRules.jl which makes this possible. But using some of the native Julia ML libraries that others have mentioned is preferable.

No. And it doesn't seem like that will become possible any time soon.

This is a bit vague, any concrete example?

  julia> using StaticTools, StaticCompiler
  
  julia> hello_world() = printf(c"Hello World\n")
  hello_world (generic function with 1 method)
  
  julia> compile_executable(hello_world, (), "./")
  "~/hello_world"
  
  shell> ./hello_world
  Hello World
  
  shell> du -h hello_world
  16K hello_world

For discovering methods you can do

  julia> ?("hello", 1, 2.0)[TAB]
  broadcast(f, x::Number...) @ Base.Broadcast broadcast.jl:844
  readuntil(filename::AbstractString, args...; kw...) @ Base io.jl:520
  ...

I think for the most part this is solved. It works very well and has good integration with VS Code:

    julia> integrator.<tab>
    EEst                    accept_step             alg                     cache                   
    callback_cache          differential_vars       do_error_check          dt                      dtacc ...

    julia> ODEProblem(<tab>
    ODEProblem(f::SciMLBase.AbstractODEFunction, u0, tspan, args...; kwargs...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:183
    ODEProblem(sys::ModelingToolkit.AbstractODESystem, args...; kwargs...) @ ModelingToolkit C:\Users\accou\.julia\packages\ModelingToolkit\arrCl\src\systems\diffeqs\abstractodesystem.jl:911
    ODEProblem(f, u0, tspan; ...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:187
    ODEProblem(f, u0, tspan, p; kwargs...) @ SciMLBase C:\Users\accou\.julia\dev\SciMLBase\src\problems\ode_problems.jl:187

Not quite. There's a bunch of knobs you can use to get small binaries (I use this for industrial deployments often), but Jeff Bezanson gave a really nice talk at JuliaCon Local Eindhoven 2023 that described the reasons for the large binaries, what the memory is actually attributed to, and what to do about it (https://youtu.be/kNslvU3WD4M?si=hwo9AgXthNpiQ3-P). With the "normal options" you get to about 15MB now, still bad but not half as bad. The vast majority of that is the base system image. Jeff's talk then goes into the next steps with reducing the size of that base system image.

Not a fan of Python at all but now I just stick with that for my quant analysis. Tons of issues with Python too but atleast they are all known / well documented problems (also chatgpt knows pandas / matplotlib / python very well).