Julia v0.7.0 Release Notes
github.comImportant 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.
Is the plan still that 0.7 and 1.0 are the same except for deprecations?
Essentially yes.
I don’t use Julia but those language changes would have me worried that existing code would start behaving differently because of parser changes.
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.
Also, Femtocleaner will give you a PR with most of the changes.
https://github.com/JuliaComputing/FemtoCleaner.jl
It's quite nice to have a bot give you an update PR!
That seems reasonable, and it’s what Django does as well I think. The change list doesn’t mention it hence my comment.
I’m not surprised that deprecation logic is harder than the new features.
> you'll want to upgrade /through/ versions 0.5 and 0.6 instead of skipping them.
god that sounds sooo painful
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.
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.
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.
I have investigated Julia for a while and am exactly holding off starting some major work until 1.0 is in.
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!
Wow, a bunch of nice features here, named tuples, function argument destructuring... Also a bunch of syntax/parsing cleanups, hopefully for the best.
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?
Wouldn't that just be a struct?
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.
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)
Types are first class in Julia.
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.
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.
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.
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.
That heading gives someone who doesn't already know, absolutely no clue what it is or why they should click on it.
If you feel that way and want to contribute, the thing to do is to spend 30 seconds with Google (if that) answering your own question, then posting a summary of what you've learned for other HN readers who may not have heard of Julia.
The thing NOT to do is get mad because people are talking about something that you personally have never heard of.
The thing to REALLY not do is to actually expend energy posting a public statement about how you're upset because people are talking about things that you personally have never heard of and can't be bothered to spend a few seconds learning about. No good will ever come of it, especially when you could have spent that same time and energy answering your own question.
I don't know if you thought you meant me, but I didn't at all get mad or upset, not in the slightest, (your capitals make it seem like you did though) no idea why you got that impression. Maybe I got downvoted so much because people thought I was. I just thought the title could have gotten a lot more clicks if more informative. Gee, the whole point was, I didn't know it was about the language called Julia. I needed a more informative title to decide whether to click. I thought I was contributing, being helpful to the author, giving free marketing focus group feedback, by letting people know that as an outsider, the title told me nothing. I've no idea why that's so hard for people to understand. I was told that for HN regulars, the title wasn't confusing, so I guess in future I won't comment in similar situations, no good comes of it.
edit: Well, I did end up learning quite a bit about Julia - which sounds awesome - and got the best answer I ever got on here, which it seems others benefited from too, so that was good. :-)
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/
> 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.
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?
When you write code in a C like fashion it can often get as fast or faster than C. Of course it has the disadvatnage of all jit languages that it will likely have slower startup. But when you crunch big chunks of data it should be able to compete with C.
Actually want to qualify this a bit. Nothing gets automatically fast by just picking a fast language. That Julia is close to C in performance mainly means it is possible to achieve this through optimization without too much effort. However you still need to have some idea of what makes something slow or fast in Julia.
Personally I find it very easy to optimize Julia code because you can quickly see how the JIT transforms an individual function and what you may need to change.
Ok thanks. Lately been using Cython with its near-C speed and Python convenience. Just quickly had a look at Julia wiki page, seems like a fast Python, is that fair?
Python doesn't have multiple dispatch though. It's central to making Julia's type system fast. I.e., it's not just loops that are fast, but also code that uses Julia-defined data structures are fast. Additionally, you can write generic code and have it automatically compile fast code for large classes of types. Also, the whole Base library is written in Julia, mostly generically, so this will be compatible with your user-defined data structures as well.
Then finally, the kicker is that Julia, especially on v0.7, doesn't optimize functions separately: it optimizes them together. It will inline small functions into others, perform interprocedural optimizations and utilize compilation-time constants, etc. Thus when the code is Julia all the way down, it can and will compile everything together to optimize it a lot more than functions compiled separately, giving a lot more performance benefits. When you add in the macros to turn off things like bounds checks and adding in explicit SIMD, you truly get to C-level of performance and many times beyond because your code is so architecturally and vertically optimized (it's like you put on the flags to say "compile code that only works for this current machine with this current codebase", and it can safely make this assumption because it's JITing).
Because of this, it goes much further than Cython, and this also makes the type system and multiple dispatch central to the language. So I would say at a surface level it's "fast Python" (or "more productive C", that's how I usually think of it). However, at a deeper level the type system is so central that larger software architectures will be different to accommodate this multiple dispatch style as opposed to OOP.
I don't any purpose for Julia, beyond being a language geek, but it surely looks like a kind a of Dylan's 2nd coming, regarding how everything is put together.
Loooking forward how it evolves.
Thank you! :-D Such a great answer, wish I could +100 that.
I have been interested to see how Apache Arrow has targeted SIMD enablement with data layout. Is there a sweet spot using Julia with Arrow?
This should be in julialang.org frontpage.
Superficially you could say that, but the design of Julia is such that it is much easier for you to grasp what is going on at the lower levels and the performance implications of the code you write.
Python is much more of a black box, performance wise.
Also something like Cython is radically different from Julia. Cython is compiled to C code. Julia is based on JIT so while you have an interactive session in the REPL, functions are continously compiled as you make them.
I've gotten Cython-like speeds for non-parallelized code in a gradient descent task. I haven't been able to achieve the same speed as parallelized Cython code in Julia using either pmap or @parallel though.
I wouldn't say it's a fast Python.
Edit: Grammar
You weren't doing the same thing. Julia's `pmap` and `@parallel` are multiprocessing. These will parallelize across multiple computers, like multiple nodes of a cluster. It has much larger scaling potential (it's more like MPI) but at the cost of a larger overhead (like MPI). It for example was used to achieve >1 petaflops in the Celeste.jl application on the Cori supercomputer.
Cython's parallelism is via OpenMP which is shared memory multithreading. Of course multithreading is faster, but it's restricted to a single computer. Julia does have multithreading as well via `Threads.@threads`. This is shared memory and restricted to a single computer just like Cython, and will have a lot lower overhead than `pmap` and `@parallel`. If you want to directly compare something to Cython's parallelism, this is what you should be looking at.
On a side note, it looks like Cython doesn't have any native multiprocessing or multinode parallelism that would be the direct comparison to `pmap` or `@parallel`.
Thanks! From the documentation and all the threads I searched in discourse, it was never clear to me that @parallel and pmap where aiming towards the direction you just described.
I did try Threads.@threads, but the overhead was way too high. I might look into it again soon.
Threads.@threads is still consider a bit experimental and there are a few performance pitfalls that one can stumble into. I talked about this for a bit in http://slides.com/valentinchuravy/julia-parallelism, but if you still have issues after reading that feel free to reach out on https://discourse.julialang.org and we will figure out what is going on.
Very technical presentation, but it contains nuggets of that I can't wait to try once I get home! Do you have a blog that lays this out in a way that is aimed at the general Julia programmer?
Working on it :) I will probably announce it on twitter (@vchuravy) once I managed to find time to finish it.
unfortunately slides.com is blocked at work....
The problem isn't overhead but that there's a performance bug that one can easily hit with multithreading right now, which is why it's labelled experimental. When that's fixed hopefully you'll be happy :). A function barrier fixes it, but it's a little nasty. This is probably the bug I want fixed most, but since it's not syntax breaking it's a slated for v1.x and not v1.0.
Ah, gotcha. Maybe it didn't initially say "Julia Lang"; it does now, perhaps thanks to your comment.
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
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." :-)
I guess the problem is with the name Julia, which is lovely but you have to specify that you mean the language—no-one ever mistakes what "C++" refers to.
I thought it was a random person's github account because Lang is a common Chinese/Asian name...
It is a far more common western name: https://en.wikipedia.org/wiki/Lang_(surname).
The Chinese Wikipedia entry on the most common form of 'Lang' is anemic in comparison: https://zh.wikipedia.org/wiki/%E9%83%8E%E5%A7%93
Well, they do got https://en.wikipedia.org/wiki/Lang_Lang
when you post a title with a version number next to a project name, people expect it's a new version. So unless your comment is about not describing what Julia is a bit more, suivi might be fair, I don't see the issue
I don't know what 'suivi' means. I was just saying, I didn't know what it means. If they're trying to attract new people to it, that title seems a bad choice to me. It seems only insiders understand it. Unfortunately "Julia Lang" sounds to me like a name. It was confusing. Just trying to help.
That style of posting is not uncommon on HN. Some of the recent examples with the exact same structure, from https://hn.algolia.com/?query=%22release%20notes%22&sort=byD... are: "GHC 8.4.1 Release Notes", "Gulp v4.0.0 release notes", "Go 1.10 Release Notes", "Cryptsetup 2.0.0 Release Notes", "MongoDB 3.6 RC release notes", "Android Studio 3.0 Release Notes", "Tmux 2.6 release notes", and "Django 2.0 release notes".
Did you understand what all of those meant? Probably not. I don't.
But your lack of understanding doesn't make it notable.
Don't know what all those things are, no, but I know what to expect. With this I had no idea but wished I did.
Not notable? Luckily it was just a HN comment not a wikipedia page. :-)
Right, but it sounds like you want things to be more predisgested for you than is typical for HN reader expectations, and stated in a way which sounds entitled.
That's no doubt why your comment was downvoted.
Tell me, what do you expect from "Go 1.10 Release Notes"? You'll notice that link it's even less informative than this link to "Julia v0.7.0 Release Notes".
For future reference, here's how to the information you wanted. First, go to the link, which you can see is to github. It uses the standard github layout. On the top is a hierarchical list of names showing "julia" / "NEWS.md". The "julia" is a hyperlink to the github project page.
Click on that and the top says "The Julia Language: A fresh approach to technical computing. https://julialang.org/". Lower down it says "Julia is a high-level, high-performance dynamic language for technical computing. The main homepage for Julia can be found at julialang.org." If that is not enough information for you, both URLs take you to the language page.
Figuring out what you wished for, from the information given, takes less time then writing your HN comment.
And much less time then it takes to pass on HN cultural norms to new accounts.
OMG why are people so blind and autistic about this. I thought I was helping, both the author and other people who came along. Just sounded entitled. Will try not to make that mistake again. Too many people here unable to take things in a non-autistic way. Ah sorry. You see yet again I have a lot to learn about supposed HN cultural norms. (Sorry, am fed up with people picking on me about this.)
edit: Ahhh hehe I just noticed the title is now "Julia v0.7.0 Release Notes"! When I commented yesterday it was "Julia Lang v0.7" I think. So I've been wondering why on earth the comments about 'Release Notes', and the late commenters must have been wondering why the earlier talk about 'Lang'. So.. there was confusion. That makes more sense of why people were getting weirder and weirder about this—false assumptions. I learnt something, hopefully the people lecturing me about not understanding how HN works learnt something too. Apologies not expected, but that would be lovely. p.s. Yes, the new title is much much better!
Please do not use "autistic" as a slur. That is unkind and uncalled for. Autism is a real disease.
The change means that the person who submitted the post was in error. HN guidelines call for using the original title, with a few exceptions.
The page's title when the posting was made was "Julia v0.7.0 Release Notes", which you can confirm from this snapshot of 4 days ago: https://github.com/JuliaLang/julia/blob/eb94b8c3d8e8ee2294ed... .
This suggests that you did not even click on the link to learn more about the project before complaining about the lack of context.
The practice I try to do in situations like this is not to complain about the problem, but to figure out the solution to my complaint, and post that. For example, you could have written: "The submitter used the wrong title. It should be 'Julia v0.7.0 Release Notes'. Julia is a programming language for technical computing. More at http://julialang.org/"
That would be helping. Complaining about such a basic topic is not helping.
I'm kind of curious about the "suivi", too :) I assume it was a typo, and not the French word for "followed" (from what Google tells me, anyway), since that didn't make any sense either.
suivi -> which (swype auto correct)