Having said that, I can easily agree with the remainder of the post that the existing languages/ecosystems aren’t alternatives, and that statement does not change if you correct Scala’s “great performance” to “mediocre performance”.
The high performance part of your Haskell code might not look much like idiomatic Haskell in the end, but you can write abstractions around that. (The holy grail is high performance idiomatic code. If you befriend the compiler just right, it's possible for many problems.)
Text.Bytestring is a good example in Haskell land.
Despite that, fusion is beautiful and happens without all of that verboseness that makes the same thing in C++ work.
If you needed to squeeze the last bits out of your hardware you would have to waste more time. That's my main complaint. As verbose as C++ is I still can't make stuff perform as best as it could in Haskell/Scala/Java without spending more time (much more than it would take me to fix in C++).
All of the languages are nice to work with but for some reason the more you distance yourself from the data representation in your memory (with references, boxes etc.) larger the time you have to spend to makes things fast, and all of those abstractions that saved you time, now turn out to be the overhead you don't want, and all of those abstractions now need to go away.
I guess value types might change the thing for Java and other JVM languages. Can't wait to see how successful it'll be.
The function's certainly there. I don't think it will automatically collapse an AB+C operation (though there's no reason that can't be implemented), but you wouldn't get that in C++ either (or rather, the template-fu needed to achieve it there would be harder than doing it in Scala).
> All of the languages are nice to work with but for some reason the more you distance yourself from the data representation in your memory (with references, boxes etc.) larger the time you have to spend to makes things fast, and all of those abstractions that saved you time, now turn out to be the overhead you don't want, and all of those abstractions now need to go away.
Yes and no. I'll grant that it's very rare to find a language that's better than another in every conceivable circumstance. But there's no law that abstractions have to be expensive (I guess that's part of the point of Rust). And even when they do come with a cost, computers get cheaper and programmers get more expensive.
Try writing a fast A* (without any pointers and memory management, easily done in C++), maybe a travelling salesman problem -- simple 2-opt heuristic (easily done without memory management). If you find these suitable for libraries, and not something you would write on your own, there's not a single fast matrix library implementation in Java or Haskell. If something that "simple" can't be done, then, in my case, I cannot use these languages as easily as I can use C++.
A simple principle, a simple idea of copy and move semantics enabled me to write C++ code without worrying much about memory at all. When allocations become a problem, I just move the container out of that heavy loop, or change my malloc implementation with a simple flag, and it's still 10x if not 100x faster than what Haskell/Scala/Java could accomplish in the same amount of time it took me to write the C++ code.