3 ms·

That's true, but it's because Julia looks like Python/Fortran/Matlab on the surface but it's a really unique language that you can't really learn in one day or

That's true, but it's because Julia looks like Python/Fortran/Matlab on the surface but it's a really unique language that you can't really learn in one day or two. Write Julia like Python and it will be slow (dynamic languages are slow after all), write Julia like Fortran and it will be fast (static languages are fast, but they are restrictive). And after you actually learn the language you can fairly easily write extremely dynamic code that is around 80% of the speed of C just following a few rules (only consts on global namespace, type stability, typing containers like struct, abusing multiple dispatch/parametric types and profiling the eventual inference failures). Being permissive lowers the barrier for non CS people, one of the main target of the language, to start using the language, especially in the REPL/Notebook, even if they are not the most effective at the language.

appleiigs 6y ago
This is a feature of Julia I like. I write in my pythonic way, slow but good enough. Then I tune it when I really need the speed. As you and others mentioned, there's only a few things to do to get most of the way - put things in functions, type stability, optimize array allocations. Also more here: https://docs.julialang.org/en/v1/manual/performance-tips/ https://docs.julialang.org/en/v1/manual/performance-tips/
- eigenspace 6y ago
  It's important to emphasize that while this may sound like what Python people do with Numba or Cython, it's actually quite different because whether or not you write "slow julia code" or write "fast julia code", it's all seen by the same compiler. A highly tuned kernel function can be inlined into a not so finely tuned outer function and vice versa, our metaprogramming tools see both functions the same, etc.
  - ddragon 6y ago
    Plus high performance Julia code (at the 80% of C range, maybe not at the 100% range where micro-optimizations start to happen) isn't any less readable than low performance Julia code. A common misconception is that annotating every type and making it more imperative and C-like makes code faster, but as long as you internalized what makes code slow, making fast code is surprisingly just as concise as it would be in Python without any type annotation. But since fast and slow code are so similar, and both give the same ultimate result, it becomes less obvious for someone who is reading someone's code to see what was made to make it fast (even if it's easy to see what the code does because of it's high level nature). I think that's something that could improve over time with better tooling, using the meta-capabilities of the language to create linters and compiler suggestions that guide the users into making the small changes in the code that makes the most difference.

appleiigs 6y ago

This is a feature of Julia I like. I write in my pythonic way, slow but good enough. Then I tune it when I really need the speed. As you and others mentioned, there's only a few things to do to get most of the way - put things in functions, type stability, optimize array allocations. Also more here: https://docs.julialang.org/en/v1/manual/performance-tips/ https://docs.julialang.org/en/v1/manual/performance-tips/

eigenspace 6y ago
It's important to emphasize that while this may sound like what Python people do with Numba or Cython, it's actually quite different because whether or not you write "slow julia code" or write "fast julia code", it's all seen by the same compiler. A highly tuned kernel function can be inlined into a not so finely tuned outer function and vice versa, our metaprogramming tools see both functions the same, etc.
- ddragon 6y ago
  Plus high performance Julia code (at the 80% of C range, maybe not at the 100% range where micro-optimizations start to happen) isn't any less readable than low performance Julia code. A common misconception is that annotating every type and making it more imperative and C-like makes code faster, but as long as you internalized what makes code slow, making fast code is surprisingly just as concise as it would be in Python without any type annotation. But since fast and slow code are so similar, and both give the same ultimate result, it becomes less obvious for someone who is reading someone's code to see what was made to make it fast (even if it's easy to see what the code does because of it's high level nature). I think that's something that could improve over time with better tooling, using the meta-capabilities of the language to create linters and compiler suggestions that guide the users into making the small changes in the code that makes the most difference.