About the superoptimizer:
If we can automatically derive compiler optimizations, we might be able to sidestep some of the substantial engineering challenges involved in creating and maintaining a high-quality compiler.
Don’t get me wrong, I like how Julia is fast as C (while ironically it may feel slower than Python), and @code_native etc. It was made for technical computing/HPC, and I can see how people may think this suggestion of lower opt. is admitting defeat. But less optimization gives you time to use your time more wisely, with e.g. (always targeted) superoptimization.
@Elrod’s work with @avx may not be one in a strict sense, while it feels like it to me.
The way I see it, is, people giving up on Julia, for some work, where e.g. Python (or Perl) are good, so we’re sacrificing world dominance for the smaller HPC/Fortran environment/language replacement:
I would hate to throw the bath out with the bathwater, and succeed at neither. It doesn’t have to be either or. I mean, to me (not all) Julia has proven to be a Fortran (and MATLAB) replacement. It’s the only inherently fast interactive language I know, but we know about the endless (well until recently) time-to-first-plot issue, and the “short script” problem above is just the same. Most people aren’t going to accept Julia as a Python/MATLAB replacement, until those issues go away, and they will stay to some degree with the current default.