The blog post linked is worth reading. This part in particular:

> While you were reading this article, the test scripts have already run. So open up the developer console and check it out!

That was really slick.

I think while flang (https://github.com/llvm/llvm-project/tree/master/flang) is getting more stable. It would be a lot easier to compile Fortran into WASM with LLVM's WASM backend

That would save a few steps (gfortran, dragonegg, llvm-as), so it's definitely worth trying.

But note that technically speaking the current approach also uses the LLVM wasm backend (after doing all the above, it uses the LLVM wasm backend to compile LLVM IR to wasm).

It's awesome that BLAS for the most part will compile (except for the "Complex and quad-precision numeric support is still unavailable, but the rest works just fine." according to the article)

CBLAS (and CLAPACK) can already be compiled. It is used for example in https://pidtuner.com

Is there something about Fortran that makes is a more attractive language for WebAssembly than, say, C?

Or is this project more of a "I did it because it was there and I can" (which is certainly a good reason as well)

A lot of fluid dynamics code is in Fortran and has been validated in wind tunnel. Scientists do not care about what language it is in nor they want to port and risk breaking the pre validated code. They want to run the code and be able to provide a citation as the ground for their work. Scientifically they would need to produce academic literature validating the port and only then come back to the matter at hand.

All of the stuff at Ames that ran on the Cray, was written in HPE Fortran, because the compiler has the ability to vectorize it, and yes, a lot of those fluid simulations that are in their final form for airfoil design do get validated in wind tunnels.

I would love to see some fluid dynamic work run in a web browser, but ... You need the WebAssembly to be able to vectorize and optimize it: See Airvisual.com

or

https://paveldogreat.github.io/WebGL-Fluid-Simulation/

Fortran doesn't have pointer arithmetic, and pointers that decay like C. The compiler can be much more aggressive about optimization.

Passing around variable length arrays and arrays with a variable number of dimensions is much easier than C. You don't need to worry about making your own interface around blocks of memory or macros to do this sort of routine thing.

Bounds checking is standard in every Fortran compiler.

Fortran does what its name implies: FORMula TRANslation of math code without a lot of noise.

Yes, 50 year old Fortran code can be hard to read. But, there are tools that can statically 'modernize' it if you really need to do maintenance on it.

I suppose the #1 reason to pick Fortran over C is knowing Fortran and not C. Then doing it because you can.

Maybe you have a math library in there worth putting into wasm.

Second one is performance for numerical computing, followed by modules, generics, OOP and almost forgot that one, better type safety.

While reading the blog article, I kept wondering what the performance was like compared to bare metal?

I guess the performance hit is similar to the one C and Rust take? In the order of 10x slower IIRC? How does a Fortran-written (better optimized) library compare to a C-written one? Is the WASM overhead enough to nullify the performance difference? Are the original optimizations well translated to WASM?

#2: Due to the differences in language design, Fortran admits better generated machine code optimization than C does.

Fortran is probably easier to learn than C and it also has some cool cuda and parallel extensions.

Fortran is much easier to learn (compared to C/C++), much, MUCH easier, including its Coarray one-sided communication parallel programming paradigm.

*>math library

Ah, that's right. There's a ton of scientific software in FORTRAN.

Your supposition is likely inaccurate.

Some of our core assets are still in Fortran.

What do you mean by our? I guess you mean collective scientific community?

That, and lots of companies. Everything thats old and not COBOL is FORTRAN.

Yes, this is certainly true. I work with a "modern" ERP that just had it's newest release. Lots of low level pieces are stíll in COBOL.

Alongside UNIX and C, which happen to be just 10 years younger, but people keep forgetting it.

In fact, Fortran is one of the oldest and newest programming languages in the world right now, with the Fortran 2018 standard released just recently.

Does anyone know whether VBA will be compiled to WebAssembly?

I'm not sure it can. I've worked with VBA professionally and it always needs to run within an Office application like Access of Excel. A transpiler is probably doable, but I don't think it would be easy or even possible to port things using VBA to webasm.

Hm. So did anyone adapt MPI on web assembly to work over web sockets yet, for a dyi folding@home etc ?

Call me when you can compile Cobol to English.

Did you miss?: https://news.ycombinator.com/item?id=22888170

Strong point!!

Not there, but JVM, .NET and WebAssembly backends are already there.

Sacrilege