arrow-julia VS ITensors.jl

For some examples of people porting existing C++ Fortran libraries to julia, you should check out https://github.com/JuliaLinearAlgebra/Octavian.jl, https://github.com/dgleich/GenericArpack.jl, https://github.com/apache/arrow-julia (just off the top of my head). These are all ports of C++ or Fortran libraries that match (or exceed) performance of the original, and in the case of Arrow.jl is faster, more general, and 10x less code.

I guess current preferred format not feather, but arrow: https://github.com/JuliaData/Arrow.jl

Excited to see this release's official inclusion of the pure Julia Arrow implementation [1]!

It's so cool to be able mmap Arrow memory and natively manipulate it from within Julia with virtually no performance overhead. Since the Julia compiler can specialize on the layout of Arrow-backed types at runtime (just as it can with any other type), the notion of needing to build/work with a separate "compiler for fast UDFs" is rendered obsolete.

It feels pretty magical when two tools like this compose so well without either being designed with the other in mind - a testament to the thoughtful design of both :) mad props to Jacob Quinn for spearheading the effort to revive/restart Arrow.jl and get the package into this release.

[1] https://github.com/JuliaData/Arrow.jl

DMRG packages are available in Julia and C++ and Python. (Don't use Fortran. But here is a Fortran library if you insist.)

As one example, one of the leading libraries for tensor network simulations (https://itensor.org) has recently been rewritten in Julia (previously was c++) and the flatiron institute who develops it (which is certainly one of the leading Computational physics institutions in the world) is advising new users to use the Julia version. I also know some other computational groups which use Julia, even for things like quantum Monte Carlo (where I personally would have believed c++ to have an edge but people tell me different)! I think when even leading computational groups switch, Julia is almost always the much better option for the average user if you write your code from scratch (a situation not so rare in condensed matter). If you need to use some libraries or legacy code, this obviously changes the situation.

> One thing that supports this view is that there are several Julia packages that are wrappers around existing C/Fortran/C++ libraries, and basically no examples (that I know) of people porting existing libraries to Julia.

As with the others, I'll strongly disagree and chime in with a few examples off the top of my head:

* ITensors.jl : They started moving from a C++ to Julia a couple years ago and now their webpage doesn't even mention their original C++ implementation on its homepage anymore https://itensor.org/

* DifferentialEquations.jl : This has many state of the art differentiatial equation solving facilities in it, many of which are improvements over old Fortran libraries.

* SpecialFunctions.jl, Julia's own libm, Bessels.jl, SLEEFPirates.jl : Many core math functions have ancient Fortran or C implementations from OpenLibm or whatever, and they're being progressively replaced with better, faster versions written in pure julia that outperform the old versions.

Otherwise, maybe check ITensors.jl or look for packages that want to do the same thing?