> Julia's authors get credit for trying to rewrite many core compute/LA libraries from scratch in a composable manner rather than using ancient fortran code nobody dares touch.

You can go even further than that. OpenBLAS, the BLAS linear algebra library that things like Julia and NumPy use by default now, was an MIT Julia Lab project. The developer was a research software engineer in CSAIL under Alan Edelman! And then the openlibm open source math library? Also made by the Julia developers. Julia developers like Steven Johnson and Doug Bates are also the ones behind some of the ancient classic codes like FFTW and nlopt. So in many cases they aren't just rewrites but rewrites by authors of the some (but not all of course) of the ancient codes!

(And many of these are C)

> OpenBLAS, the BLAS linear algebra library that things like Julia and NumPy use by default now, was an MIT Julia Lab project.

In what sense? The only "official" link that I can find is that one of the developers spent part of 2016 as a postdoc at MIT.

Yes, specifically to change focus from academic work to being "full time" on OpenBLAS a bit and clean it up as it started getting a lot more traction. Shortly after completing that he passed on the maintainership of OpenBLAS its growth, but that was how it sat until came along late in 2017 to pick it up from there.

This ends up being why a lot of people in the Julia Lab learned the internals and started creating pure Julia BLAS implementations, which continues to this day with things like LoopVectorization.jl and Octavian.jl (though Chris Elrod was not around during that time, so he comes with his own influences)

> And then the openlibm open source math library? Also made by the Julia developers

openlibm is just (yet another) msun repackage, isn't it?

It was cobbled together from msun and other sources to make a complete, portable, open source, liberally licensed libm, which—shockingly enough—did not exist in 2010 when we put it all together.

Thanks for all the hard work you and your colleagues put into Julia!

>... using ancient fortran code nobody dares touch.

Only the BLAS/LAPACK reference implementation are in F77. Intel MKL, OpenBLAS, ATLAS and other are all in a mix of C and ASM.

> This undated blog post (published in about May this year) is not the last word on Julia. There have been fixes made to issues brought up.

And yet this is an anticipated reaction:

> Whenever a post critiquing Julia makes the rounds, people from the community are often quick to respond that, while there have historically been some legitimate issues, things have improved substantially and most of the issues are now fixed.

> For example:

> [...]

> These responses often look reasonable in their narrow contexts, but the net effect is that people’s legitimate experiences feel diminished or downplayed, and the deeper issues go unacknowledged and unaddressed.

> My experience with the language and community over the past ten years strongly suggests that, at least in terms of basic correctness, Julia is not currently reliable or on the path to becoming reliable. For the majority of use cases the Julia team wants to service, the risks are simply not worth the rewards.