Obviously speculating, but if you make a really good humanoid robot, it'll be easier to create purpose-specific ones, as the tech is basically explored far enough. Plus, in China they don't just build factories, but create infrastructure / supply chain around them. Also, maybe they are trying to scale out automation, e.g. the Xiaomi factory that has mo workers, maybe they're betting on a universal-ish automation machine.
I’m a developer, daily driving Linux, and prefer GUI apps. Would’ve used Sublime Text if clangd plugin worked. Hence stuck with Emacs. Open Code GUI sucks compared to their TUI though.
I have to say, I prefer dongles lately. There are many inexpensive hifi dongles that sound great with in-ears. They’re also USB class-compliant audio devices and work everywhere. Obviously a preference, but as other commenters have mentioned, 3.5 jacks do break, and I’ve personally broken plenty.
It's a Dell Pro Max GB10. I have two that I can bridge together to run larger models across the 256GB pool but I only bridge them when I am experimenting with larger models and they will run fine but at lower tk/s with really only marginal reasoning gains, so I tend to stick to medium models (122b) on one GB10 and I use the other to serve gen models for music, image and video gen.
In my experience, using chats merely as stack overflow replacement, e.g. for providing obscure API usage examples, is a huge time saver — otherwise I would’ve had to lurk around game engine sources, examples, comments, sometimes forum posts, etc. AI code reviews definitely help finding issues, especially when I work on something for more than a week and inevitably forgetting things.
This is my experience. It's a huge time saver for learning something that you would have had to previously Google or wade through multiple pages of documentation for, as long as you develop an intuition for when to fact-check it. It's a slightly less huge time saver for one-shotting simple functions/scripts ("write a function to download everything in a given time range from this paginated API and save it to files"), assuming you actually review what it outputs. But neither of those things are where most time is spent in software.
> It's a huge time saver for learning something that you would have had to previously Google or wade through multiple pages of documentation for, as long as you develop an intuition for when to fact-check it.
When you're learning something, wading through documentation is a lot more valuable than zeroing in on the one thing faster. It's an investment in the future.
You don't need to do this if you setup TDD. Over time, you develop confidence in the tests, and those ensure your code is solid. Linters/formatters ensure coding standards.
It's a shift, but once you make it, is when agentic development clicks.
TDD is fantastic. It's also insufficient on its own. Humans must verify code line-by-line - unless you're writing disposable code, which is fine! That has its place.
More and more, this is becoming an unreconcilable ideological difference in software development.
This is true but it's completely negated when someone wastes my time asking them to review their AI slop wall of code, or when it actually goes live and blows up production.
From what I understood, their critique of RAII is twofold: coupling of allocation and initialisation, and enforcement of deallocation. The ease of use of smart pointers makes it tempting to allocate/free of temporary structures even within one single function. Given enough number of such occurrences, it kills performance by a thousand cuts. Also I remember they mentioned it’s not necessary to free memory if you’re about to close your program, because the OS will take the memory back. Obviously you need to gracefully deinitialise some things, like audio or other devices, but that’s beyond the discussion.
As on some references, Ryan Fleury did an episode on Wookash podcast on RAD debugger showing ECS like approach.
IMO, their RAII critique is a but nuanced, but because of their personality the discourse often gets polarising.
Edit: the sibling comment just proved my last point.
most of that criticism only works on C++. rust does enforce RAII but uses stack allocation for locals by default instead of touching the heap so it skips the slow part.
on the other hand there are no constructors (just normal functions) so you cant initialize values in place, only stack allocate and return. i think rust needs to add in place init and change the rules from "always init at declaration site" to "must be initialized at first use" like kotlin.
the big missing piece is custom allocators that let you use something like a bump arena with the same convenience as system malloc. they already exist on nightly but nobody knows when they will land on stable.
honestly thats the biggest problem with rust, they come up with a lot of useful changes but then take ages to stabilize because the core team is overworked. they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.
there should be a stage between nightly and full release where feature is in stable toolchains behind a cfg flag and you get a warning if upstream crates use it. show commitment to shipping it in time but still make it clear that it can change (in minor incompatible ways) before release.
There are several libraries for doing arena allocation in Rust, e.g. bumpalo: https://crates.io/crates/bumpalo , see the documentation for examples (it's quite easy to use and fits the borrow checker very well). The comments in here regarding Rust are somewhat misleading; Rust doesn't require unstable/nightly features to do this sort of stuff. What's unstable in Rust right now is a standardized interface for generically working with allocators (see https://github.com/rust-lang/rust/pull/157428 for the most recent progress), including support for the containers provided by the stdlib.
I haven't written any serious Rust in a while, but I assume there is some kind of lifetime annotation involved. The "objects" allocated in the arena have to be explicitly given the same lifetime as the arena itself. I have no idea how that looks syntactically.
> honestly thats the biggest problem with rust, they come up with a lot of useful changes but then take ages to stabilize because the core team is overworked
On the contrary, that has been one of Rust's biggest strengths. My impression when reading through stdlib was that they got so many things right, and for that to happen, things need to be thought out properly.
Case in point, it'd be such a shame if they stabilized the allocator API, only for us to forever regret never getting the storage API [1] instead, or vice-versa, depending on which one turns out to be more pragmatic.
> they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.
And that's a good thing! Some people really dislike the constant influx of new features due to the overwhelming complexity it leads to. So if we do have new features, they better be worth it.
The ease of use of smart pointers makes it tempting to allocate/free of temporary structures even within one single function. Given enough number of such occurrences, it kills performance by a thousand cuts.
This isn't true and doesn't make any sense. Smart pointers don't need to enter into it. If you need a lot of something you make a vector and allocate once.
Also I remember they mentioned it’s not necessary to free memory if you’re about to close your program, because the OS will take the memory back.
It is an extremely niche scenario to need a program to shut down so much faster that you can't even deallocate memory. If you don't make lots of small allocations in the first place the deallocations won't take any time.
Obviously you need to gracefully deinitialise some things, like audio or other devices, but that’s beyond the discussion.
It's actually a pretty big advantage to destructors to deal with stuff like this as well as memory and locks.
IMO, their RAII critique is a but nuanced, but because of their personality the discourse often gets polarising.
I think it gets polarizing because they are both undeniably sharp programmers but don't have any real evidence of this stuff, they are just grasping at rationalizations.
