funny_falcon

I haven't seen Go's hit larger than 25% in our production.

Usually that means we have to keep average CPU load below 70%. (Since GC cames once in several minutes, it is usually not seen in per-minute averages)

That is ok for us, since Go significantly boosts development compared to stricter language.

It is "marketplace" thing, so we have enough money to spend on additional 50% servers compared to "extremely efficient No-GC" solutions.

It all depends.

TCP can't multiplex. HTTP/2 runs over TCP and does multiplexing.

WebSocket can't multiplex. Nothing prevents gRPC over WebSocket implement multiplexing itself.

DRAM interfaced Optane wouldn't consume NVMe lanes. It should be soldered same way as usual DRAM is soldered in most non-professional (but home or bussiness) notebooks this days.

For example: MacBook M1/M2 has fixed limiter RAM. But with Optane as swap it could be four-eight times larger without user notice on difference.

I mentioned consumers notebooks as main target for such optimization. A lot of "memory" for apps and real hibernation are main profits.

And disadvantages. LLVM is still hard to build precise GC with.

Largest profit Go gains from custom toolset - they able to buld precise GC.

Then they were able to build reliable preemptible scheduler, which would be hard as well if they use LLVM/GCC.

For consumers notebook, Optane could be fast swap drive. It's pity manufacturers didn't get this done. Swap should be just fast to make application switch fast enough. Optane could do it.

Optane was still cheaper than DRAM modules of same capacity. And were twice larger for same price.

Really, I dream of Optane as a "super-fast swap drive" that "extends" RAM (that is what some manufacturers do with NVMe this days). Then it will be ease to have notebook with 256G "RAM" with actual 16G of DRAM and 256G Optane swap. Most users will not notice any difference compared to actual 256G DRAM since Optane is fast enough to make application switch fast. At least my Google Chrome and Intellij Idea could live in peace in such setup, each eating many gigabytes "RAM" since I don't code and watch sites at the same microsecond.

Ocaml doesn't compile to C. Sometimes having translated C source is major gain.

I'm not Ocaml implementation expert, but I suppose Ocaml exception handling and garbage collector could be tricky to aware about when one extend or embed Ocaml.

To be honestly, my fellow did Ocaml embedding once. He made able to load natively-compiled plugins written in Ocaml into C based software. And it worked. I didn't dig into details, though. There was at least one bug regarding garbage collection (and it happens that I fixed it).

May be it is time for "coming out"? (Excuse me for the joke).

Really, perhaps your language is The Next One.

I'd really like to find "the low-level functional language" without "the fun stuff". Or at least it should have simple and boring subset that is usable without "the fun stuff".

Something like Caml Light - precursor to Ocaml - but with translation to C instead of bytecode, so it will be fast and will have comfortable integration with C libraries.

Typing allows reduce runtime type-checking. It allows to use faster specialized byte-code. It will help JIT to build faster code.

Well, our world is made of plastic. If bacteria will eat plastic, we would have to make other uneatable plastic.

Just tried with Canon TS6340 (which claimed to be supported). Doesn't work at all.

To be honestly, TS6340 is bad creature (as a scanner). I regret buying it.

Well, as a printer it is ok.

I believe using Optane as fast swap could be great way to increase RAM capacity. Not completely fair, but enough for most usages.

It is strange Apple didn't cooperate with Intel in this area.

I believe, this is result from overclocked system.

Yes, most probably it is begin of WW3.

No, it won't be nuclear war.

Except logical replication doesn't handle DDL yet. And 2 phase commit (prepared transactions) as well.

(Please, don't mention Redis it is not database, and its failover is for availability but no consistency)

You are right. Despite I love PostgreSQL, MongoDB is eons ahead in terms of replication and sharding.

Ruby requires to `require` somewhere in the project, not in the the file where actual usage is.

Why didn't you rewrite it in Crystal instead of Rust? Crystal preserves a lot of "look-and-feel" from ruby.

Yep, Crystal is not as mature as Rust even these days, but it is cute and useful.

But it is quite limited at the moment:

- connection is bound to backend process it were passed to, - backend process can perform only one transaction simultaneously, - therefore if backend process performs long transaction, all other connections on same backend process are waiting for.

Even pgbouncer in transaction mode performs better since it could switch incoming connections to different outgoing connections.

There will be no good builtin connection pooler until PostgreSQL adopts some kind of intra-process concurrency - threads or green-threads (preemptive coroutines). And I say, most likely it will never happen due to all extensions written for PostgreSQL.

afaik FoundationDB has something similar to "C++ with Actors".

Vacuum is just "most common" long transaction. Take reports: some of them take hours to build.

Dell XPS is marvelous. Keep it with hands and type on is so pleasureful. It is not superior in tech sense, but it is so cute.

Given concrete problem, looks like it is for all new notebooks and/or OS: I have same issue with HP ProBook 640G8 + Linux.

> Credit cards should never be linked across accounts thanks to PCI-DSS complince

Afaik, PCI-DSS doesn't prevent you to store cryptographic hashes of card. Therefore cards still could be linked with hashes.

Computer is too large. They definitely should license Apple M1 (M1x, M2) for this robot.

Consensus on eventual consistency is eventual.

strcpy - is a standard library issue, not language one. Most C projects creates their own "string handling" routines.

It is pity there is no alternative "standard library" with safer data struct and operations.

There are some attempts, for example, relatively wildly known klib: https://github.com/attractivechaos/klib

Afaik, Nginx used this hack for aio on FreeBSD many years. It is superrior to aio on Linux. That is why Netflix used nginx together with FreeBSD.

Now nginx could use threads for file io, and linux file performance became ok as well.

It's the dirties hack I've ever met.

Except I did something like this once in the past (but with zero byte instead of dot).