As John and Matt said, a huge portion of the standard library is written in Julia itself, so there's no real technical need for it to be developed within the same repository. In fact developing technical features as packages rather than as part of base allows getting features to users in a stable way on a time scale that the package developer has control over, rather than being subject to the readiness of features in the core language and compiler that obviously have to be done in the base repository.
> I can also find some > Fortran/C code, and include in Julia, and have all these > functionality, but then what is the advantage of using Julia, as > opposed to, say, python? Using Julia, your wrapper "glue code" will be shorter, simpler to understand, more efficient, entirely in the high-level language, and yet map more directly to the underlying library's interface. You just have to be able to point to a standard C or Fortran shared library and you can use that API directly, even interactively from the REPL. No need to invoke a separate compiler or build system at install time just for the language-specific binding code. Depending on the library, there will usually be less marshalling and worrying about cross-language data structure copying. > But since Julia is a language specifically for scientific computation That's not quite fair. Julia is a general-purpose language that happens to be designed to be very good at scientific computing tasks. (And most, but not all, of the early-adopter user and package developer community have come from that domain.) There are pieces included by default in the standard library right now that you would normally find in packages in the likes of NumPy or SciPy in other languages, but this may not be the case forever as the technical problems that have stood in the way of decoupling that development are gradually being solved.
