/jump to repo

Repos Recent Bookmarks Watched Notes Tags Discover Compare Stats GitHub

Repository brief

JuliaLang/julia

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis

cached 2026-03-30T11:58:05.961Z

3mo ago

JuliaLang/julia

JuliaLang/julia is the upstream source repository for the Julia programming language: a high-level, high-performance dynamic language for technical computing. It is very active, with recent commits as of 2026-03-29, a large community footprint, and a broad source tree that includes the compiler, lowering/syntax components, standard library, CLI, docs, tests, and build/dependency infrastructure.

Loading tags...

Stars48,532

Forks5,755

Default branchmaster

Last pushed2026-03-29T11:53:15Z

Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

10 of 10 fork briefs

Maintenance:

Magnitude:

Sort:

Selected

Prefer this fork only if you specifically need its old, custom Julia internals and are prepared to maintain a long-lived divergence. For most users, upstream Julia is a much better choice because this fork is stale and substantially behind current language, compiler, and tooling work.

Choose this fork only if Android/Termux support is the main goal. For general Julia development or production use, upstream is far newer and safer.

Prefer upstream unless you specifically need an old, highly customized Julia branch. This fork is best treated as legacy code for archaeology, backporting, or historical experimentation, not as a modern starting point.

Choose this fork only if you need the historical Portuguese-localized branch or its old runtime/compiler experiments. For almost any active development, production use, or modern Julia compatibility work, upstream JuliaLang/julia is the better base.

Choose this fork only if you need its specific experimental/compiler-oriented changes and are prepared to maintain a large divergence from upstream. For general Julia users, upstream is the safer choice because this fork is stale and materially behind current development.

Prefer upstream Julia unless you specifically need this fork's historical process/runtime experiments. For new work, the fork is too stale and too divergent to be a low-risk base.

Choose this fork only if you specifically need its older, heavily modified compiler/runtime state. For most adopters, upstream Julia is the safer and more current base; this fork looks useful mainly for niche experimentation or legacy maintenance.

Prefer upstream JuliaLang/julia unless you specifically need this older snapshot; the fork adds no visible capabilities and is substantially behind on upstream maintenance and fixes.

Prefer this fork only if you explicitly need its old, highly customized Julia internals. For almost any adopter who wants a maintained language base, upstream is the better choice.

Prefer upstream unless you specifically need this historical fork’s behavior or patches. The fork is not maintained, is far behind current Julia, and is only attractive for legacy reproduction or deep compiler experimentation where you control maintenance.

Fork comparison

jadijadi/julia

38/100

stale

significant_divergence

Prefer this fork only if you specifically need its old, custom Julia internals and are prepared to maintain a long-lived divergence. For most users, upstream Julia is a much better choice because this fork is stale and substantially behind current language, compiler, and tooling work.

Likely purpose

A heavily diverged, old Julia branch aimed at compiler/runtime experimentation and custom backend/runtime work rather than staying current with upstream Julia.

Best for

Compiler researchers who want a historical Julia fork to study or extend.; Teams maintaining a legacy Julia-based stack that depends on old runtime behavior.; Adopters who need a custom backend or patched dependency set and are willing to own the maintenance burden.

Additional features

Custom compiler and code generation changes in `src/codegen.cpp`, `src/cgutils.cpp`, `src/gf.c`, and `src/subtype.c` suggest experimentation with Julia internals.
A patched LLVM dependency (`deps/patches/llvm-rL327898.patch`) indicates custom backend integration beyond vanilla upstream Julia.
Changed `stdlib/LinearAlgebra/src/lapack.jl` suggests fork-specific numerical library behavior or integration work.
Repository changes in `.github/workflows/` and compiler devtools paths suggest added or adjusted contributor and CI workflows for this branch.
Adds plugin, tool, or MCP-style extensibility beyond the upstream baseline.
Changes agent workflow behavior, such as prompt handling, handoffs, worktrees, memory, or orchestration flow.

Missing features

It is far behind upstream Julia, so it likely misses years of runtime, lowering, inference, GC, and codegen fixes that landed after 2019.
Current upstream compiler architecture work around `JuliaLowering`, `subtype`, GC profiling, and coverage tooling is not reflected here.
Modern upstream docs, tests, and maintenance updates are likely absent or stale, making this a poor fit for users who want a current Julia base.
The fork appears to have large deletions in compiler tests and markdown test assets, which can make validation and contributor workflows harder.
It trails upstream by 218 commits, so some recent upstream features and fixes are likely not present yet.

Strengths

Useful if you need an old, highly customized Julia internals baseline.
Large source-level divergence suggests room for research, patching, or teaching purposes.
May preserve specific historical compiler or library behavior that newer Julia versions no longer have.

Risks

Very stale activity with last push in 2019.
Large divergence from upstream makes rebasing, security updates, and bugfix tracking difficult.
Users targeting modern Julia packages, tooling, or compiler internals will likely hit compatibility issues.