3 ms·

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. Th

by 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.

by newen 8y ago

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.