5 ms·

Julia v0.7.0 Release Notes

207 points by kmisiunas 9y ago

wallnuss 9y ago
Important to note that the 0.7 release is not quite done yet and we are polishing it. So there is no official release candidate yet.
- Certhas 9y ago
  Is the plan still that 0.7 and 1.0 are the same except for deprecations?
  - KenoFischer 9y ago
    Essentially yes.
- marmaduke 9y ago
  I don’t use Julia but those language changes would have me worried that existing code would start behaving differently because of parser changes.
  - clarkevans 9y ago
    The forthcoming Julia 0.7 release will provide warning messages for important (and breaking) changes that the community has been clamoring for. I don't think users are "worried" so much as they are planning to review and update their code accordingly. For example, I don't expect my existing 0.5 code to work without substantial revisions. This is the last window to improve the language proper before the 1.0 release, after which users like me will expect stability.
    - Certhas 9y ago
      I have investigated Julia for a while and am exactly holding off starting some major work until 1.0 is in.
      - gajomi 9y ago
        Just FYI as noted above, 0.7 is the harbinger of 1.0. It is functionally equivalent to 1.0 except deprecation warning, serving essentially as a migration version. So while not out yet, 1.0 is around the corner!
  - StefanKarpinski 9y ago
    We're very careful with changes and give thorough deprecation warnings. When you upgrade and the meaning of something that you're using is going to change in the following version, you will get a warning to change it now, with specific detail of the new spelling of that feature. So as long as you don't skip major versions, you're safe. Corollary: don't skip major versions. Even if you're upgrading from 0.4 to 0.7, you'll want to upgrade /through/ versions 0.5 and 0.6 instead of skipping them. Aside: implementing deprecations is often harder than implementing new feature themselves. We put in the effort because it is absolutely critical that people's code never just silently change behavior. Syntax and variable scope deprecations are particularly hard to implement, but all of the changes in 0.7 do have deprecation warnings – some of them with absolutely crazy implementations that we're very excited to get to delete when we release 1.0.
    - ChrisRackauckas 9y ago
      Also, Femtocleaner will give you a PR with most of the changes. https://github.com/JuliaComputing/FemtoCleaner.jl https://github.com/JuliaComputing/FemtoCleaner.jl It's quite nice to have a bot give you an update PR!
    - arthurcolle 9y ago
      > you'll want to upgrade /through/ versions 0.5 and 0.6 instead of skipping them. god that sounds sooo painful
      - ChrisRackauckas 9y ago
        That's only if you haven't touched your code in 2 years or so, and is also just an issue with early adoption. There's a reason why Julia wasn't labelled v1.0 yet, but post-1.0 is where the syntax is stable.
      - StefanKarpinski 9y ago
        It's not so bad really – having done it a few of times on fairly large code bases. Upgrading a project for a new Julia version is very straightforward: change the julia version, run your tests, and making any changes that warnings tell you to make. It's about as difficult as fixing compiler warnings in C – it's tedious but not hard. Keep in mind that in the future this statement would be something like: if you have code that was written for Julia 1.x and want to upgrade to Julia 3.x, then you should upgrade through Julia 2 instead of just skipping it. This does not seem terribly unreasonable.
rattray 9y ago
Wow, a bunch of nice features here, named tuples, function argument destructuring... Also a bunch of syntax/parsing cleanups, hopefully for the best.
- karmakaze 9y ago
  When I first used named tuples in Swift I thought they'd be so great, no more _1 _2 or whatever. After using them a while, it gets a bit tiring and litters with repeated type info. A type alias for a named tuple would help with that. Any others have similar experiences? Or would they play out differently in Julia?
  - dnautics 9y ago
    Types are first class in Julia.
  - AboutTheWhisles 9y ago
    Wouldn't that just be a struct?
    - karmakaze 9y ago
      Like an ad-hoc anonymously typed struct. Only the members are named, so each time the type is specified it is with the member names, hence just using a type name is preferred. If it is really just used at one or two call sites and not propagated all is well, but invariably things tend to expand in use.
      - wallnuss 9y ago
        I still don't quite see why you wouldn't just use a named struct, but you can create a alias for the NamedTuple type const MyAlias = NamedTuple{(:a, :b),Tuple{Int64,Int64}} MyAlias((2, 3)) # (a = 2, b = 3)
yesenadam 9y ago
That heading gives someone who doesn't already know, absolutely no clue what it is or why they should click on it.
- rattray 9y ago
  Hmm, I would guess that if somebody doesn't already know about the Julia language, this wouldn't be a very interesting page (which is fine). So this is a great title! In case you're curious, the website is https://julialang.org/ https://julialang.org/ > Julia is a high-level, high-performance dynamic programming language for numerical computing. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library.
  - yesenadam 9y ago
    Thanks. Well, I've heard of the language Julia, but didn't connect the title with it as it sounded like a person, robot or something.. Mm sounds good. Is it as fast as, say, C?
    - rattray 9y ago
      Ah, gotcha. Maybe it didn't initially say "Julia Lang"; it does now, perhaps thanks to your comment.
      - yesenadam 9y ago
        Hehe no. It said "Julia Lang v0.7" but I'm not insider enough to think of Julia the language when I read that. I wondered "Who is Julia Lang? Hmm must be some software?" etc
        doodpants 9y ago
        I'd think that most regular readers of Hacker News would naturally interpret "____ Lang" as referring to a programming language, but clearly there's some ambigutity. I would have the opposite problem; if a Hacker News item was titled "Fred Lang Has Died", my first thought would be: "I didn't even know there was a programming language called Fred. It must have died from obscurity." :-)
sixbrx 9y ago
Is there anything in Julia yet or planned, that would allow to specify that "implementations" (in some sense) of an abstract type must provide certain method implementations, which would be checked before any attempt to call a missing function at run time (such as just after all definitions have been read maybe)? I realize that this issue can be thorny under multiple dispatch so maybe no solution is practical. But this is one thing from traditional single-dispatch statically typed OO languages that I really miss.
- 3JPLW 9y ago
  Yes, there have been lots of discussions about this — typically referred to as "formal interfaces." This would be a 2.0 (or later) feature addition, and it's not yet certain how it would be approached. https://github.com/JuliaLang/julia/issues/6975 https://github.com/JuliaLang/julia/issues/6975 https://github.com/JuliaLang/julia/issues/5 https://github.com/JuliaLang/julia/issues/5
zmk_ 9y ago
Removing eye() in favour of a new construct is weird after all this time. It seems to me like v0.7 will break a lot of my current code.
- nalimilan 9y ago
  Existing code won't break as a deprecation is in place. And the replacement is very simple: Matrix(I, m, n), Matrix{Float64}(I, m, n) or even just I depending on the use case.

207 points by kmisiunas 9y ago

Important to note that the 0.7 release is not quite done yet and we are polishing it. So there is no official release candidate yet.

Certhas 9y ago
Is the plan still that 0.7 and 1.0 are the same except for deprecations?
- KenoFischer 9y ago
  Essentially yes.
marmaduke 9y ago
I don’t use Julia but those language changes would have me worried that existing code would start behaving differently because of parser changes.
- clarkevans 9y ago
  The forthcoming Julia 0.7 release will provide warning messages for important (and breaking) changes that the community has been clamoring for. I don't think users are "worried" so much as they are planning to review and update their code accordingly. For example, I don't expect my existing 0.5 code to work without substantial revisions. This is the last window to improve the language proper before the 1.0 release, after which users like me will expect stability.
  - Certhas 9y ago
    I have investigated Julia for a while and am exactly holding off starting some major work until 1.0 is in.
    - gajomi 9y ago
      Just FYI as noted above, 0.7 is the harbinger of 1.0. It is functionally equivalent to 1.0 except deprecation warning, serving essentially as a migration version. So while not out yet, 1.0 is around the corner!
- StefanKarpinski 9y ago
  We're very careful with changes and give thorough deprecation warnings. When you upgrade and the meaning of something that you're using is going to change in the following version, you will get a warning to change it now, with specific detail of the new spelling of that feature. So as long as you don't skip major versions, you're safe. Corollary: don't skip major versions. Even if you're upgrading from 0.4 to 0.7, you'll want to upgrade /through/ versions 0.5 and 0.6 instead of skipping them. Aside: implementing deprecations is often harder than implementing new feature themselves. We put in the effort because it is absolutely critical that people's code never just silently change behavior. Syntax and variable scope deprecations are particularly hard to implement, but all of the changes in 0.7 do have deprecation warnings – some of them with absolutely crazy implementations that we're very excited to get to delete when we release 1.0.
  - ChrisRackauckas 9y ago
    Also, Femtocleaner will give you a PR with most of the changes. https://github.com/JuliaComputing/FemtoCleaner.jl https://github.com/JuliaComputing/FemtoCleaner.jl It's quite nice to have a bot give you an update PR!
  - arthurcolle 9y ago
    > you'll want to upgrade /through/ versions 0.5 and 0.6 instead of skipping them. god that sounds sooo painful
    - ChrisRackauckas 9y ago
      That's only if you haven't touched your code in 2 years or so, and is also just an issue with early adoption. There's a reason why Julia wasn't labelled v1.0 yet, but post-1.0 is where the syntax is stable.
    - StefanKarpinski 9y ago
      It's not so bad really – having done it a few of times on fairly large code bases. Upgrading a project for a new Julia version is very straightforward: change the julia version, run your tests, and making any changes that warnings tell you to make. It's about as difficult as fixing compiler warnings in C – it's tedious but not hard. Keep in mind that in the future this statement would be something like: if you have code that was written for Julia 1.x and want to upgrade to Julia 3.x, then you should upgrade through Julia 2 instead of just skipping it. This does not seem terribly unreasonable.

rattray 9y ago

Wow, a bunch of nice features here, named tuples, function argument destructuring... Also a bunch of syntax/parsing cleanups, hopefully for the best.

karmakaze 9y ago
When I first used named tuples in Swift I thought they'd be so great, no more _1 _2 or whatever. After using them a while, it gets a bit tiring and litters with repeated type info. A type alias for a named tuple would help with that. Any others have similar experiences? Or would they play out differently in Julia?
- dnautics 9y ago
  Types are first class in Julia.
- AboutTheWhisles 9y ago
  Wouldn't that just be a struct?
  - karmakaze 9y ago
    Like an ad-hoc anonymously typed struct. Only the members are named, so each time the type is specified it is with the member names, hence just using a type name is preferred. If it is really just used at one or two call sites and not propagated all is well, but invariably things tend to expand in use.
    - wallnuss 9y ago
      I still don't quite see why you wouldn't just use a named struct, but you can create a alias for the NamedTuple type const MyAlias = NamedTuple{(:a, :b),Tuple{Int64,Int64}} MyAlias((2, 3)) # (a = 2, b = 3)

yesenadam 9y ago

That heading gives someone who doesn't already know, absolutely no clue what it is or why they should click on it.

rattray 9y ago
Hmm, I would guess that if somebody doesn't already know about the Julia language, this wouldn't be a very interesting page (which is fine). So this is a great title! In case you're curious, the website is https://julialang.org/ https://julialang.org/ > Julia is a high-level, high-performance dynamic programming language for numerical computing. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and an extensive mathematical function library.
- yesenadam 9y ago
  Thanks. Well, I've heard of the language Julia, but didn't connect the title with it as it sounded like a person, robot or something.. Mm sounds good. Is it as fast as, say, C?
  - rattray 9y ago
    Ah, gotcha. Maybe it didn't initially say "Julia Lang"; it does now, perhaps thanks to your comment.
    - yesenadam 9y ago
      Hehe no. It said "Julia Lang v0.7" but I'm not insider enough to think of Julia the language when I read that. I wondered "Who is Julia Lang? Hmm must be some software?" etc
      - doodpants 9y ago
        I'd think that most regular readers of Hacker News would naturally interpret "____ Lang" as referring to a programming language, but clearly there's some ambigutity. I would have the opposite problem; if a Hacker News item was titled "Fred Lang Has Died", my first thought would be: "I didn't even know there was a programming language called Fred. It must have died from obscurity." :-)

sixbrx 9y ago

Is there anything in Julia yet or planned, that would allow to specify that "implementations" (in some sense) of an abstract type must provide certain method implementations, which would be checked before any attempt to call a missing function at run time (such as just after all definitions have been read maybe)? I realize that this issue can be thorny under multiple dispatch so maybe no solution is practical. But this is one thing from traditional single-dispatch statically typed OO languages that I really miss.

3JPLW 9y ago
Yes, there have been lots of discussions about this — typically referred to as "formal interfaces." This would be a 2.0 (or later) feature addition, and it's not yet certain how it would be approached. https://github.com/JuliaLang/julia/issues/6975 https://github.com/JuliaLang/julia/issues/6975 https://github.com/JuliaLang/julia/issues/5 https://github.com/JuliaLang/julia/issues/5

zmk_ 9y ago

Removing eye() in favour of a new construct is weird after all this time. It seems to me like v0.7 will break a lot of my current code.

nalimilan 9y ago
Existing code won't break as a deprecation is in place. And the replacement is very simple: Matrix(I, m, n), Matrix{Float64}(I, m, n) or even just I depending on the use case.