Live data from Hacker News

Giving up on Julia

zverovich.net

41–50 of 242 posts

Re: Giving up on Julia

#41
post #19

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =). The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd def…

One-based indexing is also used in Fortran, which seems to be used in a great deal of numerical computing even today. Additionally, BLAS/LAPACK is an important linear algebra library written in Fortan.

I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?

Re: Giving up on Julia

#42

For many users of Julia, long-running performance matters more than microbenchmarks. Having converted a naively written Python program to Julia (there was a huge amount of computation being done over a large search space), I experienced a massive speedup even against PyPy. My Python scripts ran for about 10 hours before I called it quits (.6% of the work had been completed). Converting to Julia allowed me to finish w…

What kind of computation were you running?

Re: Giving up on Julia

#43

For many users of Julia, long-running performance matters more than microbenchmarks. Having converted a naively written Python program to Julia (there was a huge amount of computation being done over a large search space), I experienced a massive speedup even against PyPy. My Python scripts ran for about 10 hours before I called it quits (.6% of the work had been completed). Converting to Julia allowed me to finish w…

Just how naively was the Python written? ~1600 hours vs. 4 hours of execution time sounds like some extremely naive starting code. Is it fair to even compare them?

Re: Giving up on Julia

#45

Earlier quoted context omitted.

Obviously static/strong typing is winning. Last man standing are JavaScript and Python, the former transforms into a compilation target (like Elm), the latter doing some kind of gradual typing (like mypy). I think dynamic typing has its place, but more in experimental design and prototyping than in bigger application development (big IMHO).

Why is strong/dynamic typing considered such a big deal?

Two main reasons:

1. You can detect very common errors (e.g. typos) at compile-time instead of maybe detecting them at run-time. This makes the code much much more reliable (or equivalently you don't need to do nearly as much testing).

2. Dynamic typing prevents IDEs from doing extremely useful things like real code completion and symbol renaming.

If you're thinking "but I edit Javascript with code completion" or "code completion isn't such a big deal" then it's probably because you've never used accurate code completion, e.g. Microsoft's Intellisense for C++, or pretty much an Java IDE.

Re: Giving up on Julia

#46
post #26

Earlier quoted context omitted.

Octave is much slower than MATLAB.

True, but if performance is your key concern, you shouldn't use either of them. Octave and MATLAB are great for prototyping matrix based numerical algorithms. And for this purpose I find Octave much more pleasant, since it is less nitpicky regarding its syntax. And once I have something that works and want to apply it to huge datasets, I usually rewrite my code in C++.

That's exactly why Julia was created - it's supposed to be like Matlab, but fast.

Re: Giving up on Julia

#47

Earlier quoted context omitted.

Why is strong/dynamic typing considered such a big deal?

Two main reasons: 1. You can detect very common errors (e.g. typos) at compile-time instead of maybe detecting them at run-time. This makes the code much much more reliable (or equivalently you don't need to do nearly as much testing). 2. Dynamic typing prevents IDEs from doing extremely useful things like real code completion and symbol renaming. If you're thinking "but I edit Javascript with code completion" or "co…

0. Performance. 3. Interface documentation.

Re: Giving up on Julia

#48

Earlier quoted context omitted.

Obviously static/strong typing is winning. Last man standing are JavaScript and Python, the former transforms into a compilation target (like Elm), the latter doing some kind of gradual typing (like mypy). I think dynamic typing has its place, but more in experimental design and prototyping than in bigger application development (big IMHO).

Why is strong/dynamic typing considered such a big deal?

It's totally not. You totally never see anyone talking about it, anywhere.

Re: Giving up on Julia

#49

Earlier quoted context omitted.

Obviously static/strong typing is winning. Last man standing are JavaScript and Python, the former transforms into a compilation target (like Elm), the latter doing some kind of gradual typing (like mypy). I think dynamic typing has its place, but more in experimental design and prototyping than in bigger application development (big IMHO).

Why is strong/dynamic typing considered such a big deal?

The way that I see it is that it's a factor that is very much in the front and center of how a developer usually uses the language and their preference tends to fall out of the mentality in how they're writing their code. A static-strongly typed language will pretty much always take more time to write, you have to be a bit more methodical in what you're writing because sometimes changing one thing means changing types in function signatures and variables in a few dozen different places in your code. On the other hand the dynamic-weakly typed languages you can definitely iterate faster, but that can mean that large projects can end up being less maintainable in the future because you don't usually have a type checker to tell you you're passing an array to a function that is expecting a map/object and you end up needing more unit tests and the like to know that your code isn't going to crash in production.

Neither approach is wrong, but most developers have (sometimes very strong) opinions on which is the right way to do it in various different cases.

Re: Giving up on Julia

#50
post #41
post #19

Earlier quoted context omitted.

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =). The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd def…

One-based indexing is also used in Fortran, which seems to be used in a great deal of numerical computing even today. Additionally, BLAS/LAPACK is an important linear algebra library written in Fortan. I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?

No less than Dykstra has weighed in on the numbering of arrays.

http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

Having worked with both, I'm inclined to prefer 0 based addressing in most cases. It's slightly less intuitive, but it generally leads to cleaner code.

Post reply on HN