When it gets out of its data-science pedigree and can be used for standard apps. When it gets good tooling. When its stack-traces stop being arcane gobbledygook. When it can be compiled to a single binary at the command line without going through arcane hoops. When it gets interfaces/protocols/traits.
At the moment, Julia is a nice language at v1alpha1 for scripts and data exploration.
I agree it lacks all of these things, but in scientific computing - at the current state - it is already ahead of fortran, python, and C++ in terms of convenience. Precompilation doesn't matter as much here, and the packaging and JIT compilation as well as relatively simple FFI are making one's life a lot easier.
And NB, python also doesn't offer many of these features, such as dependency management and simple single-binary builds. Yet it's popular.
"And NB, python also doesn't offer many of these features, such as dependency management and simple single-binary builds"
Python has tools for both of these - including virtualenv in standard Python. Nuitka if you want native compilation to a single binary. Julia has none.
I did mention simple single-binary builds using the CLI. (ie - it just works with one command). Not fiddling around for hours with PackageCompiler.jl. Fiddling around with snoopfiles, then forced to ask questions on the forums to do what other languages do out of the box is not the way to go for developer ergonomics.
Uhh, you don't have to do anything with snoop files, and it's just a one line CLI call.
julia -e 'using PackageCompiler; create_sysimage(["MyPackage"], sysimage_path="MyPackage.so"; precompile_execution_file = "MyScriptOfWhatToCompile.jl")'
and now you have a binary. How are people "forced to ask questions on the fourms" if the only thing to do is to change file location names? Are you talking about PackageCompiler from 2019 or PackageCompiler from 2023?
At the moment, Julia is a nice language at v1alpha1 for scripts and data exploration.