# Julia written in Julia?

**URL:** <https://discourse.julialang.org/t/julia-written-in-julia/25781>\
**Category:** Internals & Design\
**Tags:** question\
**Created:** [June 27, 2019, 10:31pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781 "2019-06-27T22:31:17Z")\
**Posts on this page:** 18\
**Page:** 2

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 30, 2019, 12:16pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/21 "2019-06-30T12:16:10Z")

</div>

> [@StefanKarpinski](#):
>
> So if you want to write a kernel, you could do it but Julia is a weird choice.

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.

---

<div class="post-metadata">

**Author:** ![ninjaaron](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ninjaaron/32/6392_2.png) [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)\
**Post date:** [June 30, 2019, 3:53pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/22 "2019-06-30T15:53:31Z")

</div>

Doesn’t Zygote generate GPU kernels with Julia? Or is that the “wrong kind of kernel”?

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [June 30, 2019, 5:01pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/23 "2019-06-30T17:01:44Z")

</div>

[Kernel isn’t a very specific word](https://en.wikipedia.org/wiki/Kernel#Computing). I beleive this discussion uses kernel in the [operating system sense](https://en.wikipedia.org/wiki/Kernel_(operating_system)).

---

<div class="post-metadata">

**Author:** ![ruszkipista](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ruszkipista/32/7381_2.png) [@ruszkipista](https://discourse.julialang.org/u/ruszkipista)\
**Post date:** [July 1, 2019, 6:37pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/24 "2019-07-01T18:37:22Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [July 1, 2019, 6:42pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/25 "2019-07-01T18:42:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sgjanssens](https://avatars.discourse-cdn.com/v4/letter/s/9f8e36/32.png) [@sgjanssens](https://discourse.julialang.org/u/sgjanssens)\
**Post date:** [July 1, 2019, 6:47pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/26 "2019-07-01T18:47:39Z")

</div>

> [@ruszkipista](#):
>
> the world badly needs a common language, hopefully Engilsh becomes that in 1-2 generations.

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.

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 1, 2019, 6:52pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/27 "2019-07-01T18:52:57Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 2, 2019, 6:14am UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/28 "2019-07-02T06:14:54Z")

</div>

> [@ruszkipista](#):
>
> 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.

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](https://scratch.mit.edu/)) 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.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [July 2, 2019, 7:39am UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/29 "2019-07-02T07:39:53Z")

</div>

> [@ruszkipista](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 2, 2019, 11:29am UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/30 "2019-07-02T11:29:29Z")

</div>

> [@yuyichao](#):
>
> One thing to realize is that freeing is not free. You must do work to free memory, work needed so that you can use the memory again, or else why are you freeing the memory in the first place…
> 
> So there are basically two aspects of freeing memory afa the GC is concerned, to mark it as not needed and to actually free it. In a tracing GC, the first is free (dead memory cause no time in marking) and does the second in bulk. Both of these are very important for the performance of the GC. In particular, the bulk freeing is actually one of the main reason, I believe, that a GC can achieve higher throughput than manual memory management. That this means is that if you don’t do freeing in bulk, you can easily loose performance, rather than gaining it and just marking something free is useless since it doesn’t take the GC any time to ffigure that out anyway.

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.

---

<div class="post-metadata">

**Author:** ![ninjaaron](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ninjaaron/32/6392_2.png) [@ninjaaron](https://discourse.julialang.org/u/ninjaaron)\
**Post date:** [July 5, 2019, 7:48pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/31 "2019-07-05T19:48:20Z")

</div>

With regard to the overall compiler discussion, I have these thoughts:

Julia has a lot of implementation languages:

- Scheme for the parser
- C for the runtime.
- C++ for LLVM
- Julia (because the first thing the parser does is convert a lot of of syntax into simple function and macro calls).

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.

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 5, 2019, 8:07pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/32 "2019-07-05T20:07:45Z")

</div>

> [@ninjaaron](#):
>
> The parser is the easiest to replace with statically compiled Julia.

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.

> [@ninjaaron](#):
>
> On the other hand, converting C to the common subset of C and C++ isn’t the hardest thing in the world

Julia’s C code is C++ compatible.

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [July 5, 2019, 10:27pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/33 "2019-07-05T22:27:04Z")

</div>

Sounds like you’d be interested in [WIP: Import Tokenize/CSTParser/FancyDiagnostics by Keno · Pull Request #31954 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/31954) (see also [https://github.com/JuliaLang/julia/pull/32201](https://github.com/JuliaLang/julia/pull/32201))

---

<div class="post-metadata">

**Author:** ![jpsamaroo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jpsamaroo/32/46804_2.png) [@jpsamaroo](https://discourse.julialang.org/u/jpsamaroo)\
**Post date:** [July 5, 2019, 11:52pm UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/34 "2019-07-05T23:52:18Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [July 6, 2019, 1:50am UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/35 "2019-07-06T01:50:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [July 6, 2019, 4:08am UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/36 "2019-07-06T04:08:56Z")

</div>

That’s my favorite kind of C++ 😬, just C with the occasional `obj->method()` call.

---

<div class="post-metadata">

**Author:** ![tkoolen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkoolen/32/1603_2.png) [@tkoolen](https://discourse.julialang.org/u/tkoolen)\
**Post date:** [July 6, 2019, 5:02am UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/37 "2019-07-06T05:02:39Z")

</div>

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.

> [@jpsamaroo](#):
>
> There are open PRs to try replacing the femtolisp parser with CSTParser, so that’s something to look forward to

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](https://discourse.julialang.org/t/talk-by-anders-hejlsberg-on-interplay-between-editors-and-compiler/11570)).

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 6, 2019, 6:01am UTC](https://discourse.julialang.org/t/julia-written-in-julia/25781/38 "2019-07-06T06:01:48Z")

</div>

> [@ninjaaron](#):
>
> 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.

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.

[Previous page](https://discourse.julialang.org/t/julia-written-in-julia/25781.md?page=1)