And yes, that destination does include production.
Julia is hard to debug as is (and this is fully acceptable to me due to the architecture) and these hacks on hacks make it just impossible.
Julia suffers from the same "fancy calculator" approach than e.g. R and Matlab, and like those, they refuse to take note of the decades of experience in software development that this just leads to a total mess if you have anything more complicated than a one-off analysis. It's like insisting on editing files with ed because that's how it's always been done.
I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where you'll find the best success in both tooling and code structure for sustainable (and modern) development. We need to do a better job of helping folks more effectively develop and work with Julia before it becomes frustrating.
My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow session".
Perhaps there is some disconnect in how different parties of the discussion see the whole thing. For me this sounds a lot like "you're holding it wrong". What background are you coming from and what languages/programming environments you are familiar with? I get the impression that you don't have much general purpose programming background and somehow tend to assume that people are using "wrong workflows" due to being just stupid or something. But this is how it comes off to me, I think you mean something else, but I don't know what that is.
My approach is: I want files with code and I want to run some of those with some kind of entry point. And preferably organize it to files or something like that. This is the usual setup for general purpose programming languages. In general purpose programming you rarely tend to stick solely to one language, any larger project is usually a mishmash of different stuff, e.g. glue code in python, tight loops in C, maybe some bash thrown around to do some more trivial chores.
This is the overall structure of practically all general purpose programming languages. This requires interfacing with these languages (often done in bash or something in unixy systems at least) and tools that work regardless of language (e.g. version control, grepping, Make etc). Julia (and R and Matlab etc) just plain refuse to even consider this as a valid approach. If you mention it somewhere, you tend to get some bizarre instant putdowns that provide no real rationale, i.e. "you're just holding it wrong".
In programming I tend to think the whole computer and its OS and so on as the programming tool. My impression is that for Julia folks Julia is something totally separate from anything else in the computer. But I don't understand why. Is it that its felt that changing syntax on the fly is too cognitively demanding or something? This is something that one gets used to very fast. And also tends to ease the IMHO weird hung-ups on syntax. In fact, I think Julia has made some (IMHO misguided) syntactic decisions because they just want to do something differently from Python just for the sake of being different. I find this totally senseless.
Us CLI folks are not even asking for much. Just a way to call a program with arguments and so that you don't have to do compile identical code every time you do something. That's it. Is that unreasonable? It wouldn't take anything away from people using REPLs and Notebooks. We don't want to change the language, the language is fine and that's why we'd like to use it but just cant because these paper cuts!
I've expanded on my rationale for my workflow and how Julia makes it really difficult e.g. here, where I admittedly started with too strong wordings out of frustration: https://news.ycombinator.com/item?id=26134970
Look, everyone wants static compilation, and it's almost certainly going to happen eventually. It's not unreasonable at all to want that. The only thing that would be unreasonable is to (apparently repeatedly!) imply or assert that this lack of static compilation (and/or better caching) is due to some bizarre perversion on the part of the community.
If you want it to happen faster, then stop complaining about it on HN, get familiar with the current attempts at true static compilation in e.g. https://github.com/tshort/StaticCompiler.jl/pull/46 and start contributing yourself.
I like the "AOT-JIT" approach of Julia, and I think a separate compilation step is quite a stupid idea in the first place. I see it as some historical relic from computers with extremely limited memory (by current standards) and outdated business models that want obfuscated binaries.
My main gripe is just that I have to do it every time I run anything if I'm not using a REPL/Notebook, which drive me insane with their inconsistent and opaque global state. This could be solved mostly by caching the compilation results and compiling new stuff incrementally. But I'm starting to lose any hope that this is gonna actually happen.
Some lesser stuff follows from lack of this, but they should be relatively easily fixed.
For what it's worth, I've seen some nasty (though well meaning) pile-ons in the julia discourse, but for the most part it's a pretty nice place. I find though that the Zulip [2] and Slack communities are generally more friendly and relaxes places though.
No, you're not stupid. You've correctly identified current flaws in the tools, and the community tries to lead you to the tools that are known to work well in spite of the issues. We need to work a little bit more on the other tools to make them as good, but large parts of the community are just not the right people to work on that problem. It's not a design problem, it's fixable, but you just have more people who know how to make new differential equation solvers than you have people who can compile a binary, so the tooling ecosystem moves at a different pace from the scientific packages. This is changing with the help of some commercialization aspects though, but it is something we have to be cognizant of.
The world is bigger than you.
There is no need to insult people around.
I totally get that there are workflows that Julia is inappropriate for, but when someone says that a tool shouldn't be released because it doesn't target their workflow, I really don't know what to call that other than blindingly self centred.
More seriously though, just because some language may be considered "general purpose" doesn't mean it's the best language for everything, or should replace other languages outside of whichever particular applications where it excels.
No I don't. It needs some work in some places.