Though it is less visible than the changes in the blog post, I'm also happy about the possibility introduced in 1.8 of removing LLVM from the runtime to create a smaller Julia runtime.
Not to mention the new effect system, which allows for quite aggressive constant propagation and constant evaluation.
Then there are a few small things: The new `eachsplit` function, for example, or the ability to read a file line by line, backwards, the introduction of "lazy strings" that makes writing informative errors more performant and the ability to match regular expressions to error messages in tests.
The real big one is the latency reduction, though, and the promise that it brings in the future for caching native code - perhaps in v 1.10 or even 1.9
This one is a very big and exciting release. The `@assume_effects` system is quite nice and very useful. Typed global variables will be great, and having callsite inlining is a big boon. The package manager improvements are also very welcome.
What purpose do you see for typed global variables? I'm sure they'll be useful for interfacing with external ABIs, OS interfaces, or hardware; but I'm not sure the added complexity will be worth it in the end, as these use cases seem rare. For one, it'll now be more difficult for newbies to understand they shouldn't use global variables in packages unless absolutely necessary.
I see typed global variables as replacement for writing
const x = Ref{Int}(1)
and then mutating it as `x[] += 1`. With the type annotated globals, we'll be able to simply write
x::Int = 1
and rebind it as `x += 1`. Besides the syntactic advantage, this way is threadsafe by default whereas mutating a constant global `Ref` is not threadsafe.
> Mutable struct fields may now be annotated as const to prevent changing them after construction, providing for greater clarity and optimization ability of these objects
So will these be exactly like non-mutable structs?
No, it'd be a hybrid between a mutable and immutable struct. This allows you to control on a per-field basis whether the field is mutable or immutable.
Release is a process, not a single instant, so "hasn't been released yet" depends on which point in this process you like to call a "release". There is a non-rc release tag on github [1]. The binaries are not available for download (yet), so I assume that is your requirement for the "release", correct?
Not to mention the new effect system, which allows for quite aggressive constant propagation and constant evaluation.
Then there are a few small things: The new `eachsplit` function, for example, or the ability to read a file line by line, backwards, the introduction of "lazy strings" that makes writing informative errors more performant and the ability to match regular expressions to error messages in tests.
The real big one is the latency reduction, though, and the promise that it brings in the future for caching native code - perhaps in v 1.10 or even 1.9