4 ms·

Someone wake me up when Julia reaches 1.0

by cutler 8y ago

newen 8y ago
Wouldn't hold my breath even then. They decided to split a lot of functionality in Julia into a standard library, which they will keep changing indefinitely. There goes my hope of Julia having any API stability.
- KenoFischer 8y ago
  Alternatively, you may see this as a sign that we've thought carefully about which APIs are stable enough to be part of the long term stability guarantees of 1.0, and which APIs are not, making it more likely that we'll able to maintain those guarantees longer. Also, there nothing really special about code that used to be in base, but is now in stdlib other than historical accident. It so happened that we used to ship a git client as part of the language, but the HTTP client was a separate package, despite the latter probably being a lot more useful to users. Packages can and do have their own stability guarantees. With the language itself maturing, I imagine package authors will start taking advantage of this more.
  - newen 8y ago
    Yes I get your viewpoint about long term stability guarantees and feel it's valid to a certain degree. But I waiting for so many years for Julia 1.0 while expecting the entire language (base + stdlib) to have API stability for at least a few years, and hopefully many many years, like Fortran or at least Matlab. Also, I wish you guys would have some overarching philosophy w.r.t API stability in the stdlib. From looking at the github, it seems like the core developers are just delegating API change decisions in the standard library to new people who are not as familiar with the code base, without much discussion at all. I just don't think that is the way the stdlib should be managed.
- chappi42 8y ago
  With Pkg(3) you can lock library versions (including standard library). As the Julia API won't change in 1.x it won't break after upgrading. You should be fine. On the other hand, as far as I understand, 1.0 means that the API is stable but not that all 'luxury' features (debugger, Atom/VSC code integration, etc) are perfectly working and/or even ready. This will come in future (it needs a stable API).
  - tavert 8y ago
    stdlib modules aren't versioned separately from the language. That may happen in some 1.x release but it's not usable today.
    - chappi42 8y ago
      I took the info from this post: https://discourse.julialang.org/t/feedback-on-inconsistent-naming-of-types-for-julia-v1-0-release/7923/7 https://discourse.julialang.org/t/feedback-on-inconsistent-n.... And e.g. https://github.com/JuliaLang/julia/tree/master/stdlib/LinearAlgebra https://github.com/JuliaLang/julia/tree/master/stdlib/Linear... looks like a proper Pkg(3) package? Sorry for misinformation. Thought this would be for 1.0 already.
      - tavert 8y ago
        "proper package" in that it has a toml file and a uuid, but it can't be controlled by the package manager in terms of updating, handling installation, or pinning versions. The stdlib "packages" are an awkward in-between state that isn't usable the way a full package would be, the only thing it has forced people to do relative to being included in Base is now you need to do `using LinearAlgebra` to load it in downstream code. That might get fixed eventually so you can express that you depend on the LinearAlgebra 1.0 API to isolate yourself from stdlib breakage, but there's no way to do that today short of doing the work yourself to create a full versioned package with the same content.
chappi42 8y ago
Won't be a long sleep... The 1.0 beta is here.
montalbano 8y ago
No need to wait for 1.0. I'm happily getting my work done ~50x faster than python/numpy could offer (cython would be a massive headache for the fiddly numerical work I'm doing). Don't get me wrong I often still use Python + numpy for prototyping and non-scientific work but I switch to Julia for bigger numerical projects. Python was around for a long time before Scipy took off. MATLAB is expensive, proprietary and I do not enjoy coding in it. C, C++ and Fortran are all fantastic for some kinds of numerical work but for what I do, the speed of development and readability are far superior in Julia whilst still yielding excellent execution speed. edit: Regarding API stability mentioned in other comments, I'm not sure I agree as we are only just coming up to v1.0. However, even if the criticism is valid I'll still be developing numerical code faster in Julia with API changes than in C/C++/Fortran.

Someone wake me up when Julia reaches 1.0

by cutler 8y ago

Someone wake me up when Julia reaches 1.0

Wouldn't hold my breath even then. They decided to split a lot of functionality in Julia into a standard library, which they will keep changing indefinitely. There goes my hope of Julia having any API stability.

KenoFischer 8y ago
Alternatively, you may see this as a sign that we've thought carefully about which APIs are stable enough to be part of the long term stability guarantees of 1.0, and which APIs are not, making it more likely that we'll able to maintain those guarantees longer. Also, there nothing really special about code that used to be in base, but is now in stdlib other than historical accident. It so happened that we used to ship a git client as part of the language, but the HTTP client was a separate package, despite the latter probably being a lot more useful to users. Packages can and do have their own stability guarantees. With the language itself maturing, I imagine package authors will start taking advantage of this more.
- newen 8y ago
  Yes I get your viewpoint about long term stability guarantees and feel it's valid to a certain degree. But I waiting for so many years for Julia 1.0 while expecting the entire language (base + stdlib) to have API stability for at least a few years, and hopefully many many years, like Fortran or at least Matlab. Also, I wish you guys would have some overarching philosophy w.r.t API stability in the stdlib. From looking at the github, it seems like the core developers are just delegating API change decisions in the standard library to new people who are not as familiar with the code base, without much discussion at all. I just don't think that is the way the stdlib should be managed.
chappi42 8y ago
With Pkg(3) you can lock library versions (including standard library). As the Julia API won't change in 1.x it won't break after upgrading. You should be fine. On the other hand, as far as I understand, 1.0 means that the API is stable but not that all 'luxury' features (debugger, Atom/VSC code integration, etc) are perfectly working and/or even ready. This will come in future (it needs a stable API).
- tavert 8y ago
  stdlib modules aren't versioned separately from the language. That may happen in some 1.x release but it's not usable today.
  - chappi42 8y ago
    I took the info from this post: https://discourse.julialang.org/t/feedback-on-inconsistent-naming-of-types-for-julia-v1-0-release/7923/7 https://discourse.julialang.org/t/feedback-on-inconsistent-n.... And e.g. https://github.com/JuliaLang/julia/tree/master/stdlib/LinearAlgebra https://github.com/JuliaLang/julia/tree/master/stdlib/Linear... looks like a proper Pkg(3) package? Sorry for misinformation. Thought this would be for 1.0 already.
    - tavert 8y ago
      "proper package" in that it has a toml file and a uuid, but it can't be controlled by the package manager in terms of updating, handling installation, or pinning versions. The stdlib "packages" are an awkward in-between state that isn't usable the way a full package would be, the only thing it has forced people to do relative to being included in Base is now you need to do `using LinearAlgebra` to load it in downstream code. That might get fixed eventually so you can express that you depend on the LinearAlgebra 1.0 API to isolate yourself from stdlib breakage, but there's no way to do that today short of doing the work yourself to create a full versioned package with the same content.

chappi42 8y ago

Won't be a long sleep... The 1.0 beta is here.

montalbano 8y ago

No need to wait for 1.0. I'm happily getting my work done ~50x faster than python/numpy could offer (cython would be a massive headache for the fiddly numerical work I'm doing). Don't get me wrong I often still use Python + numpy for prototyping and non-scientific work but I switch to Julia for bigger numerical projects. Python was around for a long time before Scipy took off. MATLAB is expensive, proprietary and I do not enjoy coding in it. C, C++ and Fortran are all fantastic for some kinds of numerical work but for what I do, the speed of development and readability are far superior in Julia whilst still yielding excellent execution speed. edit: Regarding API stability mentioned in other comments, I'm not sure I agree as we are only just coming up to v1.0. However, even if the criticism is valid I'll still be developing numerical code faster in Julia with API changes than in C/C++/Fortran.