Sorry not to see a rehaul of the module system. I've talked to the devs and know its not a direction they want to take but I really wish they had tried to make Julia a language you can build modular applications around (like Python) instead of an all batteries included runtime (like R).
IMHO I think thats the sweetspot that could have been what many scientific computing developers are looking for. Python is good but has its problems when doing scientific computing (most addressed and fixed by julia btw) but you still use python because its much better than julia for building modular applications, and you use R because its much better than julia at doing exploratative work. So in the end julia is in this limbo of having fixed most of the problems with python but not being able to be used as a replacement for python.
Thats just my opinion though. I'm sure others will disagree :)
Are you talking about breaking modules (like linalg) out of base or changing the semantics and mechanics of modules?
I think the former is planned before 1.0?
If the latter, what do you think is the issue? Do you not like julia packages are separated into interface/abstract implementation and then concrete packages that can then have submodules that call each other?
Seems more modular than working around a python inheritance mess.
"Are you talking about breaking modules (like linalg) out of base or changing the semantics and mechanics of modules?"
Well, I'd be all for making Base as small as possible since I'm not big on monolithic standard libs and think everything possible should more or less be a package which you can include on a per project level.
As for the semantics and mechanics, I'd like to have the ability to have true public/private like rust or go, so that you can have a tightly defined public api and be sure your users only have access to that. Also I'd like to see the whole thing simplified it is way more complex than it needs to be. Just have import act like a function for example it could take a module, a keyword, and a vector like this:
import MyModule, :all # import all public defs
import MyModule, [a, b, K] # use as MyModule.a, MyModule.b, MyModule.K
import MyModule, :alias, [a,b,K] # use as a, b, K
compare the above to https://docs.julialang.org/en/stable/manual/modules/ as far as I can tell the functionality is the same. Anyway those were some of the things that I didn't like about it and would have changed.
Adding enforced access controls is certainly within the realm of possible future language enhancements, as is some tweaking of the module and import system (I'd like to collapse `import` into `using`, for example). But you seem to be doing a bit of a bait-and-switch in your comparison here: is Julia being compared with permissive, dynamic languages like Python and Ruby, or static languages with strict access controls like C++, Rust and Go? In terms of permissions and enforcement, Julia is quite similar to Python where access control is entirely by convention. In terms of binding resolution and modularity, it is quite similar to C++. People seem to be able to build large systems in both languages fairly effectively.
Programming for scientific computing also tends to lead toward needing/wanting access to "internal" types a lot more. Personally, I find the restricted-only-by-convention approach of Julia modules (and Python/R) to be very handy.
"But you seem to be doing a bit of a bait-and-switch in your comparison here"
You're right I might be conflating the comparison but does it matter? JavaScript is a dynamic language which allows strict access controls (although its semi-hacky to do it).
Also, when is access control by convention a good idea? Sure you can live with it as Python and Ruby devs like myself do, but compared to languages which give you stricter controls like Erlang (which is also dynamic) its pretty obviously worse when it comes to building large software systems because it weakens the guarantees you can make about your libraries and the libraries you use to build those libraries.
"People seem to be able to build large systems in both languages fairly effectively."
People can and have built large systems in assembly. That doesn't mean assembly provides the optimal means for building composable software. Why settle for something thats mediocre when you're still unstable and change it for the better?
Your argument is deeply confused. First Python is "much better than Julia for building modular applications", now it's flawed for the same reasons as Julia? Feature requests are fine but let's make them coherent please.
Yes you're right. Sorry about the overlap. Its been a while but from what I remember the module system doesn't have any concept of public/private i.e. fine grained control of an exported public api and essentially just lets everything inside a module be accessible. I didn't like that but you can live with it I guess. The package system is what was problemtic because it pulls everything into the runtime libs i.e. it works just like R. I was hoping they would have package management like elixir with mix, rust with cargo, or npm or some tool like that which allows you to build complex modular software.
Julia has export statements to make things public. You can always access the non-exported parts, yes, but that's true with _ variables in Python too (we're all adults and all that).
There is always someone claiming language"x" is a lisp with modern syntax, but that is simply not true. I'm not sure if there is a good definition of lisp, but homoiconicity is essential and to my knowledge only in languages like lisp (scheme, common lisp, racket...etc) and Rebol. Yes Elixir has a REPL and metaprogramming and the super awesome messaging model of Erlang, but it is not a modern lisp, rather a modern Erlang in my opinion. Note: I'm not a lisp user (I have dabbled) and am not arguing superiority, just that it's an apples to oranges comparison.
By module system, do you mean the ability to do something like "import sys; sys.function(blah)". As in having namespaces? Julia obviously has modules..
IMHO I think thats the sweetspot that could have been what many scientific computing developers are looking for. Python is good but has its problems when doing scientific computing (most addressed and fixed by julia btw) but you still use python because its much better than julia for building modular applications, and you use R because its much better than julia at doing exploratative work. So in the end julia is in this limbo of having fixed most of the problems with python but not being able to be used as a replacement for python.
Thats just my opinion though. I'm sure others will disagree :)