After fighting crash after crash with pgcopydb v17 and v18 I decided to bite the bullet and write my own in Golang.

I picked Golang because most issues with pgcopydb were related to concurrency bugs and memory leaks. There is nothing in this tool that requires C, Golang is totally fine and comes with a good concurrency built-in and a garbage collector.

A few more notable improvements:

- I use binary format instead wal2json - Optional control plane with web interface - CDC replay runs concurrently (partition by fk)

I had a very similar story back pre-Go-v1, was frustrated trying to debug a C memory leak in concurrent code. Switched to Go in a few weeks, less code, no bugs in this realm, more features. I was hooked and have been a proud gopher since

At getstream.io we ended up running Github Actions on Hetzner. The end-result is 4x faster builds for 3x less $$$.

Running workers ourselves was the last resort, we tried everything else but it was impossible to get fast (and consistent) build times otherwise.

In a way we are now going to get charged for Github's poor execution on Actions.

How are you guys running it? Is it via RunsOn, Ubicloud? We just moved ours to Blacksmith since I still don't want to manage the worker ourselves yet. But with this change, we might be looking into cheaper, better alternatives if there's any.

> anyone can see what URLs you are visiting

this is not correct with HTTPS (query params are not part of the plain text)

ofc it depends where you would hire, for me (NL) its above 100x more efficient

I agree, only reason I read the project readme was to see the drop-in explainer.

Very misleading title

cc klaussilveira

Well, it says right there in the GitHub About section: "Drop-in replacement for E in the ELK stack".

searching for running shoes returns a mix of brands and shoe models

Plenty of engineers on the market can work professionally in C. Only a small amount of people can write Cobol (or is willing to given that is almost useless). That alone is a good reason to consider Cobol a legacy language and throw away a codebase written in Cobol.

Consider legacy: yes.

Throw away the codebase: no, until you have a well-working, battle-tested replacement. I mean, yes, it's possible to do, and you can even run e.g. Java under z/OS on the same in-house mainframe hardware because you can't trust the public cloud. But you still have to do the massive work of reverse-engineering the ancient, scantly documented Cobol codebase, write a modern replacement, cover a ton of corner cases, run in in prod as a shadow that does all the same work, and comparing the results with the load-bearing Cobol codebase, and switch over very carefully.

Depending on the size of your codebase, the complexity of your processes, the strength of your need for change, and the quality of your engineering org, the above may be a very costly process. Few managers are comfortable to approve such a large cost without a very clear return on this investment. Hence we'll see Cobol running for a few decades more.

> At Compose, every WebSocket message starts with a fixed 2-byte type prefix for categorizing messages.

some of the complexity is self-inflected by ignoring KISS principle

How would you make it simpler?

In my experience, only Swift has a generator that produces good-quality code. Ironically, it’s developed by Apple.

The list of supported commands looks quite impressive https://kvrocks.apache.org/docs/supported-commands#script-co...