7 ms·

Julia 0.3 released

idunning 12y ago
For anyone curious about the packages available in Julia 0.3, please check out http://pkg.julialang.org/ http://pkg.julialang.org/. We hope to add keywords and such in the near-term to make package discovery easier. Until then you can check out some of the "organizations" (http://julialang.org/community/ http://julialang.org/community/) such as JuliaStats (http://juliastats.github.io/ http://juliastats.github.io/) and JuliaOpt (http://juliaopt.org http://juliaopt.org). Finally, we have a blog aggregator that you can follow at http://www.juliabloggers.com/ http://www.juliabloggers.com/ Julia 0.3 is a solid release and many Julia users have been using the master Github version for the past few months for production use, academic work, and just messing around quite happily. There are relatively few breaking changes from 0.2 to 0.3, with much better package support - so upgrade as soon as you can. Julia 0.4 is likely to be a more "unstable" release in the tick-tock style that Linux used to have. Already been some great new things merged in, many more to come. I'd recommend not using the master branch of Julia at this time, and instead stay on release-0.3 if you like to build from source.
- idunning 12y ago
  Sorry for self-reply, but ran out of edit time: a very valid concern about Julia is the lack of packages because it is new - a catch-22 situation that all new languages. This has been recognized by developers and Julia has now got some great inter-language interop packages and functionality, allowing it to harness a world of packages in other languages. * Very efficient interaction with C and Fortran libraries is a core Julia feature, with the ability to pass arrays and structs directly between C and Julia. Calling C: http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-code/ http://docs.julialang.org/en/latest/manual/calling-c-and-for... * Python libraries can be used through PyCall.jl, which is used most famously to call matplotlib (PyPlot.jl) but also other libraries like pandas (Pandas.jl). PyCall.jl: https://github.com/stevengj/PyCall.jl https://github.com/stevengj/PyCall.jl PyPlot.jl: https://github.com/stevengj/PyPlot.jl https://github.com/stevengj/PyPlot.jl Pandas.jl: https://github.com/malmaud/Pandas.jl https://github.com/malmaud/Pandas.jl * Java libraries can be used through JavaCall.jl, which is used in Taro.jl to call Apache Tika and Apache POI JavaCall.jl: https://github.com/aviks/JavaCall.jl https://github.com/aviks/JavaCall.jl Taro.jl: https://github.com/aviks/Taro.jl https://github.com/aviks/Taro.jl * R libraries can be called through Rif.jl Rif.jl: https://github.com/lgautier/Rif.jl https://github.com/lgautier/Rif.jl
  - pygy_ 12y ago
    It is still experimental, but the C++ FFI should also be mentioned: https://groups.google.com/forum/#!topic/julia-dev/4kUu2ieWZ9Q https://groups.google.com/forum/#!topic/julia-dev/4kUu2ieWZ9... Some more samples: https://github.com/Keno/Cxx.jl/tree/master/test https://github.com/Keno/Cxx.jl/tree/master/test
marcodena 12y ago
I'm curious. I would like to know if it is worth to learn a new language only for speed reasons or if it's better to hope in improvements in Python... What do you think? Anyway awesome! It's going well :))
- deleted 12y ago
  [deleted]
- leephillips 12y ago
  I wouldn't expect mainline Python to get significantly faster. You can get huge improvement in speed by using various libraries, alternative interpreters, and other strategies - but you'll always be going beyond "pure", standard Python. Julia is designed with numerical performance in mind, and gets impressive results out of the box. But, because of the aforementioned, that by itself would probably not be a compelling reason to learn a new language. Such reasons would be Julia's design, which may make it preferable to you once you've learned more about it. Read up on multiple dispatch, built-in networked computing, and array syntax. I find the design around multiple dispatch to be much more sensible than Python's object-oriented approach.
  - coldtea 12y ago
    >I wouldn't expect mainline Python to get significantly faster. Why not? JS did. And before you mention that it's the de facto language of the web, so of course had tons of commercial backing, well, PHP did too (with PHP7, but also with recent 3 releases really working on speed and less memory use). We have this Dropbox initiative too, and renewed talk about Python optimization. For Python it's an obvious shortcoming, with some low-hanging fruits available.
    - jurip 12y ago
      It's been an obvious shortcoming for over 20 years, though. Maybe it'll get better some day, but at this point it's probably best not to count on it.
    - StefanKarpinski 12y ago
tapia 12y ago
I gave julia a try some weeks ago, but it seems it has a big performance problem when importing libraries... it takes too much time. This release doesn't seem to solve this problem sadly :/
- johnmyleswhite 12y ago
  Resolving this issue is one of the main goals for the 0.4 release. There is already a way to get much better performance for frequently used packages, but it involves a level of tinkering that's prohibitive for most users.
  - tapia 12y ago
    I'm glad to hear this! I'll be waiting for it to give it another try.
tomrod 12y ago
Thanks for posting the release news!
beders 12y ago
Has anyone spotted a buildpack for Heroku?
Stubb 12y ago
Does redefining functions with dependencies in the REPL work with this release? How about deleting items from the symbol table?
- idunning 12y ago
  Is https://github.com/JuliaLang/julia/issues/265 https://github.com/JuliaLang/julia/issues/265 the issue you are referring to? If so, not fixed. Not sure about the second part, but `workspace()` was added in 0.3 (https://github.com/JuliaLang/julia/blob/release-0.3/NEWS.md https://github.com/JuliaLang/julia/blob/release-0.3/NEWS.md, https://github.com/JuliaLang/julia/issues/1195 https://github.com/JuliaLang/julia/issues/1195)
  - Stubb 12y ago
    Yeah, that's the issue that I'm referring to. Looks like workspace() wipes the whole slate clean. I was thinking along the lines of R's rm() that can target individual variables.
apl 12y ago
For fans of the Python numeric stack (NumPy, SciPy, pandas, etc.): if you ever want to give Julia a go, there's an excellent Julia-to-Python bridge called PyCall. https://github.com/stevengj/PyCall.jl https://github.com/stevengj/PyCall.jl It allowed me to incorporate Julia into my academic work without breaking a sweat.
thearn4 12y ago
Python is my usual go-to language for technical computing, bit Julia is a lot of fun! I'd be curious to hear more from folks who have made use of it in "production" (sort of a tricky label in scientific programmiong) code.
- oostevo 12y ago
  For what it's worth, I tried and failed to convert my team of scientists/programmers (heavy on the science; not so much on the programming) to Julia from MATLAB/IDL/C++ for a project we were kicking off ca. 1 year ago. It's a really, really nice language that I find more consistent and easier to grok than MATLAB, but the deciding factor was the lack of the equivalent of MATLB toolboxes with all of their pre-rolled code that made our development as fast as it was. Edit: I should have mentioned: the Julia add-on packages are multiplying quickly, and are starting to look mature! http://pkg.julialang.org/ http://pkg.julialang.org/ I'm looking forward to them overtaking Mathworks on this front too.
  - jordigh 12y ago
    Octave dev here, which packages are you looking for? I'm curious if it's as sophisticated as Simulink and Mupad, which are completely different programs that happen to be associated to Matlab, or if it's just the image package that we have almost all in Octave already. Where's the demand? Where is your demand? :-)
    - oostevo 12y ago
      This was at an organization that I don't work for anymore, and my recollection is a bit fuzzy. I think it was Computer Vision, Signal Processing, Wavelet, and Image Processing. There were also some convoluted, non-technical reasons that we went with MATLAB.
      - jordigh 12y ago
        Could you contact me at jordigh@octave.org for some follow-up questions?
roye 12y ago
When I last looked at Julia (as a candidate for writing a bioinfo. tool) it seemed a really appealing alternative to prototyping first in Python and then Cythonizing to gain speed, in that code would only have to be written once and no stitching together would be required. Ultimately, I decided against using it because it seemed packaging of binaries wasn't quite there yet (e.g., one would have to download Julia and then download my code to run it). Is this something that's likely to be addressed in 0.4? Was my understanding of the situation accurate?
- one-more-minute 12y ago
  Yeah, that's exactly right. Static compilation is a high priority though, so it will be possible eventually.
  - roye 12y ago
    Alright, thanks. I'll check in at the start of the next project :)
toleavetheman 12y ago
My favorite change in 0.3 isn't even in the changelog: Startup time has been massively improved. It used to take 5-10sec to start the REPL or run a test, now it's about 0.2sec.
- andrewflnr 12y ago
  Actually, that's the "system image caching" mentioned in item #1. :)

For anyone curious about the packages available in Julia 0.3, please check out http://pkg.julialang.org/ http://pkg.julialang.org/. We hope to add keywords and such in the near-term to make package discovery easier. Until then you can check out some of the "organizations" (http://julialang.org/community/ http://julialang.org/community/) such as JuliaStats (http://juliastats.github.io/ http://juliastats.github.io/) and JuliaOpt (http://juliaopt.org http://juliaopt.org). Finally, we have a blog aggregator that you can follow at http://www.juliabloggers.com/ http://www.juliabloggers.com/ Julia 0.3 is a solid release and many Julia users have been using the master Github version for the past few months for production use, academic work, and just messing around quite happily. There are relatively few breaking changes from 0.2 to 0.3, with much better package support - so upgrade as soon as you can. Julia 0.4 is likely to be a more "unstable" release in the tick-tock style that Linux used to have. Already been some great new things merged in, many more to come. I'd recommend not using the master branch of Julia at this time, and instead stay on release-0.3 if you like to build from source.

idunning 12y ago
Sorry for self-reply, but ran out of edit time: a very valid concern about Julia is the lack of packages because it is new - a catch-22 situation that all new languages. This has been recognized by developers and Julia has now got some great inter-language interop packages and functionality, allowing it to harness a world of packages in other languages. * Very efficient interaction with C and Fortran libraries is a core Julia feature, with the ability to pass arrays and structs directly between C and Julia. Calling C: http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-code/ http://docs.julialang.org/en/latest/manual/calling-c-and-for... * Python libraries can be used through PyCall.jl, which is used most famously to call matplotlib (PyPlot.jl) but also other libraries like pandas (Pandas.jl). PyCall.jl: https://github.com/stevengj/PyCall.jl https://github.com/stevengj/PyCall.jl PyPlot.jl: https://github.com/stevengj/PyPlot.jl https://github.com/stevengj/PyPlot.jl Pandas.jl: https://github.com/malmaud/Pandas.jl https://github.com/malmaud/Pandas.jl * Java libraries can be used through JavaCall.jl, which is used in Taro.jl to call Apache Tika and Apache POI JavaCall.jl: https://github.com/aviks/JavaCall.jl https://github.com/aviks/JavaCall.jl Taro.jl: https://github.com/aviks/Taro.jl https://github.com/aviks/Taro.jl * R libraries can be called through Rif.jl Rif.jl: https://github.com/lgautier/Rif.jl https://github.com/lgautier/Rif.jl
- pygy_ 12y ago
  It is still experimental, but the C++ FFI should also be mentioned: https://groups.google.com/forum/#!topic/julia-dev/4kUu2ieWZ9Q https://groups.google.com/forum/#!topic/julia-dev/4kUu2ieWZ9... Some more samples: https://github.com/Keno/Cxx.jl/tree/master/test https://github.com/Keno/Cxx.jl/tree/master/test

marcodena 12y ago

I'm curious. I would like to know if it is worth to learn a new language only for speed reasons or if it's better to hope in improvements in Python... What do you think? Anyway awesome! It's going well :))

deleted 12y ago
[deleted]
leephillips 12y ago
I wouldn't expect mainline Python to get significantly faster. You can get huge improvement in speed by using various libraries, alternative interpreters, and other strategies - but you'll always be going beyond "pure", standard Python. Julia is designed with numerical performance in mind, and gets impressive results out of the box. But, because of the aforementioned, that by itself would probably not be a compelling reason to learn a new language. Such reasons would be Julia's design, which may make it preferable to you once you've learned more about it. Read up on multiple dispatch, built-in networked computing, and array syntax. I find the design around multiple dispatch to be much more sensible than Python's object-oriented approach.
- coldtea 12y ago
  >I wouldn't expect mainline Python to get significantly faster. Why not? JS did. And before you mention that it's the de facto language of the web, so of course had tons of commercial backing, well, PHP did too (with PHP7, but also with recent 3 releases really working on speed and less memory use). We have this Dropbox initiative too, and renewed talk about Python optimization. For Python it's an obvious shortcoming, with some low-hanging fruits available.
  - jurip 12y ago
    It's been an obvious shortcoming for over 20 years, though. Maybe it'll get better some day, but at this point it's probably best not to count on it.
  - StefanKarpinski 12y ago

tapia 12y ago

I gave julia a try some weeks ago, but it seems it has a big performance problem when importing libraries... it takes too much time. This release doesn't seem to solve this problem sadly :/

johnmyleswhite 12y ago
Resolving this issue is one of the main goals for the 0.4 release. There is already a way to get much better performance for frequently used packages, but it involves a level of tinkering that's prohibitive for most users.
- tapia 12y ago
  I'm glad to hear this! I'll be waiting for it to give it another try.

tomrod 12y ago

Thanks for posting the release news!

beders 12y ago

Has anyone spotted a buildpack for Heroku?

Stubb 12y ago

Does redefining functions with dependencies in the REPL work with this release? How about deleting items from the symbol table?

idunning 12y ago
Is https://github.com/JuliaLang/julia/issues/265 https://github.com/JuliaLang/julia/issues/265 the issue you are referring to? If so, not fixed. Not sure about the second part, but `workspace()` was added in 0.3 (https://github.com/JuliaLang/julia/blob/release-0.3/NEWS.md https://github.com/JuliaLang/julia/blob/release-0.3/NEWS.md, https://github.com/JuliaLang/julia/issues/1195 https://github.com/JuliaLang/julia/issues/1195)
- Stubb 12y ago
  Yeah, that's the issue that I'm referring to. Looks like workspace() wipes the whole slate clean. I was thinking along the lines of R's rm() that can target individual variables.

apl 12y ago

For fans of the Python numeric stack (NumPy, SciPy, pandas, etc.): if you ever want to give Julia a go, there's an excellent Julia-to-Python bridge called PyCall. https://github.com/stevengj/PyCall.jl https://github.com/stevengj/PyCall.jl It allowed me to incorporate Julia into my academic work without breaking a sweat.

thearn4 12y ago

Python is my usual go-to language for technical computing, bit Julia is a lot of fun! I'd be curious to hear more from folks who have made use of it in "production" (sort of a tricky label in scientific programmiong) code.

oostevo 12y ago
For what it's worth, I tried and failed to convert my team of scientists/programmers (heavy on the science; not so much on the programming) to Julia from MATLAB/IDL/C++ for a project we were kicking off ca. 1 year ago. It's a really, really nice language that I find more consistent and easier to grok than MATLAB, but the deciding factor was the lack of the equivalent of MATLB toolboxes with all of their pre-rolled code that made our development as fast as it was. Edit: I should have mentioned: the Julia add-on packages are multiplying quickly, and are starting to look mature! http://pkg.julialang.org/ http://pkg.julialang.org/ I'm looking forward to them overtaking Mathworks on this front too.
- jordigh 12y ago
  Octave dev here, which packages are you looking for? I'm curious if it's as sophisticated as Simulink and Mupad, which are completely different programs that happen to be associated to Matlab, or if it's just the image package that we have almost all in Octave already. Where's the demand? Where is your demand? :-)
  - oostevo 12y ago
    This was at an organization that I don't work for anymore, and my recollection is a bit fuzzy. I think it was Computer Vision, Signal Processing, Wavelet, and Image Processing. There were also some convoluted, non-technical reasons that we went with MATLAB.
    - jordigh 12y ago
      Could you contact me at jordigh@octave.org for some follow-up questions?

roye 12y ago

When I last looked at Julia (as a candidate for writing a bioinfo. tool) it seemed a really appealing alternative to prototyping first in Python and then Cythonizing to gain speed, in that code would only have to be written once and no stitching together would be required. Ultimately, I decided against using it because it seemed packaging of binaries wasn't quite there yet (e.g., one would have to download Julia and then download my code to run it). Is this something that's likely to be addressed in 0.4? Was my understanding of the situation accurate?

one-more-minute 12y ago
Yeah, that's exactly right. Static compilation is a high priority though, so it will be possible eventually.
- roye 12y ago
  Alright, thanks. I'll check in at the start of the next project :)

toleavetheman 12y ago

My favorite change in 0.3 isn't even in the changelog: Startup time has been massively improved. It used to take 5-10sec to start the REPL or run a test, now it's about 0.2sec.

andrewflnr 12y ago
Actually, that's the "system image caching" mentioned in item #1. :)