It’s you
3 Likes
The reason I agree with this is that there is a growing popularity of online courses provided by universities. If academics adopt Julia then lecture videos and MOOCs will start appearing that use Julia instead of Python/Matlab and then Julia doesn’t become an extra task on top of what I want to learn. You don’t need to be an academic or studying at university to appreciate a decent online course on Julia programming, and you can’t find them on Udemy!
Unfortunately the stuff on JuliaAcademy is outdated and I’m not sure if the people with the knowledge have the time to update them to work with the latest API. A situation that will improve as the language becomes more stable I hope.
1 Like
well, it’s also me. I know the VSCode hints apparently work well for some people, but on mine they are very flaky
4 Likes
I got interested in Rust because it’s wasm implementation is way ahead of Julia’s. As a web developer I don’t think I’d ever adopted Julia as my main platform but being able to have scientific code running in the browser would be awesome.
I also got put off by long precompilation times and TTFP problems when I was experimenting with Julia and only had the odd spare 30 min to play around. It meant most of my time was hitting overheads. For the same reason, Pluto was a dead-end for me, it’s great, but I don’t want to have to start up a server when a ipynb runs directly in VSCode, and each Pluto notebook maintains it’s own environment so they always took ages to load. As a beginner there were just too many unnecessary details to fight with, with Rust I just typed out some code and cargo run (package management is very similar), that’s how it was done, so I didn’t need to worry about which notebook to use or whether to write scripts, or how to optimise code, I never accidentally defaulted to a global environment and then paid the price later. The Julia language is easier, but the on-boarding was much more difficult. I had such a bad experience starting with Julia I’m amazed I don’t hear more about it from others, perhaps it was partly using a old laptop that was quite slow?
Noobs just can’t be dealing with all that if you want more language adoption, make the basics easier.
9 Likes
Focus has been on TTFX and major work happened there leading to startup times that now feel very reasonable. I agree that we need some onboarding document and/or videos so people understand environments and projects and how workflow works.
2 Likes
That will definitely help.
Revise.jl and PackageCompiler.jl are not the types of things you would typically have to deal with separately to the language installation. Whether a language is interpreted or compiled, opening up a new command shell to run a program wouldn’t make any difference. It’s definitely a workflow issue that, at least to me, was non-obvious.
Because I use Julia as an education tool, I’m often hopping around different small sample projects, and it feels like I’m fighting the language all the time by doing this. I can see how it’d be easier if I were working on one main project.
4 Likes
I sort of do a fair amount of this too. And it doesn’t feel that difficult.
julia --project
or
julia
] activate .
Though in reality I just embraced vscode and the emacs keybindings extension, so I just open vscode in that directory. For an educational context I think jupyter notebooks in vscode work well.
But I could see how if you don’t have a workflow down yet, it would be very confusing to try to figure out how best to do stuff. So we definitely need onboarding workflow docs!
3 Likes
Yes! I also find vscode with the Awesome Emacs Keymap extension very productive. For a long time, the only functionality I seriously missed from Emacs was keyboard macros, but then I found Keyboard Macro Beta and keymap-wapper which together let me use standard Emacs key chords for keyboard macros 
.
2 Likes
Once you’ve figured that out, yeah it’s not too hard. My expectation from other languages is that behaviour would be the default and the global environment would only be used if no Project.toml was found locally.
Similarly, VSCode will set the environment to the current working directory, so if you’re opening up a common parent of your projects, again the global environment is used, not the project that the file being run is in.
Running Jupyter Notebooks in VSCode does seem to pick up the project though. Pluto manages its own environment.
When you’re desperately trying to avoid long precompilations, these little idiosyncrasies just seem to start adding up.
Maybe I am repeating what has already been said now. I just think there are some small usability improvements that could make for a big improvement for new users without trying to make Julia the next big web development platform or something like that.
2 Likes
This is typically what I observed around me with colleagues and students doing machine learning.
I get always the same answer each time I advice people to come to Julia, those implementing, or expecting to implement in the near future, deep learning (which actually represents most of ML people): “Pytorch is more complete”. [Note: I am not expert in DL and do not have the skill to compare Flux.jl and PyTorch, I only report what I ear]. As a result, and unfortunately for me, they prefer to stay on Python even if impressed by some demo of Julia (being not ready to learn an additional language, what I can understand)…
2 Likes
It probably doesn’t help, that the performance of Julia, particularly the initial compilation time, is magnitudes slower than Python.
Python is already known to be slow, and the factual experience of iterative code design, and experimenting with the language being subjectively slower – while simultaneously bragging about near C like performance – drives people away.
Why would people learn a new language, when one of its biggest promises appears to be a lie?
Particularly when the execution speed of Python largely depends on C libraries.
Casual AI programmers will find just find very little benefits in Julia.
1 Like
Is it possible that you are doing something in a very suboptimal way? You could probably open a separate thread, post your problem (like “I’m doing this and that and I have to wait 30 min / sec / ms before I can continue”), and get advise.
One’s experience with Julia depends on the workflow, and I recall very well my early frustrations.
3 Likes
Yes, unfortunately there is no contest in that department. Python has TF, PyTorch, and JAX, all of which have thriving ecosystems of associated packages. Each of those Python packages has corporate-backed teams of engineers working on them full-time. Teams are huge. Packages have been battle-tested on enormous models.
IMHO, this is a strategic area where Julia should not fall behind. Differentiable programming is not just for deep learning, it is fundamental for any modern implementation of classical inference methods, ranging from maximum likelihood to variational inference.
If Julia does not catch up in this area, Python, which I regard as an inferior language, will continue to attract most users.
4 Likes
Tell me how I do this in a very suboptimal way 
Intel 6200U
I understand, that this is not the fastest CPU in the world, but 6 seconds is nothing short of a scam, if you advertise your language based on speed.
1 Like
I can comfort you on that, as I am part of the F# community, and know the situation there.
Thanks to the .NET ecosystem, there is a package available for basically all the prominent frameworks, Tensorflow, Keras, Pandas, NumPy.
They even implement the API to existing libraries, so that it feels familiar to the Python guys.
F# did recently a pretty major refactor of the compiler, just so that Python devs can omit a single dot.
And they have pretty interesting frameworks themselves, like DiffSharp and ML.NET.
Nobody bats an eye.
So, you don’t need to be sad, that Julia lacks support for prominent AI libraries, as it would not make any difference in adoption. F# has the power of .NET in their back, and all the libraries are available from C# as well. Python devs simply see too little reason, to switch.
The language is “good enough”
And projects like Mojo will just cement that status.
1 Like
I’m not sure what you’re measuring there. This is what I get on Julia v1.8.2:
julia> @time add(x, y) = x + y
0.006697 seconds (7.86 k allocations: 454.296 KiB)
add (generic function with 1 method)
julia> @time add(1, 2)
0.000001 seconds
3
I’m on an old MacBook with a 2.3 GHz Intel Core i5 processor.
8 Likes
That’s vscode-jupyter
I did evaluate before with the little |> button in the top right, in normal VSCode mode.
That took comparatively long.
Just writing 20 lines of code and hitting that button, takes an eternity till the whole things is properly evaluated.
Edit: It seems like it is an issue with the VSCode extension.
Output of my terminal:
@time add(x, y) = x + y
0.011075 seconds (7.33 k allocations: 440.927 KiB, 1155.33% gc time)
add (generic function with 1 method)
Seems like hitting the button for the first time starts up a new Julia process – which takes some time (Similar complaints have been raised about Clojure which needs to start up a JVM). Ones the Julia process is running, it will be much faster, i.e., when hitting the button again afterwards.
8 Likes
running the cargo run first time requires time but nobody complains it but when Julia requires time for compilation, it matters. I think that’s why Julia doesn’t save the compiled file that’s ready to run each time. People are not used to this type of compilation work.
I wonder how much faster Julia is than C++ or Rust on Jupyter notebooks.
It may be more appropriate to promote Julia as an easier C++ than a faster Python. With projects targeting more and more hardware, Julia could become an alternative to C++ in heterogeneous computing. However, it is a pity that Julia is not among the priorities of the group that adapts software to RISC-V hardware.
https://wiki.riseproject.dev/display/HOME/Language+Runtimes+WG
6 Likes