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