What about battery life? I bought a cheap Chinese MP3 player online and it works wonders. I use it with some regular wired headphones as well.

The battery life is pretty bad, it hardly lasts for 2-3 hours, but I somehow keep going to use it anyways

The internal version at least is heavily based on a global commit cloud.

If you give me your commit ID I can immediately print it on my workspace without you having to upload a formal change request.

That’s a feature of jj’s integration with Piper, and is not relevant outside of Google, as neither Piper nor that jj integration is available to anyone else.

That's not a jj feature, but a CitC feature. You can use it on hg workspaces or plain p4 workspaces.

But parent is right, you have to cast it anyways before reading from it, so might as well take the right type from the beginning.

Anything can be aliased by char, unsigned char, std::byte (as well as signed char in C), and usually uint8_t == unsigned char, thus by extension any valid void pointer can be cast to u8*.

Thus void*+size is usually the right type if ones only care for the memory representation of an object (cstring functions like memcpy, etc.)

Most likely one would have both overloads:

    void Hexdump(const void *p, size_t size); // (1)
    
    template<typename T>  // (2)
    inline void Hexdump(const T &obj) {
         return Hexdump(&obj, sizeof(T));
    }

With (2) being a wrapper to (1) that compilers will almost always inline, avoiding monomorphization costs (and (2) can also accept rvalues as argument).

(1) could also take std::span<const u8>, but (void*, size) is the more common idiom, more convenient to use and to read , as it is unambiguous which overload it is.

What about "go see an agent in person and use your fingerprint to prove it is you"?

That's still orders of magnitude more complexity for no real benefit. A migration from sqlite to postgres, if really required, is not that hard.

Yes, postgres should support a superset of SQLite functionality.

It's more like comparing assembly against the same program but with comments.

The pattern I notice more frequently at work now is:

"I'm working on X problem, I tried Y solution, AI thinks Z is wrong and W could be better, human opinion?"

This way there's never space for ambiguity, you showed you did your homework to the best of your extent, you already asked AI, all that's left is explicit request for human input.

It works quite well, and I appreciate it from both ends, as it saves everyone time.

This is obviously massively understating what an IDE does.

Do you never use language server features? Showing git blame on files? Doing regex search and replace? Doing multi-cursor editing? Run test?

If you genuinely never do, then that's ok, you don't need an IDE.

I do this all the time in Emacs, which runs on an old computer and handles it quickly. None of the tasks on this list require significant CPU resources.

I actually think these constraints _help_ the average project as well. By enforcing remote builds and execution you completely remove the need for something like docker. You also get cloud backups for your code automatically.

This is not a complete answer.

There are many open source projects that are developed in google3.

Good old capybara