Julians, of course! 
For some (many?) of us, a pleasant July might be spent by the pool or a beach, under an umbrella, with a cool drink, and a laptop programming Julia!
5 Likes
It’s like the old joke about Perl 6: It’ll be ready by Christmas (without specifying “of which year”).
Julia v1.0 will be ready by JuliaCon. 
2 Likes
What will come first: LaTeX3, Julia 1.0 or the end of One Piece?
6 Likes
Now, now! It seems to be coming along rather well, IMO (at least, judging by all the changes I have to adjust to on pretty much a daily basis!)
I am very glad it wasn’t rushed out in the state it was after the supposed feature freeze on Dec. 31st, but I do think it will be able to see the light of day by JuliaCon 2018! 
1 Like
Yup. I include a missing-feature slide when I give a talk about Julia. To show that things get done in the Julia world, I strike through the promised features that have been implemented since I last gave the talk.
7 Likes
Hi there. Just wondering how much closer we are for the alpha milestone.
another idea would be to release an 0.8 version that signals that it should be working, but should be slow.
the nightly 0.7 builds were supposed to be broken, primarily for package maintainers.
0.8 could pull it together, being supposedly user-space working (no longer deprecated stuff), but slow and not 1.0.
only useful if pulling a late 0.7 into an 0.8 is cheap and easy, and 1.0 is around the corner…
1 Like
https://github.com/JuliaLang/julia/milestone/4 should give you an idea.
1 Like
Last week there were 11 issues related on GitHub. Today 8, some of them WIP’s or PR’s.
1 Like
There is also:
1 Like
Could including Revise.jl as part of the ‘default’ user experience be one of these - there seem to be interest in this?
Moving things that require external (sometimes large) libraries out of base would probably be fairly easy,
even if (for now) the code was still actually in base but only exported in a stdlib package.
The three things that I see that would help slim down the binary dependencies of base are:
BigInt, BigFloat, and the PCRE2 / regex support code.
The PCRE2 support is already out of date (10.30 instead of 10.31), it only supports String, and it is not thread-safe.
I have already implemented a thread-safe PCRE2 library that supports a full set of Unicode, binary, and non-Unicode single-code unit string types, along with a regex library that works with it, and is compatible with the regex support in Base. Moving pcre.jl and regex.jl out of Base would make it simpler to have those updated.
BigInt and BigFloat are both very inefficient because of the impedance mis-match between the C library API (which wants mutable types, using pointers that have to be allocated and deallocated) and Julia wanting numbers to always be immutable values.
Note that DecFP Dec128 numbers are about 3x faster in many tests than using a BigFloat with 128 precision, whereas you might think that the binary floating point would be faster, but DecFP numbers are 32, 64, or 128 bit bitstypes, which is responsible for the performance advantage.
5 Likes
I kind of obsessively check the number of open issues for 1.0, and the list is now as short as I’ve ever seen it: 5! https://github.com/JuliaLang/julia/milestone/4
14 Likes
…no one enter another, please!!!
3 Likes
My understanding from what @StefanKarpinski was saying is that the major blocking issue here is the iteration protocol change and (what is probably taking most of the effort) the new optimizer needed to make this work. Presumably the existence or non-existence of other, unrelated issues won’t make this go any faster or slower.
Will Pkg3 be a part of v1.0/0.7?
Yes it is already in 0.7 (on master) as a standard library.
Will Pkg3 be the default package manager?
Yes.
6 Likes
3 Likes