ScottPJones uses it for string processing, and I have seen him comment on hackernews a few times. He's a big advocate for using it for things other than crunching numbers.
For scripts, the JIT overhead has gotten a lot better, and I think it will continue to improve. The strategy is saving more so that it doesn't have to get recompiled on launch.
That currently doesn't happen for packages. Which means while R and Python run much slower, they feel much snappier -- and will be much faster if you're just running a bunch of short scripts that wont amortize compilation.
So in the short term, I wouldn't use Julia for speed.
Multiple dispatch and powerful meta-programming are two other major highlights.
Multiple dispatch can make for much simpler, cleaner looking syntax, while often making it easier to remember too -- you only need one name per concept.
I briefly compared explicit SIMD vectorization in Julia and C here:
https://bayeswatch.org/2018/08/08/matrix-multiplication-kern...
were I to change the vector size, all that'd take in Julia is changing the number of elements, and it'll dispatch correctly. In C...
I don't have too much experience with object oriented programming which gives single dispatch, but I like the separation of functions from objects, and freedom of dispatching on any/all of the arguments.
If metaprogramming appeals to you, Julia makes that really easy compared to many other languages, with things like the `@eval` macro or `@generated` functions.
Any sort of repetitive pattern that isn't easily expressed in array operations can probably be handled pretty simply with metaprogramming. I gave an example of `@generated` in the blog post with matrix multiplication kernels, and a great example of `@eval` is: https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/...
In that link, ForwardDiff defines a gazillion function overloads for dual numbers for automatic differentiation.
Being an interactive language, plus the helpful macro `@macroexpand`, can make it easy to explore and figure out what's going on if you like playing with that sort of stuff.
I've heard loads of great things about Rust, too. Hope this helps decide if its worth looking at.
My examples were all still analysis-focused, but that's my experience.
I know it is not the default, but this package has no overhead over the default arrays according to recent benchmarks, and provides 0-indexed arrays:
https://github.com/JuliaArrays/OffsetArrays.jl
I confess, not being the default is a big thing. I've definitely had times where I thought "this would be easier with 0 indexed arrays", but it can then be harder to commit to adding a dependency and making that change vs just adding awkward looking "+1"s to all the indexes.
Coming from math/science, there's lots of times 1-indexing makes more sense / is more familiar. It's normal there to start counting from 1, so it can be easier to translate.
What do you have in mind for "outside the lines"? Gaming?
I've found the opposite. I'm a grad student, and my department assigned me to a computer with Windows 7.
I found it incredibly counter-intuitive and difficult to do things as simple as navigating to hidden directories or opening files therein, let alone anything even slightly further outside the lines of what my grandpa would use a computer for.
It felt like Windows deliberately obfuscated everything, hiding it behind smoke and mirrors for the sake of a "friendlier" facade. Which makes it all the more frustrating -- why would someone go out of their way to make my life more difficult?
The old saying that the "free" in "free software" is about freedom really hit home after my experiences. Linux never got in my way.
Reminds me of Brian Wansink, the Cornell professor who was a "world-renowned eating expert for over 25 years". When statisticians finally started looking at his lab's work, they noticed absolutely extraordinary amounts of errors. Like, 150-errors-in-just-4-papers level of extraordinary.
Your "3" is a Bayesian view. Specifically, from the Jaynesian school, which views probability as ignorance.
When we can't calculate which of those world's we're in, we express our remaining uncertainty with probability. The connection to subjective "beliefs" is recognizing that these probabilities are all in our own heads. Believing otherwise is the "mind projection fallacy"; in reality -- as you noted -- these things are certain from the god's eye view, and we fall somewhere in between that and total ignorance/entropy.
(I'm not a physicist, but I know some use the Many Worlds interpretation to apply this determinism even to quantum physics.)
E.T. Jaynes fleshes out his worldview in "Probability Theory: The Logic of Science", which was published posthumously in 2003.
I think Julia is a great example.
It also uses a "world-age" for function redefinitions, like another commenter suggested, to put the burden on redefinitions rather than than using runtime deoptimizations.
Before implementing the world age, they still didn't deoptimize. This meant that if "bar" called "foo", you call "bar" (causing it to compile), and redefine "foo", and then call "bar" again, it would still use the old foo method. That workaround (redefining "bar") was inconvenient, but unlike with deoptimizing, there was a workaround.
One comment on Julia though. It isn't like other JIT languages.
It's a lazy statically compiled language with a REPL. It uses LLVM (like Clang) to compile functions the first time they're called for a given set of input types (every function is like a C++ template by default).
This makes it easy to get C-level speed, because all it is is a different front end (with extensive type inference infrastructure/default "auto" for all types) to the same back end.
This is in constrast to an interpreted language, where code only gets compiled when hot (but then with the potential of profile-guided compilation, which could sometimes let them run even faster).
For scripts, the JIT overhead has gotten a lot better, and I think it will continue to improve. The strategy is saving more so that it doesn't have to get recompiled on launch. That currently doesn't happen for packages. Which means while R and Python run much slower, they feel much snappier -- and will be much faster if you're just running a bunch of short scripts that wont amortize compilation. So in the short term, I wouldn't use Julia for speed.
Multiple dispatch and powerful meta-programming are two other major highlights. Multiple dispatch can make for much simpler, cleaner looking syntax, while often making it easier to remember too -- you only need one name per concept. I briefly compared explicit SIMD vectorization in Julia and C here: https://bayeswatch.org/2018/08/08/matrix-multiplication-kern... were I to change the vector size, all that'd take in Julia is changing the number of elements, and it'll dispatch correctly. In C... I don't have too much experience with object oriented programming which gives single dispatch, but I like the separation of functions from objects, and freedom of dispatching on any/all of the arguments.
If metaprogramming appeals to you, Julia makes that really easy compared to many other languages, with things like the `@eval` macro or `@generated` functions. Any sort of repetitive pattern that isn't easily expressed in array operations can probably be handled pretty simply with metaprogramming. I gave an example of `@generated` in the blog post with matrix multiplication kernels, and a great example of `@eval` is: https://github.com/JuliaDiff/ForwardDiff.jl/blob/master/src/...
In that link, ForwardDiff defines a gazillion function overloads for dual numbers for automatic differentiation.
Being an interactive language, plus the helpful macro `@macroexpand`, can make it easy to explore and figure out what's going on if you like playing with that sort of stuff.
I've heard loads of great things about Rust, too. Hope this helps decide if its worth looking at. My examples were all still analysis-focused, but that's my experience.