vbezhenar

Water is not wet. Human lacks water sensor. All the sensors we have a temperature ones so we sense "wet" as a combination of temperature and visual information. Close your eyes, touch water of your skin temperature and you won't sense it. It's not wet.

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.

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.

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.

What's not to like? For example the fact that Go's threads and OS threads are two different things. For example the fact that I can't just use fork in Go. And many other things.

Go is good for writing web servers. For system software? Not so much. 90% of Unix is written with C. It's not that bad.

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

Of course it can.

C was and is a good choice for that kind of software. I don't understand the prevalence of Go in these tools.

What made Docker unique IMO is not the container technology itself. I used chroot 20 years ago and it worked just fine. Yes, no network namespaces; no process namespaces, but I don't even think these are that important.

What made Docker unique were there things:

1. Dockerfile concept. Building images layer by layer. Caching layers. Everything in a single file. It made possible to iterate on image quickly. It made possible to implement CI builds efficiently.

2. Docker network registry concept. Putting universal images onto a server and share them with the world.

3. Momentum. A lot of software that was traditionally complicated to deploy, suddenly appeared in docker servers. I remember how fascinated I was, when I could deploy wordpress website with tiny docker-compose. And how contained it was. I could just delete every trace of it from my host. I always felt uneasy installing various things onto my host and docker just solved that uneasiness.