As a quick example, compare doing embedded work with a C static uint8_t[MAX_BUFFER_SIZE] alongside a FreeRTOS semaphore and counter for the number of bytes written, vs using Rust's heapless::Vec<u8, MAX_BUFFER_SIZE>, behind a embassy Mutex.
The first will be a real pain, as you now have 3 global variables, and the second will look pretty much like multi-threaded Rust running on a normal OS, but with some extra logic to handle the buffer growing too big.
You can probably squeeze more performance out of the C code, specially if you know your system in-depth, but (from experience) it's very easy to lose track of the program's state and end up shooting your foot.
So it's mostly about the absence of abstraction, in the C example? C++ would offer the same convenience (with std::mutex and std::array globals), but in C it's more of a hassle. Gotcha.
One more question because I'm curious - where would you anticipate C would be able to squeeze out more performance in above example?
I think the key is that the LLM is having no trouble mapping from one "embedding" of the language to another (the task they are best performers at!), and that appears extremely intelligent to us humans, but certainly is not all there's to intelligence.
But just take a look at how LLMs struggle to handle dynamical, complex systems such as the "vending machine" paper published some time ago. Those kind of tasks, which we humans tend to think of as "less intelligent" than say, converting human language to a C++ implementation, seem to have some kind of higher (or at least, different) complexity than the embedding mapping done by LLMs. Maybe that's what we typically refer to as creativity? And if so, modern LLMs certainly struggle with that!
Quite sci-fi that we have created a "mind" so alien we struggle to even agree on the word to define what it's doing :)
I'm looking for it as a general development machine, sometimes I do stuff that requires GPUs so if they can get a competitive price wrt. building a custom PC then I'm all in for the convenient form factor!
The steam machine as they’re marketing it doesn’t have enough RAM to be a proper development box once you start running IDEs, language servers and debuggers. They’d need to release a 64 or 128 gig sku, unless RAM is easily upgradable.
"Proper" is very subjective here. My entire workflow for developing 3D engines is covered a couple of times over with the announced Steam Machine specs. In fact, even when I was working in web backend development it would've covered it as a dedicated development machine and that was with some pretty pathological dev setups, language servers that ate up way too much memory, etc..
I think most people would agree that AlphaEvolve is not AGI, but any AGI system must be a bit like AlphaEvolve, in the sense that it must be able to iteratively interact with an external system towards some sort of goal stated both abstractly and using some metrics.
I like to think that the fundamental difference between AlphaEvolve and your typical genetic / optimization algorithms is the ability to work with the context of its goal in an abstract manner instead of just the derivatives of the cost function against the inputs, thus being able to tackle problems with mind-boggling dimensionality.
But it can be profited for not-so-big corps, so I'm still working for free.
Also I have never received requests from TooBigTech, but I've received a lot of requests from small companies/startups. Sometimes it went as far as asking for a permissive licence, because they did not want my copyleft licence. Never offered to pay for anything though.
Well you can't reach a high orbit using air breathing engines because your impulse must be given within the atmosphere, and then your trajectory inevitably re-intercepts the atmosphere (unless you achieve an escape trajectory) and would decay quickly. You can get around this by packing a small rocket engine and circularizing on apogee!
Maybe they laser-trim the embedded crystal in situ after the chip has been fully packaged? It might be more difficult to keep it in spec if they trim it earlier and then pass it through more manufacturing steps afterwards.
Seems unlikely it would fall out of spec by that much just during manufacturing. These things drift due to temperature (or even vibrations) anyway, and when it comes to using them in an RTC you have drift adjustment registers for any major drift from the factory.
Also you have to consider that even top-notch lasers have a divergence (out of memory, I may be wrong by an order of magnitude) of 10mrad or so, and you are physically limited to not much better than that, so you need pretty insane powers to damage, let alone destroy, a satellite at LEO altitude.
reply