To my knowledge, this is not the case for salmon. Whereas wild salmon is not safe to eat raw unless it has been frozen, this should not be necessary for farm-raised salmon of the highest quality.
It's a bit weird at first, but think the Chrome extension "Most Recent Used Tab Stack" works ok. It keeps the tabs sorted by moving the current tab to the left. That being said, I also prefer Firefox -- mainly because of its container extensions.
I'm sure many workers with dangerous jobs hate rules that only seem to make their work more difficult, especially if this seems to affect their income. Many of them presumably support Trump and others who want to dismantle these regulations, but this is unlikely to improve their situation. There's no reason why corporate HR would then suddenly decide to pay them more or prioritize a second truck crane.
Perhaps the workers themselves ought to be more involved in the processes for deciding new safety regulations, but the intuitions and common sense people have w.r.t. risk and safety can be quite inaccurate.
As pointed out by dang, the same (I think) tutorial was discussed in 2016 (https://news.ycombinator.com/item?id=10949288). I went through the first half of the tutorial in 2018, and I think some aspects of F* were genuinely new, but the development seems to have stopped. There is a need for a framework for program verification of real-life software by non-experts, but F* might not be it. In the latest article [1] of Project Everest one can read: "[...], it required several person-months to implement and verify a generic doubly-linked list library in F*, while it required only three hours to do so in Dafny."
[1] A Security Model and Fully Verified Implementation for the IETF QUIC Record Layer (Antoine Delignat-Lavaud, Cédric Fournet, Bryan Parno, Jonathan Protzenko, Tahina Ramananandro, Jay Bosamiya, Joseph Lallemand, Itsaka Rakotonirina, Yi Zhou) To Appear In The Proceedings of the 42nd IEEE Symposium on Security & Privacy 2021.
it required several person-months to implement and verify a generic doubly-linked list library in F*, while it required only three hours to do so in Dafny
This could be deceptive. Structures like linked-lists are fiendishly hard to implement in safe Rust too, but people are able to stay productive by (mostly) not implementing things like that themselves. In Rust's case the difficulty comes from ownership: anything involving complex reference graphs for the sake of traversal is going to be really gnarly to establish a single-ownership story for. I don't know about F*.
Minor correction: Norway was not formally a part of Sweden. The arrangement was a "personal union of the separate kingdoms of Sweden and Norway under a common monarch and common foreign policy", see https://en.wikipedia.org/wiki/Union_between_Sweden_and_Norwa....
As someone who should be in the target audience for Julia, I am sad to see that they have not switched to 0-based arrays before launching version 1.0. I consider this is an indication of a broken design process and thus a reason to stay away from the language. (The fact that ranges include both endpoints - rather than being half-open as in Python - is another such indication.)
> the fact that ranges include both endpoints - rather than being half-open as in Python - is another such indication
No, it's the same indication, twice. Once you've decided on 1-based, you almost definitely want to include both endpoints. Else you end up saying things like a[1:n+1] to indicate "the whole array please", which is annoying.
It is really interesting (and unfortunate) that you found it so hard to solve these issues within the framework of Rx(Java). Do you think they could be solved with minor adjustments to the framework, or is there a fundamental problem?
It’s possible that it could be solved, sure, but RxJava is complex and has so many layers of objects that it’s very difficult to trace what’s going on. As was mentioned above, the difference between hot and cold subscriptions and how hard it is (at least it was for me) to know what runs on what thread, all of these issues made it incredibly difficult to work with and I don’t see these things going away as they’re caused by fundamental design choices.
It would be easier, in my opinion, to design something that is like Rx and has a very similar api or feature set, but is architected to avoid these issues. We ended up building a system from queues which supported many of the operations Rx did (map, filter, join, merge, etc). I will say that our implementation wasn’t super efficient in terms of thread usage (it creates more threads than really necessary), but that could have been solved, it just wasn’t necessary for our needs.
Even though Rx/ReactiveX is not easy and simple, it is a big improvement over traditional event-driven programming. The ideas behind Rx are also more general than, say, the actor model. Unfortunately, it is also easy to make a mess with Rx, and when that happens, the debugger is of little help. I often end up writing stuff to the console.
I have not found hot vs cold observables to be a problem in Rx (for C# or Java; I have never used RxJS). In fact, I often use "semi-hot" observables, such as what you get from a BehaviorSubject, which initially gives every new subscriber the latest/current value.
To me, the fact that "the concept of time may be screwed" when using Rx, is a good thing because of the flexibility it gives. In particular, it can be very useful for testing; but I do struggle with Rx scheduling at times. At some point there will hopefully be more information available on how to use Rx effectively in complex, real-life scenarios. Maybe someone should write a book on Rx design patterns?
