When I read this, all I can think about is the enormous amount of man-hours people have put in to make Python the go-to for Julias target market.<p>As the author says, the biggest drawback is libraries, and that is (1 of) the big attraction(s) towards languages.<p>Nobody wants to have to switch between C, Python, Assembly, etc. to make their code faster, but even fewer people want to write bindings to underlying C code. This also goes exactly against what the author doesn't want to do, which is to yak-shave around the language to get things working.
This was in 2014. Here is a more recent perspective (from a different blogger who used Julia in production) <a href="https://blog.staffjoy.com/retro-on-the-julia-programming-language-7655121ea341" rel="nofollow">https://blog.staffjoy.com/retro-on-the-julia-programming-lan...</a>
I think it will all come down to web assembly. Why?<p>Python has blaze, numba, dynd and dask going for it. These all ameliorate (and exceed Julia in some respects) many of the disadvantages of python (including fast user defined types). Then there are the libraries that while some can be used in Julia, you will never get full reliability, ease of use and compatibility.<p>On the other hand, Julia has amazing metaprogramming and much cleaner scientific syntax.<p>I think it will come down to whether Python can compile to fast LLVM regular standard lib programs.<p>Once (if?) Julia can be run in the browser with web assembly (using ahead of time compilation to produce small binaries), python has no chance if it doesn't follow suit. Python has no advantage that can permanently match Julia's potential ability to run on mobile, front end web, back end etc all from one beautiful codebase.<p>What does HN think?
> Julia breaks down the second wall — the wall between your high-level code and native assembly [...] you can take a peek behind the curtain of any function into its LLVM Intermediate Representation as well as its generated assembly code — all within the REPL<p>While I agree with the author in "betting on Julia", I do not think inspecting LLVM IR or assembly of individual functions in the REPL is as useful as a feature as the author thinks, because it gives an inaccurate picture of what the actual output will be.<p>Peeking at the code at the level of functions means a non-inlined version of the function must be produced at the REPL, and anywhere else this function is used in your actual code, it will probably be inlined (the author's example certainly will) so it can be further optimized/eliminated by later passes. Furthermore, for a non-trivial function's dump, fundamental optimizations that increase code size (inlining, unrolling loops etc) would make the output confusing to compare with the Julia equivalents.<p>Thus, I imagine a lower optimization level is used to produce readable REPL dumps. For a performance minded person (the only type of person who would care about ASM/LLVM dumps at a REPL) even this is not helpful.
Language design is vital for a language that can evolve. If you build a language for "cowboys" with the immediately-useful functionality that you can see, but without the "language geeks" insisting on the underlying principles, you end up with a language like perl - one that can dominate a particular use case for a while, but will be virtually impossible to evolve, and ultimately fall out of favour as it's overtaken by languages with firmer foundations.<p>That's why I'm betting on the strongly-typed functional tradition - OCaml/Haskell/etc. These language already have the killer feature from this article: they can be (almost) as expressive as Python and (almost) as performant as (naive) C++. But they also have really solid design with a lot of thought put into it that will let them evolve to meet the needs of the future.
> For me, code is like a car. It's a means to an end. The "expressiveness" of a piece of code is about as important to me as the "expressiveness" of a catalytic converter.<p>Im a sculptor, but all I make is coffee cups and ashtrays so I dont need to worry about the minor details of things..... This is what abstraction gets us.
The founders of julia are geniuses. The only problem the language is facing is, marketing.<p>Juila is one of those great things that everyone should use, but are simply bot promoted enough.
All of Evan Miller's programming reviews are good. I'm pretty sure it's been posted on HN before, but I quite liked his take on Rust as well.
This review was really helpful to me when I was looking for more insight into Julia.
<a href="http://danluu.com/julialang/" rel="nofollow">http://danluu.com/julialang/</a>