It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:
fn foo(namedParam internalName: bool) { // use internalName here }
fn foo(unnamedParam: bool)
> Consequently, in the case of portable batteries included in products covered by Regulation (EU) 2023/1670, the removability and replaceability obligations set out in Annex II of that Regulation prevail over those set out in Regulation (EU) 2023/1542.
The ecodesign law (spare part but 1000 cycle exemption) pevails over the batteries law.
You are right that intraday went even more negative than day-ahead. But I disagree about the rest of your comment. A spread between day-ahead and intraday does not imply additional redispatch. Only some of it might have been countertrading by the grid operators.
Negative prices have no effect on grid stability. It just means that the day-ahead market was cleared below 0, i.e. for every consumer (buyer) there is a producer (seller) selling at this price. The market is still balanced with consumption==production.
Now, you can ask the question: Why are so many producers willing to sell below 0? That has to do with misplaced incentives. For older or home-installed renewables there is a feed-in tarrif which guarantees a fixed revenue at all times. So there is an incentive to sell even for negative market prices. Newer installations can't opt for the guaranteed revenue model with revenue during negative prices any more.
Redispatch follows afterwards, if the market result clashes with physics: The physical grid can't transport the power from producer to consumer. There was no unusual amount of redispatch during easter.
Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.
At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.
> This is currently being defined and is almost complete.
>> no signed stamp of approval from on high
> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
For DP adoption it's too late. They should push for USB4 / Thunderbolt 4 instead. We are in the phase where about every new laptop has USB4. Connecting your laptop/phone to a TV might be a selling point. I'd love that for hotel TVs.
The source and the sink need a HDCP-licence. Both devices have embbed keys that get exchanged to estabish a encrypted channel. Without the licence you can't get the required key material.
AFAIK, you can even sell HDMI devices without HDCP. Practically though, every entertainment device needs HDCP support.
That's a really subtle version of the deadlock described in withoutboats FuturesUnordered post [0]
When using “intra-task” concurrency, you really have to ensure that none of the futures are starving.
Spawning task should probably be the default. For timeouts use tokio::select! but make sure all pending futures are owned by it. I would never recommend FuturesUnordered unless you really test all edge-cases.
I'm also surprised how often the preemptive vs. cooperative angle gets ignored in favor of the stackful vs stackless debate.
If you choose a non-preemptive system, you naturally need yield points for cooperation. Those can either be explicit (await) or implicit (e.g. every function call). But you can get away with a minimal runtime and a stackless design.
Meanwhile, in a preemptive system you need a runtime that can interrupt other units of work. And it pushes you towards a stackful design.
All those decisions are downstream of the preemptive vs. cooperative.
In either case, you always need to be able to interface with CPU-heavy work. Either through preemption, or by isolating the CPU-heavy work.
Though, for my example, the storage location of the array metadata/fat pointer is not relevant.
In Rust you can hold references directly into the buffer backing the array (`&v[0]`).
My Java knowledge is quite rusty at this point. AFAIK, a `ArrayList<MyType>` in Java stores pointers to MyType in the buffer. So, when indexing into a ArrayList, you never hold references into the actual buffer. Instead you get a shared-pointer to the class data. It's the indirection of the array entry that saves you during reallocation of the buffer.
Also because Java is a GC'ed VM, it wont dealloc the elements references by the array, as long as there are other references to an element.
The equivalent in Rust is `Vec<Rc<MyType>>` where holding an `&Rc<MyType>` referencing into the vec's buffer is problematic during reallocation. But, cloning the Rc and holding on to it is perfectly fine.
The initial point of this thread was that you can have a Rust-like language where you can hold multiple mutating (aliasing) references and prevent use-after-free. This won't work. Without a GC or RC, you can use one reference to "rug-pull" the memory that is aliases by the other reference.
> ArrayList is a wrapper around an array, and so adding entries will not move the ArrayList object, just the (wrapped) private array.
That's also how Vec works in Rust. Vec is just (buf_ptr, capacity, len) where capacity is the allocated size of the buffer.
The problem still exists though.
```
let mut v = vec![1, 2 ,3];
let x: &i32 = &v[0];
v.push(4);
println!("First element {x}");
```
The `push` might realloc the array. Then, x points into invalid memory. This is caused by the projection: You can create a reference to a field (aka member) from a reference to the base object.
A language without realloc sounds painful. Any growing container would lead to stale data.
You could pose the same argument against any form of warranty. Why provide/require any warrant for anything if the company might go bankrupt?
Yeah, then it gets messy. That's what the legal system and insolvency procedures are for.
> You could require all games with online components to make their servers runnable by users from the outset
That's the strawman going around. You might not even have to provide EOL support for all online-components. Just use reasonable effort to make offline content playable. The law-making process hasn't even started and people already are arguing against the worst-case, least nuanced regulation possible.
The initiative is not even asking you to provide the full functionality of your online-components.
All you should have is a "reasonable effort" EOL plan that allows customers to continue using the parts that can work without the developers support. They even call out "Gran Turismo Sport" as a good example. Sony announced the EOL a year before, and stopped selling micro-transactions. Then they removed the online services while retaining offline support for add-ons and in-game items.
A reasonable EOL plan might be: We'll support the online matchmaking for 3 years. After that we retain the rights to shut down the services providing at least a one year notice. All in-game items and add-ons will be made downloadable for all players 6 months before shut-down. All offline game modes will remain playable using those items as before.
Assume your cycle detection D(TM, i) always outputs 1 when TM(i) doesn't halt (TM is the encoding of a turing machine and i is the input to TM). Otherwise, if TM(i) halts, D does NOT halt. [1]
We can construct a new turing machine F(TM) = D(TM, TM). That is: We ask D to detect a cycle when a TM receives its own encoding as an input. What is the output of F(F)?
F(F) = D(F, F) = 1 can only happen if your cycle detector detected a cycle in F(F) which we just saw terminates with 1. If F(F) doesn't halt, then your cycle detector claims that F(F) terminated, which it doesn't.
Therefore no such cycle detection can exist. It either has to bound the size of the input system or be non-exhaustive in its detection. The intuition here is: Assume the encoding of D has size N and D can check all encodings up to size N, then D must be able to dectect its own cycles. But the input to D(F, F) is size 2N (cause F is roughly the same size as D).
[1] If your original cycle detection outputs 0 if no cycle is present, then just wrap it in a TM that calls the original cycle detection and either returns on 1 or infinite loops on 0.
Just in case you haven't read it, I can recommend this excerpt from "They Thought They Were Free." [1] It describes this exact feeling of "maybe I'm just being dramatic" during the rise of the Nazis.
As someone who grew up next to a former concentration camp, the main takeaway when talking to survivors was: If you give the benefit of the doubt, you won't believe fascism has taken over until it's too late. You should talk to your friends and close ones and draw a line somewhere. Maybe it's once a US citizen gets send to El Salvador. Just something to agree on. Once this happens normal is over and we need to act. And organize locally don't stay on your own during these times.
In Europe. Still cleaner than the US, China, India, Japan, and the world avg:
https://ourworldindata.org/grapher/carbon-intensity-electric...
Coal and gas are down 50% compared to 10 years ago despite the shut-down. Nevertheless, shutting down the last few ones was bad.