180 karma · joined March 13, 2017
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.
I've been looking for software in that space, a thing that runs cronjobs, with ability to kick off adhoc runs from some UI, see what is running, and if possible parameterise the custom runs (i.e., run an ad-hoc report for a different client than usual cron does)
My other half on the other hand, has no such interests, and thinks that I'm wasting my life away, while sitting on the couch watching netflix.
In the end we went with Aerospike which actually while backed by NVMe, outperforms redis backed by memory. Aerospike in memory is completely absurd speeds and throughput. Sadly the setup is a bit weird and query model is a bit wonky but we worked around it. A bit sad on how expensive the enterprise version is.
There are large C# monoliths out there with 100+ projects per solution, where VS simply does not work (as in you can't open a solution), and Rider takes 30mins to load the solution, and then stops working over time (after 8 hours?), so your morning routine is to open the solution Rider and go grab a coffee.