4.98 birds/GWh in the fossil fuel estimate comes from unrealized climate change expectations. They also only looked at two coal power plants for the remainder of the study.
The nuclear source bird death estimates are extrapolated from one bad weather incident over two nights from a single plant on the Florida coast.
This is not a serious or rigorous study. Is there anything more recent?
Swift actors seem to differentiate from other actor implementations (see Erlang) which have a decoupled message queue. Calling into a Swift actor may be non-blocking, but the result must still be await'd and from the actor's perspective all calls are sequential and synchronous.
By this token, actors seem to be the language-level implementation of a class where all methods are asynchronous, and also being protected by the same lock.
The novel feature seems to be cooperative scheduling amongst actors.
I spent a bit of time watching the sessions after this years WWDC. I’m primarily an Elixir developer but have wanted to try Swift for a while, so the introduction of Actors felt like a good point to jump in.
My enduring impression after learning Swift Actors is that a LOT of additional complexity is introduced because of reference types. The data inside an Elixir process is just that: data, but the possibility of the data in a Swift Actor being a reference to a class suddenly makes everything complicated.
Regardless of the technical achievement from a compiler perspective I found that Swift’s Actors didn’t map well to my understanding of them from Elixir/Erlang and that they weren’t a net positive for solving the kinds of problems actors are suited for. I’ll concede this is all very personal and subjective though.
My understanding is the primary role of Swift actors is to support safe global state in an async environment.
I plan to use actors enums for states in my next major app version release.
Or at least I was, until Apple decided to backdoor the iPhone in the absurd notion that it protects kids. Now I’m trying to figure out how to migrate off their platform entirely.
After having tried to follow the discussions on swift forums on concurrency and actors, i still couldn't make my mind on whether their design was "fancy" smart (aka : something subtle and brilliant, that few developpers will get their grasp on and lead to inscrutable concurrency bugs), or "stupid" smart (aka : take a complex problem and make it look simple).
Actors in systems like erlang seem to make concurrency simple, and the model seems to be easy to grasp.
On the contrary, a few code samples i've seen on swift forums made my mind twist trying to understand how the code was going to be executed..
The big difference AFAIK with Erlang (other than reference types) is that Swift's model is reentrant, while Erlang's is not.
This is why `await` is such an important keywords to litter around your code - anything can happen in between when you await and when you come back, including actor message processing. You could have another invocation against your actor instance happen in tandem.
This definitely increases the learning curve, but likely still saves time later when you are fighting various deadlock conditions.
that's exactly the part where i lost it. The code samples talking about reentrancy and its various quircks in some proposal discussions really made me wonder where the whole thing was going..
its seems to me having an async public interface with a sync internal implementation is the most straightforward architectural design for actors, but obviously they thought it was too limiting. Do you have any idea why ?
If an actor system is fully synchronous, it is much less efficient and can't be reentrant.
Actor implementations tend to be split on reentrancy. Having multiple paused in-flight invocations of the actor means that you need to have clearly understood suspension points (hence await keywords). Non-reentrant actors like in Erlang can deadlock if two actor instances are calling one another. Because of the deadlock and some inefficiency concerns, some actor systems allow you to decide reentrancy per-actor as well.
Because Swift concurrency is an upgrade on top of decades-old systems, I believe a certain amount of additional complexity was required whether it was built as reentrant or not.
Firefox (and every other 3rd party browser) internally uses the same web rendering engine as Safari. Rolling your own renderer + JS engine is not allowed.
> The next update to Swift Playgrounds is supposed to allow full iOS app development…
May or may not be pedantry, but it’s not allowing the UIKit APIs, only SwiftUI. Still possible to make a full app, but on top of the IDE features that it lacks from Xcode, it’s specifically shutting out important parts of current iOS app development in 2021.
That’s not to say there’s not good reasons for it too, but it’s worth pointing out.
FWIW, Swift Playgrounds currently allows apps to load any library–I would be surprised to see technical restrictions preventing the use of UIKit. App review might not like it, but other than that it doesn't seem like there would be much stopping it.
Castro annihilated the land-owning middle class in the first years of his premiership [1], using the same playbook as Lenin wrt the Kulaks after the October revolution [2]: do away with the financially and thus politically independent asap.
Cuba consistently required Soviet subsidies to survive through the end of the 20th century [3]. That's all gone now.
I don't see what's your point, that the US should invade Cuba against the will of their residents and incorporate it as the 52nd state so that eventually 50 years later the kids of the current generation may be favourable to it?
Now you're just shifting goal posts into absurdity and dodging the central point of the previous response, which isn't that the U.S should invade Cuba because of its awful, repressive, impoverishing government, but that despite all sorts of excuses for how Cuba was "saved" from U.S exploitation by the Castro regime, that regime still mismanaged it terribly in fundamental ways. Had the Cubans stuck to the sort of government that existed before Castro 8and it definitely was a corrupt, repressive government as well), they'd still have been better off by now due to evolving economic changes and entry into the wider open markets of the world.
More accurately, Cuba traded with the Soviet Union and received food in exchange for its exports. I don't think Cuba was ever fully self-sufficient in food before, either.
Other than that you are correct about land reform in Cuba.
> Under normal circumstances though, health and safety oriented regulatory bodies such as the FDA play an absolutely essential role in protecting us from bad actors.
Does it though? There's a perception that government agencies are impartial watchdogs, but this belies the reality that governments have agendas of their own. The FDA is so politically removed from the people it was created to ostensibly protect that there's now little incentive for it to relieve real suffering today. A brief example:
My brother and thousands of people suffer from type-1 diabetes. We have had the technology for years now to create an artificial pancreas, but FDA and EMA regulatory procedures have stopped any device from being sold. People are creating their own DIY systems because no commercial, professionally-developed, reasonably-priced alternative exists yet.
This isn't snake oil. There are solutions for many people's ailments available today. And the FDA is a massive giant standing in the way of people living healthier, unencumbered lives.
Treat people like adults. On the whole they're pretty good at figuring out what's best for themselves and taking care of each other.
The nuclear source bird death estimates are extrapolated from one bad weather incident over two nights from a single plant on the Florida coast.
This is not a serious or rigorous study. Is there anything more recent?