Seems like just tabs of claude code, plus markdown viewer which can just be another tab (with an editor) in a tabbed terminal?

My ide supports multiple terminal tabs, plus is a project aware code viewer, and has the ability to run the project.

What would I gain by using this?

Effectively, I'm a c++ novice, should I ever sprinkle move (under the constraints of the article)? Or will the compiler figure it out correctly for me and I can write my code without caring about this.

I.e. if I have

``` std::string a = "hi"; std::string b = "world"; return {a, b}; // std::pair ``` I always assumed the compiler figures out that it can move these things?

If not, why not? My ide tells me I should move, surely the compiler has more context to figure that out?

I want to use it in an OSS project, does that mean every drive by contributor needs a license?

Not sure they care about it running in an emulated environment.

They do effectively allocate an executable memory region, copy the machine code that was streamed into it, and jump to it.

I guess in this case the emulation is an actual vm, rather than "rewrite x86 instructions into arm" (don't know much about this subject, but assumed that was how rosetta worked)

Seems tsc itself requires node, but surely an api that takes a ts file as a string and returns a ts file as a string should be possible?

I feel that Rider is somehow better than CLion at c++, even after CLion Nova (Intellisense based on Resharper backend) became a thing.

One difference is that I write boost::asio in CLion, and just vanilla C++ in Rider, and before Nova it was completely unusable with async code, now it's usable with async code, but after a few days of running the editor I end up with fatal IDE errors for CLion, and never for Rider.

I always found it crazy how zmq gained any traction at all.

"Oh, I have a req/resp workload" - one of the sides restarts, goes out of rhythm with the state of the connection (whether its req or resp), unrecoverable errors.

Every system I've seen use zmq usually use it without these fancy patterns (use yeet messages in any order), and usually have some sort of "Is anybody there on the other side?" message to combat the fact there is no way to introspect connection state (otherwise your writes just block at the high water mark), at which point it would have been easier to just use tcp.

The whole thing to me reeks of mongo. It's great if you are completely incapable/incompetent of solving the problem properly.

It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day.

It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http calls in multiple retry handlers, and mobile operating systems have abstracted network connectivity to the point where it feels more like you are using zeromq rather than tcp.