Hacker News Reader

> I have also found the obsession with reducing time to first plot incredibly aggravating. It is finally down to a pretty good level, which is a nice quality of life improvement

For the target users of Julia, which are academics that are currently using Matlab or Python, time to first plot is one of the primary reasons that they are not willing to switch to Julia. Especially if their current workflow is writing a script then pressing run button in Matlab or calling python my_script.py, then they do julia my_script.jl and they expect it to work the same way as Python or Matlab do. This is why in all the user & developer survey TTFP is consistently ranked highest.

As a research software engineer, I've seen PhDs and postdocs that are downright scared of programming and any kind of low level technical work in general, even if their problem domain requires high performance languages. They just want their project or thesis to finish within their probably unrealistic deadlines. You throw them to a language with strict type checking or traits and interfaces and they will just give up. Unfortunately if the language users are filled with these kind of user then it results to this kind of problems, which you did mentioned in your second paragraph.

> It is incredibly hard to reason about this language if every developer is not willing to commit to understanding and writing Julia code the right way (e.g. type stable, dispatch via the type system, actually defining interfaces). Given the target demographic of academics, the proportion of people interested in grokking Julia is vastly smaller than the number of academics who hear "walks like Python runs like C" and decide this is their new, free, hip MATLAB/SciPy replacement.

Thinking about it, to solve this Julia problem we need to solve academics scared of programming problem. I don't have a solution to this either, I've been trying to think about it after seeing several people keep asking me for help in programming

I was working in a non-numerics/non-scientific code base and the quality of the code was good to very good. And I could see the value Julia was bringing to the table on some aspects of the higher levels of their stack. But it utterly fails at being any kind of "systems language", and it was being coraled into that role in spots. Tossing some optional somewhat-static (but not really) type declarations and a JIT into the language doesn't make it a performant language for areas where something like C++, Rust, etc. would be more suited.

And yes, like any late-bound language, it's going to be prone to crashing at runtime in unexpected ways. Julia has some okayish tools for doing some static analysis, but it's never going to be at the level of what you can get out of an actual modern static type system. I was fortunate to work with some very smart people who had written some very high quality code in Julia, and some aspects of the language I found very nice and expressive (and even sometimes miss), but I was happy to go back to writing Rust after I switched jobs.

And yeah, not being a VSCode user (JetBrains addict), I found tooling lacking as well. The emacs mode was okayish. Also found I kept having to use the Repl in ways I found non-intuitive.

I would reach for Julia as an alternative to Python, maybe, for certain types of things. It's certainly prettier to look at.

Using Julia as non-numerics/non-scientific systems language is not a good fit. So, not surprising you are not finding it as useful as Rust. JIT performance notwithstanding. As for Python, it is getting defaulted to any and every programming niche with predictably bad results.

The problem is that the language is in part pitched this way, as a "best of both worlds" language where you can get "C-like" performance while still living in a dynamic world, at least in part. But it's not true.

It's certainly faster than Python, and a more elegant language. So I'd be in a much happier world if people were using it for some of the places where they're using Python. But its slow startup time makes it unsuitable for many scripting type tasks. And its module system and deployment thereof is... complicated.

I have not yet fallen out of love with the language, but I can absolutely sympathize with the desire for better ways to define and enforce interfaces. In my opinion it is the #2 issue for me right behind having a non-kludgy import/module system