lallysingh

Same name, but the company is quite different. What of that old Google is left now?

I think some basic versions of both motors and circuits are 3d printable now. I doubt good enough for driving a reprap, but perhaps later.

Best guess is that it's disabled for anything but track/trick stuff. There will be some cool videos eventually showing up with tricks people pull with this. I don't know what else it's for.

I can imagine the lateral thrusters helping it turn faster on the track. Although I wonder if the extra weight is going to net out positive for lap times.

But really, a few very rich people will buy the full-rocket version to impress their friends. They'll play with them on private property.

If you have the ads turned off, it's a lot nicer. I got that with some family bundle for more Drive space.

If there's some cost or availability question you have, AWS has some complicated bullshit to solve the problem for you. Check out reserved instances.

Imagine if all the energy spent whining on the purity of a system being insufficiently private or decentralized or somehow loyal to a fight against the man, was spent instead on actually improving those systems. They're open source.

IIRC IPFS was the latest in a long line of Distributed Content-Addressed systems that long predate crypto. AFAICT (obviously I wasn't paying much attention) they went crypto (FileCoin) to fund a base population of storage users to bootstrap its popularity.

But that didn't pan out.

Probably contention on databases.

This is essentially guaranteed. There are lots of useful smaller models that we should be able to run locally. Over time they'll be more and more capable and require less API usage.

You're getting downvoted because your argument is cosmetic, egotistical, and useless. Can you give an objective separation between design flaws and engineering details? One that has zero ambiguity: if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results? And would that distinction actually correlate to a historical analysis of programming languages' effects on software project success metrics?

No, because the entire distinction falls apart pretty quickly into "shit I like to discuss and care about" and "shit I don't care about and don't want to talk about."

Systems programming lives and dies by the details you want to ignore. The economics of large software production are mildly affected by language design. But weaknesses there are easily overcome with engineering practices and additional tooling. Almost every complaint about C++ safety I've ever heard hasn't been a problem for me for decades, because I know what libraries, practices, and tools solve those problems. But I've yet to work with another language - and I've programmed in a shit-ton of languages - that gets out of the way as well as C++ when I want to systems-program. Even C. C is strictly lower level, but its lack of abstraction facilities gets in the way more than some of the modern numerical-type-safety stuff of C++ does.

I've tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it.

I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator?

What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do.

Yes Rust and its libraries are getting better. But so's C++.

Unless you spend 5min googling and see that you can do zero retention via AWS Bedrock.

In a competitive environment, it's precisely that. An improvement in product A takes customers from B and C.

Apple and Steam have been successfully applying pressure for years. Who's willfully staying behind at this point?

All the development action went to the web. Dolphin's still pretty awesome.