It is wrong to expose such level features into a a programming language. These are exposed as actual types. More and more stuff is being added to HTML, CSS and is without any thought as to what the language is meant for. Just because it can be done does not mean it should be. It is a better approach to advance type interference and compiler technology, add language primitives that assist such code generation.
The web page shows a Mandelbrot which is a terrible example because they are best done with shaders. In face there is no real use case for this. There will always be specific things that cannot be done and no language can address them all. How many apps need SIMD based physics? In fact I am not even sure what kind of physics needs SIMD.
So, before we had shaders, we used hand-written SIMD to perform those calculations as quickly as possible. Even with shaders available, there are broad categories of numerical work where you can't justify the expense of putting things out on a GPU but you still want them to be done quickly.
Good examples of this are basic vector arithmetic, which is useful for graphics and scene management and physics, or certain types of hashing, or anything else.
In some magical future land where sufficiently advanced compilers drop out of trees, maybe you have a point--but this is the web, son, and we're as quick and dirty as you can get.
Auto-vectorization is an extremely complicated topic. This stuff is slow. Not a big deal with AOT compilation, but it's of course a huge deal if you only have a few msecs to spare.
Also, a machine can't just jumble the operations around because that would change the result.
So, this is apparently something you have to do yourself. A compiler won't know what kind of data will be fed to that function. It can't make an informed decision.
> In fact I am not even sure what kind of physics needs SIMD.
It generally just means that you use some physics library which makes use of SIMD. Without having to do anything special, your game will run drastically better an use less energy to boot.
That's the primary use case; using libraries which use SIMD. Most people won't bother doing that by themself.
If speed and compilation is a concern, let's start with having proper types in javascript. That will speed things up a whole lot faster and save a lot of battery than this.
I am not saying this won't make things faster. There are many things you can do to make things faster but this really is such a niche feature (for web based apps).
> If speed and compilation is a concern, let's start with having proper types in javascript.
That is a much harder problem, especially since you brought up performance. Getting the interaction between dynamically typed and statically typed code to work in a way that's both easy and natural to use and allows compilers to get significant benefits from the statically typed code is an unsolved research problem.
Yes, it is. However, it's relatively easy to implement and the performance improvements and battery savings are fairly huge. All things considered, it's a pretty good deal.
The web page shows a Mandelbrot which is a terrible example because they are best done with shaders. In face there is no real use case for this. There will always be specific things that cannot be done and no language can address them all. How many apps need SIMD based physics? In fact I am not even sure what kind of physics needs SIMD.