I think there is a widespread fallacy that assumes that the more contexts a language can be used in, the more “powerful” it is. Conversely, if one language is less than ideal for kernels, embedded systems, etc, then it is “less powerful”.
Of this, discussions without a clear purpose are born.
Doesn’t Zygote generate GPU kernels with Julia? Or is that the “wrong kind of kernel”?
Kernel isn’t a very specific word. I beleive this discussion uses kernel in the operating system sense.
for the “why” question on Stallman level:
the world badly needs a common language, hopefully Engilsh becomes that in 1-2 generations.
in my vision students learn Julia as their first language and for most, that will be the only language they need in their life. I’d like to see Julia to extend in the territory of other languages like Java, Javascript. Developers become fullstack earlier, easier. Then you will have more contributors on any opensource projects if they are written on the common language.
I’d like to see a Raspberry type cheap hardware booting into Julia REPL…
I’d love to see Julia become popular enough to be considered a lingua franca of programming, but I’d hate to have programming become monolingual, regardless of the language.
No, please. Although the term tends to be over-used these days, I actually think diversity is a very good thing, in natural and programming languages alike.
Apart from elimating other languages, which I don’t think is a goal on many people’s mind, none of what you said are about writing Julia in Julia. Having Julia run on rpi bare metal is a reasonable (not that I think it’s easy or close or that I want to do it, but it could make sense) goal and that’s exactly the kind of specific problem that you can work on and not actually related to which language Julia is written in at all.
Be careful what you wish for.
Languages specialize, and use cases shape a language. Being a “first programming language” (largely a pedagogical exercise, a niche filled by languages such as Scratch) and a web programming language are already largely conflicting goals. It is very likely that both of the are incompatible with Julia’s focus.
This does not mean that Julia cannot accommodate a lot of use cases, but languages designed to be the last language anyone ever needs have not been successful historically — they end up not being good enough for any of their target domains.
This sounds horrible. Being multi-lingual has well-documented benefits for your brain, and knowing several programming languages makes you a better programmer.
Having a lingua franca (English, Julia) that everyone knows, alongside other languages? Eh, maybe, though I’m skeptical. But everyone who talks or codes is better off knowing more than one language.
Slightly OT… I learned a lot from your comments about the GC, but they are scattered all over the archives.
I am wondering if you could please consider writing a blog post about GC in Julia: how it works (broadly), what is the intuitive performance model, things to watch out for, how you generally optimize code for memory allocation.
It would help a lot of people, since knowledge about GCs is pretty arcane for most scientists-turned-programmers.
With regard to the overall compiler discussion, I have these thoughts:
Julia has a lot of implementation languages:
My opinion is that Julia doesn’t need to be rewritten entirely in Julia, but that there is virtue in minimizing the number of languages used in the implementation of any technology.
The parser is the easiest to replace with statically compiled Julia. Julia is almost a dialect of Lisp already (minus TCO, grumble grumble). The benefit of this is that Scheme is already the most obscure of these languages–aside from Julia itself of course, but we can take for granted that anyone interested in contributing to the compiler is already familiar with Julia. Scheme is a beautiful language, but it’s expendable as far as the Julia implementation is concerned.
While C++ is my least favorite language of those in which Julia is implemented, it’s the hook to LLVM and the most difficult to replace. (though, Rust was originally implemented OCaml and is now implemented in Rust, so I guess it’s not impossible)
On the other hand, converting C to the common subset of C and C++ isn’t the hardest thing in the world. On the third hand (ran out of hands) maybe C and C++ are similar enough that we could consider anyone who knows C++ also knows C (this is manifestly not the case, but maybe it’s close enough?)
In any case, I would be happy to see Julia be implemented in Julia and X lower-level language, since Julia isn’t the ideal language for granular control of memory or LLVM interop (yet). It looks like C++ is X language at this point.
The point of all this is, we may not need Julia in Julia, but are there any prospects for reducing the number of implementation languages? LIke, ideally to <= 2?
Of course, I’m not suggesting that *I* do these re-implementations. Don’t be absurd! My C is mediocre, my Scheme is insignificant and my C++ is non-existent. I’m merely suggesting that everyone else should implement the language exactly as I propose. Snap to it, boys.
It doesn’t need a statically compiled julia. It needs a parser to parse itself, which is completely independent from how the parser runs. This just means that requiring julia as a build dependency of julia or have a simpler parser written in whatever language that can parse the julia parser in julia.
Julia’s C code is C++ compatible.
Sounds like you’d be interested in WIP: Import Tokenize/CSTParser/FancyDiagnostics by Keno · Pull Request #31954 · JuliaLang/julia · GitHub (see also https://github.com/JuliaLang/julia/pull/32201)
There are open PRs to try replacing the femtolisp parser with CSTParser, so that’s something to look forward to. Other than that, I think keeping the C++ code as far away from the C-only code is a good thing and makes it easier for people like me (who have no desire to re-learn C++) to contribute to the runtime.
As someone who’s only occasionally dabbled that deep in Julia’s internals and who only really knows C, I find Julia’s C++ very readable. It’s a very small subset of C++, mostly just using the features that LLVM’s API demands. I very much appreciate it. I often wince when folks glob together C/C++ as one language, but here the C++ is actually written almost like C.
So yeah, we could pretend the C files are actually super-limited C++, but as a rare contributor I actually like the current use of the two languages — limited C++ when it’s needed, C otherwise.
That’s my favorite kind of C++ 
, just C with the occasional obj->method() call.
I tend to gravitate towards templated C++ code because of an ideal of expressing a generic concept in only a few lines, but I definitely recognize the verbosity / general lack of readability of templated C++ code and its (anti?) patterns (e.g., CRTP). That’s what attracted me to Julia in the first place.
I think the concept of “C where possible, ‘basic’ C++ where necessary for LLVM interop” makes sense for Julia from the point of view of making it relatively easy to contribute + performance, and given the core developers’ experience.
I think this is a very important development, if just because of tighter integration between the core language and IDEs (see also this thread I started a while back: Talk by Anders Hejlsberg on interplay between editors and compiler).
I know you are being sarcastic, but there is an important point here. I think the only people qualified to have an opinion on the parts written in FemtoLisp, C, and C++ are those who actually worked on the relevant code.
When they feel that there is a benefit from rewriting stuff in Julia, I imagine that they will rewrite it. Discussions by people who are not familiar with this code add little value and a lot of noise. Code rarely (if ever) gets rewritten because of aesthetic concerns of people who are not contributors.