One of my advisors is considering transitioning towards Julia from a traditional HPC background using C++ and Python. After a couple days playing around, he seems quite impressed by the flexibility of Julia’s type system. But, he hasn’t done any “serious numerical work” (his words), and he is wonder…

Regarding 1.: This is much less an issue in the most recent Julia versions (1.5 and 1.6). Plotting from scratch (new Julia session) takes ~7s for me in 1.6 beta - not really problematic in my opinion. In addition I suggest to use Revise.jl in your development workflow for automatic reloading. Reg…

The downside to depending on Python libraries is the uneven state of Python dependency management, which is only made uglier by PyCall. There are some ideas on how to fix this ( Vendoring Python Wheels as Artifacts · Issue #1439 · JuliaLang/Pkg.jl · GitHub ), but nothing solid yet.

Right - you could work around this by defining a “normal” conda environment (with fixed environment.yaml file) and start your Julia session in a terminal where it is activated. But this is not very convenient.

Regarding point 1 you can try using DaemonMode.jl Is basically runs a julia server, which listens on http to run code. I use it in a scenario were I have to start many julia scripts just for plotting. Connecting it to the julia daemon saves quite some time.

I have never shied away from using terminals on my life, and even so, I was won over by Jupyter. Anything that is a little takes more than a couple of lines (i.e., anything that is not just testing manually a function that I am changing in my own package and Revise.jl is keeping the REPL up to date …

I think the main issue I have is encountering bug, redesigns, or performance problems with libraries. Julia’s package ecosystem seems pretty nice at first but when you start to use things in a “more serious” manner you often stubble on some issues, and many packages are under-staffed (if at all) so …

[image] jonathanBieler: bug, redesigns, or performance problems with libraries This is very true. Specially if make more advanced use than most of the package users. I love JuMP, but the solver wrapper packages made some questionable (in my option) designs that impacted performance in less us…

I think I can honestly say that there isn’t a single thing that I have encountered that I would consider a barrier to “serious work”. Sure, certain things seem slow to pre-compile or run for the first time, but to me, waiting a few seconds for one plot to show up one time is a non-issue. I can see h…

I miss the possibility of using the @code_warntype macro in other scope than the global one. The only moment I felt that something was taking more time with Julia than with Fortran was once I had a type instability that was hard to trace, and I had to run the pieces of code one by one until I reache…

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

Community

Oscar_Smith February 4, 2021, 6:02am 2

My biggest problem using Julia for serious work is that the company i work for only used c#

Interoperability with .NET

Topic		Replies	Views
I find it hard to develop in Julia Internals & Design	72	4638	February 14, 2026
Reflections on Developer Experience After Building a Large Julia Codebase General Usage	33	2788	January 11, 2026
Ensure Julia is used to its full power New to Julia question , first-steps	100	7410	December 11, 2020
Julia motivation: why weren't Numpy, Scipy, Numba, good enough? Community history	123	84271	September 21, 2018
Reluctance to switch to Julia; PyPy and Cython General Usage	35	11897	December 10, 2019

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

Related topics