Are you talking about static typing? If so, that sounds fundamentally incompatible with the basic worldview behind Julia — that you want to delay binding/dispatch till runtime, and leverage multiple dispatch, for high composability & code reuse.
I wonder how capable the ahead-of-time compiler would be, if you have not just the library, but can also provide the “inputs” in your “script” (that it can specialize on).
Playing advocatus deii for Julia, I guess you could write code, where all function signatures only contain concrete types. Then the ahead-of-time compiler would work the same as for a C++ program without templates and dynamic polymorphism through subtyping. That's a totally valid programming model, that noone uses.
Of course you don't have to go that far in practice and you still could have static types with less restrictions, as long as the types are inferable
Multiple dispatch is a kind of runtime type resolution. Static/compile-time function overloading based on types is a thing, but is fairly banal... common in C++, but mostly forbidden in Rust, but it doesn't resolve on vtables, so doesn't give you the same kind of polymorphism as what you'd get in Dylan/Julia/CLOS/Cecil, etc.
Myself, I was excited to work in a language with multiple dispatch at first, but once I spent some time working full-time in Julia the sheen wore off. It could be Julia's take on it, but I really don't like the kind of ... semantic overloading ... and duck typing that can happen all over the place.
I've worked quite extensively for Julia as my primary language for quite some time at this point. I've gone from being absolutely in love with the language to extremely disillusioned over the last couple of years.
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.
And it's extremely good for that! The SciML ecosystem is top of the class, I would never recommend someone solve a differential equation any other way. If you can build a system that is just a thin wrapper on top of SciML, absolutely go for it. I would recommend anyone wanting to build new systems from scratch to look elsewhere.
But, the tooling is subpar and overfit to the VS Code extension, and even there I found so many false positives with the linter that I just started ignoring all but the most basic of warnings. It's not entirely the fault of the developers, Julia is dynamically typed and there's only so much you can do. But if you have to type things rigidly enough that it's inferrable while developing that Cthulhu.jl or JET.jl can infer the types, why not just work with a static type system where you get that for free?
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. However, it has done absolutely nothing for my ability to write code that doesn't crash because someone passed in a type that doesn't obey the implicit interface I expect.
> 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
I think it would be great for Julia to have a mechanism to formalise/enforce interfaces.
I thought a bit about it lately and came to the conclusion, that something like C++ concepts (minus the clunky syntax) would be a better fit for Julia than Haskell's typeclasses or Rust traits. The main difference for me is, that typeclasses are a whitelist of allowed types, while concepts are a set of type constraints, that blacklist types, when the constraints are not fulfilled. Otherwise they are quite similar.
As a result, you don't have to explicitly create a instance with concepts like you would need to do for type classes and packages can happily interoperate without knowing of each other.
I think type classes and packages can happily interoperate without knowing of each other, just like abstract types and packages do currently...well I guess the concepts idea would make it so you'd need even less coordination. But yeah, would be nice if Julia had formal interfaces.
I wonder how capable the ahead-of-time compiler would be, if you have not just the library, but can also provide the “inputs” in your “script” (that it can specialize on).