I have been involved in the same projects furthering open access within Finnish universities as the corresponding author has, and I think the aim of the study is not make OA look bad, but to make it better by finding its shortcomings and then fixing them.
Exactly. We don't see OA as the problem. OA solves many issues that exist with traditional publishing and also makes it easier to preserve content in the first place. The problem lies with decreasing library budgets, rising subscription prices, and that preservation services often are not suitable for smaller OA journals.
LOCKSS provides a free option for publishers to join, but only accepts a limited number of OA publishers (https://www.lockss.org/use-lockss/publishers). A couple years ago the PKP launched their preservation service, which we're really excited about as it also offers free preservation (for OJS journals) and would help esp. those smaller journals that otherwise couldn't afford to enroll into preservation schemes.
This article is probably not aimed at Rust beginners and you shouldn't shy away from Rust, if you feel that you cannot possibly ever understand the lifetimes. The perspective of the article seems to stem from the author's own learning process, and might make sense only after you have some experience with the borrow checker and lifetimes. Most of the time everything might go smoothly, when you know the basic rules, but when the compiler gives you an error message, and you think it shouldn't have, then reading the article might give some insight on the problem.
And the Rust developers indeed deserve respect in my opinion too. They are trying to solve a hard problem and not taking the worse-is-better-option.
A good, but difficult question - it's difficult to quantize complexity. Both languages have aim that their users can have much as much control as possible, even if it entails complexity in the language desing.
Perhaps one answer could be, that much of Rust's complexity arises from the concepts of 'borrowing' and 'lifetimes' and how they are encoded in the language.
In C++, complexity much of the complexity arises from the copy/reference semantics, and the possibility of overriding standard behaviour. You need to have wider context to understand local code. So you need to understand how the C++ works on quite a low level and you might need to know more specifics on your C++ codebase than might be the case in Rust.
Generally, you need to know the operating systems and hardware work together. And then depending on the details, you might need to know C and assembly. In this case, you need to have good understanding on how modern processors do performance optimizations.
There probably isn't any good single resource for learning all this, but perhaps getting some good textbook on computer hardware architecture might be good next step after reading the "Code". Unfortunately I don't have any immediate suggestions on the current crop - I remember learning from William Stallings' books some 15-20 years back - not sure if they are the best choice nowadays.
The course "Computer Systems Architecture" at Queen's University uses "Computer Organization and Design: The Hardware/Software Interface" by Patterson and Hennessy. It's a 400-level course in the computer and electrical engineering department. I can recommend it. Most chapters in it have a "Real Stuff" section where they look at a real world CPU and compare it with the contents of the book to see how the theory actually ends up in practice.
In Poland, the ruling party (Party of Law and Justice) is a right-wing, populist party, which has tried to nominate/replace judges and to some extent, control the media. EU is has voiced concerns, but Poland's democratic processes still work, as evidenced in the recent recall of controversial abortion bill.
A Similar, but perhaps further evolved situation is in Hungary, where right-wing populists have held the power for quite a long. But even in Hungrary the rulings party's power is not absolute, at the moment, and you don't get thrown into jail for having wrong opinions.
Publishers probably cannot keep up with the current revenue levels, especially since the university library funding is constantly decreasing.
And besides Scihub, there are emerging institutional solutions to this problem, like research funders demanding that research paid with public funds must be publicly available, and universities setting up academic repositories where papers published elsewhere are available in open access form.
The first part is major changes, like the addition of GADTs in 3.12 -> 4.00.
The second number is also kinda major features, but not as large. Kinda similar to the Python release cycle. New features get introduced here, so things like multicore, flambda, effects, modular implicits would land here. It has a rather long release cycle but I heard there are plans to shorten the release cycle to something like roughly 6 months. These are 2 digits zero-padded for no real reason except maybe easier string sorting, so 4.03 would translate to 4.3 and 3.10 would be 3.10 and not 3.1.
Then the last digit is for patches and regression fixes that do not introduce new features.
