Stick your head in it and breathe. You'll know.

Sand too, even when dry. But OK, metaphors have limits.

Not only is that statement not true, as noted by others, it's also not at all relevant to what you're responding to.

Sticking your head into non-liquid substances can have the same outcome. It therefore is not a suitable method for detecting wetness.

I'm not talking about outcome, but of sensing. I also never wrote it was a suitable method. When did that become a requirement?

I kist thought it was interesting that there are receptors that can detect wetness, just not on the skin. It was a joke pointing that out.

Fuck.

There exist lots of non-wetting liquids in which humans cannot breathe.

Your lungs have sensors that can detect being coated by a liquid which invokes coughing. In that sense, you can detect wetness.

They detect being coated, no matter liquid or not. (Source: Parents who smoke. And don't tell me the crap they are inhaling is a liquid.)

Secondhand smoke does not feel the same as drowning.

Fog, clouds, steam, ice.

By that definition, a vacuum is wet.

Trying to beathing in a vacuum would not feel the same as breathing in a liquid.

What would feel different?

Im a vacuum you would not be choking.

I have the same opinion. C++ was my first programming language I used at work. I feel that I was relatively proficient with it, but it was around 2005 I think. Since then I've mostly used other languages. Right now I feel I can use C with ease, in fact I periodically use it. But C++? I don't even dare.

I guess it's fine if one specializes on C++ programming only. But when one needs to use different languages and C++ is used sporadically, I feel like it might be substantially harder than other languages.

The problem with C are the parts that C++ already provides an alternative, regarding bounds checking, generic code with preprocessor tricks or now that _Generic thingie, stronger typed enumerations, heap allocations without sizeof math, automatic resource cleanups.

So use a minimal approach to C++.

I would feel the opposite. I dare not write a program in C. The mentality of RAII and destructors for resource management is so ingrained that attempting to track resource use and lifetime in C would be nightmarish.

I'm using laptop with Ultra 7 268V. It already has RAM on chip. I think they call it "processor package". I don't think it's socketed, though.

Of course it is possible. Unless you're dealing with manufacturer who actively works against that, like Raspberry Pi.

I prefer to use int16/int32/int64 IDs for primary keys and UUIDv4 for "visible" keys. So database always uses integer fields to refer to other rows and web API uses UUID.

So you can't generate more than 1000 UUIDs per second without skewing timestamp portion? That's not a lot. Bulk imports often require a lot more inserts.

Reading that code there's a 48-bit counter used for each millisecond, so ~281 quadrillion UUIDs per second.

You probably can't use that for streaming. Moment of UUID generation and moment of transaction commit are different, so it's very possible that even if your code generates UUIDs strictly sequentially; the observable sequence from the database will not be always sequential. I've been bitten by this once when I've used serial IDs and I don't think that UUIDv7 is any different in that regard.

When I have enough time, I'm usually using 125-bit ID which I convert to 25 alphanumeric characters (something like [A-Z0-9] excluding [IO01]).

Standard UUID length is 36 characters. So you have identifiers 11 characters less and they're actually a tiny bit more readable and writeable if you decide to type them for some reason.

I guess they just bruteforce OTP by sending all combinations of four digits to the server and eventually one works.

> your computer can't run multiple programs at once (it's just running one at a time real fast)

Of course it can.

Give them a break, machines with multiple CPU cores have only been around for 40ish years!

This list is from back in the day pre-multi-core, multi-CPU computers