Hacker News Reader

Comment by smabie | Hacker News Reader

It seemed to me that no one actually made projects that used the module system at all? Like no name spacing what so ever, just a bunch of include!s

View on HN

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.

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).

[1] https://docs.julialang.org/en/v1/manual/style-guide/#Avoid-t...

> 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).

Reply on news.ycombinator.com