Solid post. It also shows how powerful Julia is: allowing to operate at different levels of abstractions (down to seeing the assembly) using the same set of tools.
This is quite a different situation to traditional scientific computing.
No because of JIT compilation he would write code faster than Python by default. Now to truly rival optimized C++ code one has to do the tricks mentioned in this post like optimizing memory access, SIMD and maximizing instruction parallelism.
The key point is you are better off by default and can do some ugly stuff in the critical parts of the code while still using the same language.
But yeah if you're writing a loop or something else where the majority of work is actually being done by python itself, then it's going to typically be much much slower than the equivalent julia code.
This is not possible by definition, or is a misunderstanding of where and how performance occurs. If this is possible, then it is just as easy to perform worse if the beginner steps to either side of the happy path or if their problem doesn't fit the preconceived optimizations and is therefore no longer a "language" but some kind of "library". I think Julia should be seen as a library and not a language because a language is not comparable in this way that Julia likes to handwave away as magic.
Performance is on a spectrum, and usually a tradeoff against readability and conciseness. I think it IS true that Julia excels in that it gives, by far, the best expressibility/performance tradeoff.
Also, often, you really can get "free lunch" - there are many times where if you just do the obvious thing, Julia and its backend LLVM can optimise it to extremely efficient code. For a simple example, just summing an array with a for loop, for example.
That's a big hand wavy thing right there: "spending more time" is not a binary, and "just like any other language" ignores the massive differences there are in how much time you have to spend, what resources are available to you from the language, and how easy the ecosystem makes it.
A good example: there was recently a thread on the Julia discourse comparing Julia and Mojo. Julia used no external libraries (compared to 7 with Mojo) implemented a simpler, faster, and cleaner version of the Mojo code that was used to showcase how fast Mojo was: https://discourse.julialang.org/t/julia-mojo-mandelbrot-benc.... Then further still, folks were able to optimize for even more speed with various abstractions that let Julia take more advantage of the hardware.
That's the promise I think Julia makes and delivers on - you can write incredibly "fast" code simply and cleanly. Yes, you can have a higher standard of "fast" which requires a bit more advanced knowledge but I'd argue that Julia still offers the cleanest/simplest way to take advantage of those micro-optimizaitons.
That's not obfuscation, its faster code development, easier to read code, simpler maintainability.
Everything at a higher level than stack, manual heap, processor instruction, registers, explicit addressing and modes, direct I/O, and networking primitives level.
To have all that help, but still be able to drop down to the lowest level, in one consistent toolset is really nice for development and reliable sharing.
(Only a Julia fan at a distance! Not had the pleasure.)
I remember a quote that was like “Lisp programmers know the value of everything and the cost of nothing” in reference to that.
Obviously the developers of Lisp Machine operating systems could not ignore the cost of the operations. Especially since they developed ambitious software (an operating system and its application) on relatively slow machines (a Symbolics 3600 was as fast as a 1 MIPS DEC VAX 11/780).
GC was a kernel service, and there were low level primitives, including Assembly level Lisp forms.
Parenthesis all the way down to microcode.
The site is a staticly published version of a Pluto notebook, which uses modern web features to enable interactivity, reactivity, code syntax highlighting, etc. etc. Tradeoffs to enable those features but requires enabling your browser features. The underlying file that the notebook is based on is just a basic `.jl` file, so you could happily run the notebook from a Julia instance instead of the browser-based notebook environment.
Julia itself will be happy to run however you'd like it to of course.
I thought I was visiting a website.
The HN description actually referred to nicely layered technical abstractions. Which is why I had clicked the link. The description of Julia as being Lisp like. Thank you for taking an interest. I sill go see if a newer safaru works.