FFFXXX

I think you are quoting from https://learn.microsoft.com/en-us/dotnet/api/system.threadin...

"In C#, using the volatile modifier on a field guarantees that every access to that field is a volatile memory operation"

This makes it sound like you are right and the volatile keyword has the same behaviour as the Volatile class which explicitly says it has acquire-release ordering.

But that seems to contradict "The volatile keyword doesn't provide atomicity for operations other than assignment, doesn't prevent race conditions, and doesn't provide ordering guarantees for other memory operations." from the volatile keyword documentation?

The part about C# volatile accesses using release-acquire ordering seems to be wrong if I read the C# docs correctly.

"There is no guarantee of a single total ordering of volatile writes as seen from all threads of execution"

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Compare the average republican sentiment to this regarding the railway strike / paid sick days: https://www.ibew.org/media-center/Articles/23Daily/2306/2306...

I don't think you can simply hand-wave the differences between your two parties. There do seem to be substantially different outcomes for the people affected by these issues.

The 95% safe Rust Code does not use any auto-vectorization (https://cliffle.com/p/dangerust/5/nbody-5.rs)

Only the 100% Rust-safe implementation uses auto-vectorization and is at 0.73% of the RUNTIME of the C code. (https://cliffle.com/p/dangerust/6/#performance-evaluation)

No, the Rust code is at 97% of the RUNTIME of the C code (https://cliffle.com/p/dangerust/5/#evaluation) when keeping the manual vectorization.

One interesting usecase is that you can run a tauri app without any webview windows just as a system tray icon and only spawn a webview window when necessary.

This kind of makes it way more lightweight but only in some situations (obv. heavily depending on the functionality of the app).

Thats awesome, now I'm going to have to find a reason to use this for something ;)

Tiny nitpick: the #![allow()] generates a 'warning: unused attribute' warning for me.

If you change it to #![allow(unused_attributes)] it disables the warning for itself.

It possible to disable this plugin. I have it disabled.[1]

The linked YouTrack thread[2] in the article says so as well. It is just not possible to remove the plugin entirely from your device.

Regarding the plugin being enabled by default the official response by Jetbrains says [3]

  The AI Assistant plugin is enabled by default and menu items and tool windows are visible in the UI. However, AI Assistant functionality is NOT available by default, and NO requests are sent to the JetBrains AI Service unless ALL of the following conditions are met:
  
  - The user has explicitly consented to use the AI Assistant and is using the trial or has purchased the corresponding subscription.
  - The AI Assistant has not been disabled for a particular project.
  - In the case of a commercial IDE license, the AI Assistant has to have been enabled at the organizational level. We’d like to reiterate that for commercial IDE licenses, unless this is explicitly enabled by your organization’s administrators, AI Assistant will not be available.

I'm not saying this is perfect and this can obviously still be a problem on e.g work devices.

[1] https://imgur.com/ETyFlCZ

[2] https://youtrack.jetbrains.com/issue/LLM-1760/Can-not-remove...

[3] https://youtrack.jetbrains.com/issue/LLM-1760/Can-not-remove...