Julia v1.8 Release Notes | Hacker News Reader

Julia v1.8 Release Notes

github.com

14 pointsextesy14 comments

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.

> Typed global variables will be great

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.

> this way is threadsafe by default

No? Concurrent updates of integers can be accomplished with atomics: https://docs.julialang.org/en/v1/manual/multi-threading/#Ato...

Love Julia

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

I get that, but my question is: if a type is mutable and I instantiate with const, will the exact same optimizations available?

this isn't about instantiating a struct, this is about specifying that the field of a struct is const.

Oh fields. Got it.

A mutable struct which labels all fields as const is an immutable struct. And yes it optimizes.

Just to clarify, 1.8 hasn't been released yet (currently at release candidate 4).

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?

[1] https://github.com/JuliaLang/julia/releases/tag/v1.8.0

Thanks for the clarification

Reply on news.ycombinator.com