5 ms·

In my modest experience the perfect Julia slogan would be: "fast as C, easy as python, but NEVER the two together" All the sentences: "When you’re writing va

In my modest experience the perfect Julia slogan would be: "fast as C, easy as python, but NEVER the two together" All the sentences: "When you’re writing various algorithms, you don’t necessarily want to think about whether you’re on a GPU, or whether you’re on a distributed computer. You don’t necessarily want to think about how you’ve implemented the specific data structure. What you want to do is talk about what you want to compute." sound nice. Except in practice, unless someone else bothered doing that for you, you have to do it yourself.

sgt101 6y ago
Yes - if you have a real problem Julia is the way to go. If you are just banging something out to prove a point or make a delivery then Python is often much easier. Ofc this is like Excel and Notebooks - I start doing things in Excel because I can sort out an answer in like 30seconds. Doing it in a notebook requires 5 minutes, or maybe a little longer. But... see me there, a week later after the feedback and next questions from the customer... now I am in Excel hell and I wish wish wish I had started out in a Notebook.
komuher 6y ago
This is my favourite comment about julia for like last few years +1 on that. Ecosystem is extremly poor outside very few niches and most of the Deep Learning stuff isn't even faster than python api (+C ofc.) so swaping is just usless if u dont have time to write your own GPU kernals for every new opertaion.
- jpsamaroo 6y ago
  At least for the GPU case, the ecosystem is slowing moving towards writing generic kernels that can be executed on both the CPU (multithreaded) and the GPU, without doing anything special in the kernel itself, via KernelAbstractions.jl. It's still got a little way to go, but already some larger codes are using it to great effect. Also, as a member of the JuliaGPU group, I know that AMD and Intel GPUs should be supported by KernelAbstractions within the next month or two, so a single generic kernel will be able to run unmodified on all major GPUs.
jakobnissen 6y ago
Underrated comment. Yeah, if you want C-like performance, you have to do some low-level considerations, that is unavoidable at some point. So the "speed of C, convenience of Python" is misleading. However, for many, many small tasks, today's compilers are smart enough that you can express your idea in a high-level language and the generated code will be maximally efficient. The real killer feature of Julia is that, where ever you can gain maximal performance with high-level syntax, you can just choose to do that. A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen.
- cricci16 6y ago
  "A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen." This I almost fully agree
- 6gvONxR4sf7o 6y ago
  That's still a massive selling point. In python, getting speed can be weird and counterintuitive. In C, a straightforward algorithm can be blazing fast. For example, finding the length of the longest word in a string, you can just iterate through the string keeping track of a few indices. In cases like that, where the obvious simple C function is incredibly faster than the same python, where does Julia fit in? Would that kind of naively written function be closer to C or Python?
  - ddragon 6y ago
    In general, if you code like Python (highly dynamic code with no consideration to performance) it will be closer to Python in speed, and if you code like C/Fortran (completely static, overspecified types) it should be closer to C in performance, the variance in performance in terms of naive implementations is pretty high. That means it's easy to get into Julia and start programming no matter your background, but idiomatic Julia (which it's not something you'll learn in a day) should be concise and high level like Python (and frequently more concise) and close to C in speed. For example, what other dynamic languages do like verbosely typing everything doesn't really work in Julia (the compiler already knows pretty much every type even without hints), what works is treating the variable as a polymorphic container instead of a dynamic container: you don't know yet what type the variable has (only the behaviour), but whatever it is you should avoid changing it if possible (what they call type stability). Which is kinda why it might not be obvious reading proper high performance Julia code, as it is not something you do to make it fast, but what you don't do (change a variable type, forcing the compiler to create a low performance dynamic box, plus other stuff like global variables).
ku-man 6y ago
This has been my experience as well. Julia's salespitch is somehow misleading. You would think those C-speeds like are there right of the bat when in reality you need lots of contortions and tricks to get them.
deleted 6y ago
[deleted]

sgt101 6y ago

Yes - if you have a real problem Julia is the way to go. If you are just banging something out to prove a point or make a delivery then Python is often much easier. Ofc this is like Excel and Notebooks - I start doing things in Excel because I can sort out an answer in like 30seconds. Doing it in a notebook requires 5 minutes, or maybe a little longer. But... see me there, a week later after the feedback and next questions from the customer... now I am in Excel hell and I wish wish wish I had started out in a Notebook.

komuher 6y ago

This is my favourite comment about julia for like last few years +1 on that. Ecosystem is extremly poor outside very few niches and most of the Deep Learning stuff isn't even faster than python api (+C ofc.) so swaping is just usless if u dont have time to write your own GPU kernals for every new opertaion.

jpsamaroo 6y ago
At least for the GPU case, the ecosystem is slowing moving towards writing generic kernels that can be executed on both the CPU (multithreaded) and the GPU, without doing anything special in the kernel itself, via KernelAbstractions.jl. It's still got a little way to go, but already some larger codes are using it to great effect. Also, as a member of the JuliaGPU group, I know that AMD and Intel GPUs should be supported by KernelAbstractions within the next month or two, so a single generic kernel will be able to run unmodified on all major GPUs.

jakobnissen 6y ago

Underrated comment. Yeah, if you want C-like performance, you have to do some low-level considerations, that is unavoidable at some point. So the "speed of C, convenience of Python" is misleading. However, for many, many small tasks, today's compilers are smart enough that you can express your idea in a high-level language and the generated code will be maximally efficient. The real killer feature of Julia is that, where ever you can gain maximal performance with high-level syntax, you can just choose to do that. A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen.

cricci16 6y ago
"A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen." This I almost fully agree
6gvONxR4sf7o 6y ago
That's still a massive selling point. In python, getting speed can be weird and counterintuitive. In C, a straightforward algorithm can be blazing fast. For example, finding the length of the longest word in a string, you can just iterate through the string keeping track of a few indices. In cases like that, where the obvious simple C function is incredibly faster than the same python, where does Julia fit in? Would that kind of naively written function be closer to C or Python?
- ddragon 6y ago
  In general, if you code like Python (highly dynamic code with no consideration to performance) it will be closer to Python in speed, and if you code like C/Fortran (completely static, overspecified types) it should be closer to C in performance, the variance in performance in terms of naive implementations is pretty high. That means it's easy to get into Julia and start programming no matter your background, but idiomatic Julia (which it's not something you'll learn in a day) should be concise and high level like Python (and frequently more concise) and close to C in speed. For example, what other dynamic languages do like verbosely typing everything doesn't really work in Julia (the compiler already knows pretty much every type even without hints), what works is treating the variable as a polymorphic container instead of a dynamic container: you don't know yet what type the variable has (only the behaviour), but whatever it is you should avoid changing it if possible (what they call type stability). Which is kinda why it might not be obvious reading proper high performance Julia code, as it is not something you do to make it fast, but what you don't do (change a variable type, forcing the compiler to create a low performance dynamic box, plus other stuff like global variables).

ku-man 6y ago

This has been my experience as well. Julia's salespitch is somehow misleading. You would think those C-speeds like are there right of the bat when in reality you need lots of contortions and tricks to get them.

deleted 6y ago

[deleted]