Indeed, that was a fun article to reread. Interesting that 6 years on, his prediction hasn't come to pass.
I should clarify that I don't actually care much about performance. I'm bootstrapping from machine code not to keep things fast but to control the total implementation stack and so keep it comprehensible. Julia's use of native assembly is just to help people make their programs faster, not to help more people get into the compiler. It's yet another language telling you to use it as "an abstraction" and not worry about the details. Which compromises the whole point of open source: getting more eyeballs on the code.
Yeah, I didn't even really register his prediction because I'm used to taking such statements with piles of salt.
Without a clear niche and "killer app", most languages don't have any way to draw attention or attract new programmers. I've run across Julia before, but never had a reason to look at it for more than a few seconds. Today I looked at it long enough to read half of the metaprogramming page, and file it away for potential future use if I need an array-oriented language or have a data science project, just for fun.
But most people won't hear about it, and won't have the same tendencies I do to try doing new projects in new languages. Perhaps Julia does have a specific problem it's trying to solve, and people with that problem are more likely to discover and adopt it, but that doesn't translate to the broader community very quickly.
> I'm bootstrapping from machine code not to keep things fast but to control the total implementation stack and so keep it comprehensible.
Yes, and I think you've made that point fairly well, but this was a fairly helpful clarification and restatement. Perhaps there are several dimensions to "exposed internals": visibility, accessibility (that is, manipulatability), and comprehensibility or traceability. And I think attempting to maximize these attributes will lead to a design much like you have in Mu of minimizing the overall surface area of the internals - otherwise they may start to obscure each other. Traceability at least is facilitated by shorter traces; that is, fewer layers of abstractions to navigate.
It seems that formal systems often follow an axiomatic model, parsimoniously adding layers as necessary, while industrial systems are more of the 'large, flat' model that build on top of an existing platform but don't add more than a few layers of abstraction. Generally just classes, interfaces, and service APIs. At the same time, the formal systems don't necessarily add true "layers", because identities are preserved across abstractions. Something to ponder more I guess.
Also, regarding performance, I'm not really sure how merely seeing the assembly code output by Julia helps that much if you can't directly control it. I could see it being helpful for sanity checks, or for learning about how the machine works (that's why I thought it was relevant), but it would be really hard to use for tuning.
> Do you know if building the Julia compiler relies on a previous version of the Julia compiler?
I don't know for certain, but it looks like the src directory contains a lot of CPP and some "flisp", so I would guess not.
I think the main reason Julia hasn't taken off is they arrived rather late to the party in terms of their target audience. Using Python and R to script libraries (or binaries) compiled in C and Fortran already had the momentum in the data science space. Julia first appeared in 2012 [1], which is also same year as the initial release of Anaconda [2], essentially a packaging and streamlining of what many in the scientific community were already doing with Python and R. With deep learning and data science really taking off in popularity the last few years, Python was the ecosystem of choice for most.
Julia might have a bright future. It seems to have a small but thriving community and its ambitions match what a lot of people want out of a programming language. The problem is that at this point "Python driving C+Fortran" is the 200 lb behemoth they're competing with, and face nontrivial competition from a host of other languages (R, Matlab, Go).
