Thank you! I apparently just made a wrong assumption that Julia was a language for scientific computing only. Once I think of it as a general purpose language, the current structure makes total sense, just as it does for python.
On Sunday, July 12, 2015 at 4:47:04 AM UTC-4, Tony Kelman wrote: > > 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. > >
