Anything in specific you feel like is missing from the module system and testing framework? Knowing what features people want helps a lot with setting development priorities.
I could make a laundry list of features (for example: not being forced into a linear order of includes (or at least having idempotent "include"s), no namespace collision for test files, not having to list all the tests in "runtests.jl",[1] support for pending tests, support for parameterised tests, proper assertion libraries with more useful error output, etc. pp.), but I also feel like Julia developers could just look at any of the other major general purpose languages, almost all of which have better module systems and testing frameworks because these are things that matter to application developers.
Some of these would definitely be good to have issues/pull requests to track progress on. That said, I'm not sure how useful parametrized tests are in a language with first class functions. Also, for more useful error outputs, there was a PR merged just a few days ago that helps with improving the error output.
In general though, specific issues with use-cases (or even better PRs) are the best way to direct change in an open source language. It's much easier to prioritize development if we know that a specific feature is wanted.
Every package is a module, and Julia is well-known to not have monorepos and instead split packages into small modules. So I don't quite see how this follows: there's no PyTorch, instead there's Flux, NNLib, NNLibCUDA, NNLibAMDGPU, CUDA, GPUCompiler, KernalAbstractions, ... (it keeps going), all of which are documented packages in their own modules that make up the ML stack.
I feel like the DifferentialEquations package is a screamingly obvious counterexample to your claim. It has many sub-modules. Moreover, the whole point of multimethods is to live in the main semantic namespace, you do not need as many name spaces because there are no names to clash.
> you do not need as many name spaces because there are no names to clash.
You know, maybe you're right and I can't prove you wrong, but this is the kind of thing that IMHO application developers read and think "yeah no, been there, done that, never again". Because many people's experience is that names do clash, again, and again, and again, and I fail to see why multimethods should solve that.
Does this example help: There is a name defined in Base, e.g. `pop`. In languages that do not use multumethods, when you created your own "FancyContainerLibrary" you need to create a new `pop` and ensure it does not clash with `Base.pop`. In languages with multimethods you just extend `Base.pop` to work on your new type. Julia can do both: it has perfectly normal support for namespaces, but frequently you will be extending Base methods instead of working in your own namespace (of course, all your private functions are usually unexported and available only from your namespace and do not polute the global space).
I've only kicked the tires on Julia a bit, but it seems like while methods are less likely to clash, they still might if you happen to use the same name and argument types? Or maybe unexpected method resolution causes a bug?
While that might happen (and probably cause a method redefinition), there is an important convention that helps preventing it: your package must either own the function or at least one of the types used for arguments, otherwise you're practicing type piracy [1]. I've seen an automated scripts that can detect type piracy, so hopefully it could be part of a linting toolset eventually since not everyone might be aware, but at the very least popular packages shouldn't have them - or at least not in a way that may cause bugs (and if any package has it unintentionally it's probably worth creating an issue).
I'm kind of unclear what module signatures would be since Julia lets code define modules at runtime, so I don't think this could be meaningfully defined for Julia.
For most intents and purposes one can use a (potentially Singleton) type passed as a argument to functions instead of a module containing functions.
And doing that gets you all the tooling and power you could want.
(But probably in a different way to you want it).
Since multiple dispatch takes care of that.
You can compare and contrast MLDatasets.jl (uses submodule per dataset) vs CorpusLoaders.jl (uses a extra type argument per dataset)
I agree with you guys. I have been coding in Julia for 2 years and very little has happened in tooling. For example, the graphical profiler is buggy. I love the language though. Hoping things will change!
5. The module system is very primitive.
6. The testing framework is extremely barebones.
I agree with your assessment, Julia is great for crunching numbers etc., but I wouldn't write a whole application in it.