I wonder if the Julia syntax changes between versions. I have been using the online tutorial “Think Julia” but the constructs used in the ebook does not match the Julia 1.9.0 version’s REPL that I am using. Would hope that syntax changes do not happen within minor upgrades, and should only occur on major changes such as version 1 going into version 2.
All of the syntax from Julia 1.0.0 should still work in Julia 1.9.0. We follow semantic versioning. We may have added some aliases since then so that Array{Int,2} is now displayed as Matrix{Int}, but either name is valid.
Could you be more specific about what issues you are having at the moment?
8 Likes
I will run a few more examples to see if I have any issues. And I borrowed the book “Julia: Bit by Bit” from the library to do a bit more.
— Andrew Goh
1 Like
To be clear: Julia syntax does not change between minor versions. New syntax can be added, but old syntax cannot be removed. Any change that makes older code stop working requires a major version change.
If you find code with outdated syntax, it must be from version 0.x.
6 Likes
There can be package breaking changes, of course. Maybe that’s what happened to the OP.
6 Likes
Or more specifically, public parts of the syntax, functions, etc. do not change. If the examples use some internals they may break for different minor versions. But tutorials shouldn’t do that.
5 Likes
By the way, we do have a set of online learning materials:
I also recommend the help desk channels on Julia Slack and Zulip.
5 Likes
I can think of one minor (and probably pedantic) exception: the use of multiple semicolons starting with v.1.7, for array concatenation, means that earlier code that contained multiple semicolons (probably as a typo), which did not raise an error but were treated as a single semicolon, will behave differently in recent versions. There was one more like this, but I can’t remember it at the moment.
3 Likes
Yes, that is sort of pedantic. It’s the only example of changed meaning of syntax I recall (and the former meaning wasn’t useful). There have been some more “technically breaking” decisions, but I don’t recall if they were about syntax (what the syntax guarantee is about). The old meaning is kept in 1.6 LTS, so at least kept there (while no one should be relying on it, since its just buggy code), and I’ve not heard of any real-world problem rising out of this, i.e. no code working in 1.6 but not later (the opposite in not true, since there’s not backward compatibility, only forward claimed).
There’s also public API guarantee. And part of the public API has in some cases been experimental, e.g. for Threads. By not “most” (or all by now, I would like to know) of the thread API declared stable.
There’s no public part of syntax, or rather all of it is public. You have the (public) API in mind, strictly about semantics not syntax (see also SemVer).
Ran into this error:
@v1.9 pkg> add ThinkJulia
Updating registry at ‘C:\Users\HP…\General.toml’
ERROR: The following package names could not be resolved:
- ThinkJulia not found in project, manifest or registry).
Need to add in ThinkJulia before examples will run.
— Andrew Goh
Yes, that is sort of pedantic. It’s the only example of changed meaning of syntax I recall (and the former meaning wasn’t useful). There have been some more “technically breaking” decisions, but I don’t recall if they were about syntax (what the syntax guarantee is about). The old meaning is kept in 1.6 LTS, so at least kept there (while no one should be relying on it, since its just buggy code), and I’ve not heard of any real-world problem rising out of this, i.e. no code working in 1.6 but not later (the opposite in not true, since there’s not backward compatibility, only forward claimed).
There’s also public API guarantee. And pat of the public API has in some cases been experimental, e.g. for Threads. By not “most” (or all by now, I would like to know) of the thread API declared stable.
heliosdrm:
public parts of the syntax
There’s no public part of syntax, or rather all of it is public. You have the (public) API in mind, strictly about semantics not syntax (see also SemVer).
The online version of ThinkJulia says this:
If you’ve found a reference that says add ThinkJulia, please share, so it can be corrected. (This package isn’t registered in the Julia general registry.)
I haven’t read the book, but it probably assumes that you’re starting at the beginning, and remembering what you learn during the process of working through it. A tutorial that continually repeats the ‘setting-up’ code gets tedious to read… 
I thought you were asking if Threads were experimental, so I looked it up. I see you were however quoting me (in a non-obvious way), likely didn’t mean to quote me at all. So just delete that part of your post.
Anyway here are the docs, and most is no longer experimental, at least this:
https://docs.julialang.org/en/v1/base/multi-threading/
Threads.@threads [schedule] for … end
but it got me thinking, why use that prefix Threads. It’s probably an holdover from since Threads were actually experimental. Base is exported, but Base.Threads isn’t, so you are reasing in with that prefix. That’s the hint that you are doing something with an experimental API. I believe that using this as now documented will always work.
But there’s another way. You can use:
using Base.Threads
[..]
@threads [schedule] for ... end
For the loop that seems better. But using Base.Threads still seems like reaching in, and should using Threads or even it implicit?
At least some part’s af Julia are still experimental, and all of it should be documented, e.g. “ccall using a libuv threadpool (Experimental)” is.
First introduced here:
In version 0.5 about two years later, we released the
@threads formacro with “experimental” status