Templates problem

[deXtoRious via Digitalmars-d-learn]

On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer 
wrote:
> The "One language to rule them all" motif of Julia has hit the 
> rocks; one reason is because they now realize that their 
> language is being held back because the compiler cannot infer 
> certain types for example: 
> http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/

As an avid user of Julia, I'm going to have to disagree very 
strongly with this statement. The language is progressing very 
nicely and while it doesn't aim to be the best choice for every 
programming task imaginable, it already does an excellent job of 
letting a scientific programmer such as myself do most of my 
workflow in a single language with remarkable performance. 
Furthermore, the article you linked pertains to a simple type 
inference issue, exposed by the design constraints of a 
particular library. While certain design patterns can and often 
do lead to Python-style Julia code with optimal performance, you 
can always get there by manually enforcing type stability at the 
cost of less pretty code.

More to the general point of the discussion, I find that most 
scientifically minded users of Python already appreciate some of 
the inherent advantages of lower level statically typed languages 
and often rather write C/C++ code than descend into the likes of 
Cython. D has considerable advantages over C++ in conciseness and 
template facilities for achieving zero cost static polymorphism 
without descending into utter unreadability. Personally, I find 
myself still forced to write most of my non-Julia high 
performance code in C++ due to the available libraries and GPGPU 
support (especially CUDA), but in terms of language properties 
I'd much rather be writing D.