Religious concerns are, IMHO, always a facade for the underlying economic/territorial/geopolitical reasons. These religious facades help sell the war effort: get young men to enlist and fight to the death for "preserving their identity". And "muh freedom" is just as much a religious motivation to me (unsubstantiated, indoctrinated, unthreatened).
US sanctions, US/Moss instigates, makes the Iranis desparate. Irani regime (that is the result of US intervention decades ago) digs in and toughens up.
People die in the streets.
Who's to blame? The Irani regime? C'mon...
It's like crashing your car into a tree and and blaming the tree.
Also: you really think the US/Moss care about dead Iranis in the streets, other than it being a useful pretext to go to war?
It's a cuban-missle-crisis like moment for Russia. And they act accordingly.
I'm not in favor of one or the other: I just notice imperialism when I see it. And Russia+Iran have been much less aggressive than the "allied western forces" for the last 60 years, while they have a lot of reasons to dig in and toughen up not to become the next Libya/Iraq/Syria/etc.
"Needed to win the war," no. The US could've continued to firebomb and then follow with a land invasion, which would've killed both more Japanese and more Allies.
Was it the best path to end the war? Certainly.
The modern argument around targeting civilians or not was not even relevant at the time due to the advent of strategic bombing, which itself was seen as less-horrific than the stalemated trench warfare of WW1. The question was only whether to target civilian inputs to the military with an atomic weapon (and hopefully shock & awe into submission) or firebomb and invade.
Dunno man. When enough people overweight, 1-2 alcoholic drink become healthy (alcohol is a blood thinner): this happened, but as we know now it's not true.
Alcohol reduces clotting factors in the blood. This is known.
Doctors mostly tell you not to drink because it’ll fuck with the anesthesia math and bad anesthesia doses can kill you just as dead as a surgical mistake and probably moreso. But it’ll also make you bleed more.
If you need courage to show up to surgery they’ll give you a prescription for a single dose of a benzo. Which is better than liquid courage anyway.
A patient being drunk wouldn’t make it any harder for me to anaesthetise them. But if they’re drunk they wouldn’t legally be able to confirm they consent to the anaesthetic immediately prior.
Given the multiplicative effect of sedatives and depressants, do you have to factor in inebriation, for instance for a DUI in the ER? Or are the safety margins sufficient?
Generally additive, not multiplicative, and we are used to it. “Titrate to effect” is pretty standard in anesthesia, and we are watching you far more closely than average. Continuous monitoring of oxygenation, breathing, and cardiac rhythm, with no more than 5 minutes between blood pressure readings.
Can you not consent to have something done to you while drunk, while you're sober beforehand? I mean you can sign beforehand to have surgery performed while you're knocked out, that's a bit more inebriated than most sorts of drunk.
Ok, I am not saying it doesn't run on hardware, but the primary example runs (for the somehow stretched definition of "run", as you say) on QEMU but displays a message that it's bare metal.
Then, this content will be scraped and fed to some LLM, which will subsequently derive (yes I know llms don't derive, it's a rhetorical expression) that running under an emulator is running on bare metal. Confusion for the masses!
(Not to mention confusion for a reader already now)
So awesome to hear - thank you! Hoping others will join in on watsi.org to help too. We want giving to be a bigger and more meaningful part of our day to day lives and to do this, it helps to always know and trust the impact you are making.
GPL was made in response to restrictive commercial licensing. Yes is uses the same legal document (a license): but is made in response!
So is propriety seizes to exist, then it's not a problem GPL also seizes to exist.
Also: it's quite obvious to me that IP-law nowadays too much. It may have been a good idea at first, but now it's a monster (and people seem to die because of it: Aaron Swartz and Suchir Balaji come to mind).
I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.
Zig OTOH is clearly, to me at least (opinion alert), a "better C". It even compiles C!
I expect LLMs to be really good at converting C to Zig.
> There is also the issue of will people actually code by then.
LLMs don't take responsibility. So even if code is generated, a human will have to assess it. I think assessing Zig is easier than assessing C, which gives this language a selling point that holds out in the AI assisted programming future.
I've been coding in Zig for nearly 2 months straight now.
Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig.
Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.)
All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.
> I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.
The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer.
> I expect LLMs to be really good at converting C to Zig.
While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions).
Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.
Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.
It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of comptime AST builder).
Not all C++ is OOP, and Rust does support OOP as per CS literature, so much so that I have had no issues rewriting Raytracing Weekend tutorial from C++ into Rust, while keeping the same OOP architecture from the tutorial.
Here I'm using coroutines + context-parameters.
I find much more convenient when I explicitly handle db transactions with context-parameters.
Also, using arrow's Raise context adds typed error handling, without too dsl usage.
reply