by sean_the_geek on 4/17/16, 9:21 PM with 109 comments
by mahmud on 4/18/16, 1:26 AM
CL-USER> (defun f (x) (* x x))
F
CL-USER> (f 2.0)
4.0
CL-USER> (disassemble 'f)
; disassembly for F
; Size: 37 bytes. Origin: #x1002B10BDC
; BDC: 498B4C2460 MOV RCX, [R12+96] ; thread.binding-stack-pointer
; no-arg-parsing entry point
; BE1: 48894DF8 MOV [RBP-8], RCX
; BE5: 488BD3 MOV RDX, RBX
; BE8: 488BFB MOV RDI, RBX
; BEB: 41BBB0020020 MOV R11D, 536871600 ; GENERIC-*
; BF1: 41FFD3 CALL R11
; BF4: 488B5DF0 MOV RBX, [RBP-16]
; BF8: 488BE5 MOV RSP, RBP
; BFB: F8 CLC
; BFC: 5D POP RBP
; BFD: C3 RET
; BFE: 0F0B10 BREAK 16 ; Invalid argument count trap
NIL
*by phantom_oracle on 4/17/16, 10:16 PM
As the author says, the biggest drawback is libraries, and that is (1 of) the big attraction(s) towards languages.
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.
by muktabh on 4/18/16, 3:49 AM
by tanlermin on 4/17/16, 11:08 PM
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.
On the other hand, Julia has amazing metaprogramming and much cleaner scientific syntax.
I think it will come down to whether Python can compile to fast LLVM regular standard lib programs.
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.
What does HN think?
by riscy on 4/17/16, 10:25 PM
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.
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.
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.
by lmm on 4/18/16, 7:56 AM
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.
by mynegation on 4/17/16, 10:38 PM
by ProAm on 4/17/16, 11:07 PM
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.
by max_ on 4/18/16, 6:31 AM
Juila is one of those great things that everyone should use, but are simply bot promoted enough.
by rdtsc on 4/17/16, 11:31 PM
by ones_and_zeros on 4/17/16, 10:06 PM
by tombert on 4/18/16, 1:56 AM
by bleair on 4/21/16, 3:18 AM
by vfclists on 4/18/16, 3:41 PM