Musk sold Twitter into xAI which he then sold into SpaceX as a financial engineering effort to lessen the impact of massive debts and cash burn. The IPO and some clever structuring is the final step in the process.

It's really just a debt transfer to make one company look good while the other is saddled with debt. Should be illegal

My Nissan Ariya checks nearly every box. The controls for the AC have dedicated buttons, but they are capacitive, not tactile. Anyway, love the car. It's a real shame that they aren't selling them in the US anymore.

Making these claims on a 2B parameter model seems a bit like seeing linear scalability from 1 to 4 cores and then assuming 256 cores will give you a 256x speedup. Or demonstrating massive improvement on datasets that fit in cache and then assuming the same improvements will be present on problem sizes that span the memory of multiple machines. Something tells me that scaling to larger models will be more difficult than assumed.

Yeah, I agree: I'm actually not expecting it to be easy, and there will certainly be several unknown unknowns we'll discover along the way.

Our process has been, and will continue to be, a sequence of (tedious) R&D experiments where the GPU never behaves as expected when pushed to its limits in ways no-one really tested before (I still have nightmares of the L3 cache cross-IOD bottlenecks on MI300X).

IMHO, we did solve the multi-GPU memory bandwidth scaling problem, and thus the linear scaling of the size of the model towards infinity. But the main difficulties will come from keeping the speed, with steady and continuous memory streaming, while implementing the much more complex architecture of modern frontier MoEs (attention compression tricks, hash layers, routing logic, etc.)

> Invent a completely novel word

Veltis (noun) \ ˈvɛl-tɪs \ Definition: The sudden, heavy realization that a piece of hardware, software, or physical object you rely on every day has quietly cross-graded from a "tool you own" into a "service you manage." It’s the specific weight of knowing a simple device now requires its own ecosystem of accounts, updates, or maintenance to function.

In Context The Sensation: "I went to use my old e-reader, but it required a mandatory account migration and a firmware patch just to open a local file. I felt a massive wave of veltis." As an Adjective (Veltistic): "I love the new smart espresso scale, but the fact that it needs a Bluetooth sync to track water flow feels a bit veltistic."

Maybe - let's assume that we could simulate a human brain to a high level of fidelity starting from a known good state and emulate its input and output. Do you think we could poke at it enough and ask the simulated person about their experience enough to discover the mechanisms behind what we experience as a soul? It's logistically and computationally insanely complex to pull off, but if we could build such a system, I don't see why we couldn't eventually figure it out in another thousand years' time (assuming we don't destroy ourselves or do something that sets back the evolution of technology massively between now and then).

This is what humanity will inevitably end up trying to do with computing, and a great argument for why we could be in a simulation.

MMAcevedo

> Any solution that involves having to use a keyword to get the value returned from a function is such a poor design choice to me.

Technically speaking Rust didn't have to use a keyword (and in fact didn't for quite some time between 1.0 and when async was added), but the ergonomics of the library-based keyword-less solutions was considered to be less than optimal compared to building in support to the language.

> This is why new languages should build in green threading from the start.

This, just like most other decisions one can make when designing a language, is a tradeoff. Green threads have their niceties for sure, but they also have drawbacks which made them a nonstarter for what the point in the design space the Rust devs were aiming for. In particular, the Rust devs wanted something that did not require overhead for FFI and also did not require foreign code to know that something async-related is involved. Green threads don't work here because they either have overhead when copying stuff between the green thread stack and the foreign stack or need foreign code to understand how to handle the green thread stack.

> Nearly every time I call a function I don't want to have to care if it is synchronous or not.

The problem is that "nearly every time" bit. There's times where you are looking at the code and you absolutely want to be aware of where the function is suspending. Similar to the use of ? in error handling to surface all failable operations that might do an abnormal return.

> I want the syntax and grammar (and illusion?) of one continuous thread of execution

Then you shouldn't be using a low-level systems language? You can simply choose a higher-level abstraction language that better matches your programming preferences.

What you want is quite the opposite of what rust is -- rust force rules.

Look at how the borrow works. Most of the time, the compiler can _suggest_ the fix.. and instead of fixing that silently, they want you to fix it.

This is the design choice they made.

And yet it’s incredibly popular and successful. Windows is also ass, and the year of the Linux desktop is perpetually a few years away.

Being the least bad doesn't make something good. macOS is the least bad choice for the majority of people that just want a machine to mostly browse the Internet, look at their photos, do some light productivity work, and participate in their ecosystem. It also arguably hosts has the best software options for creative work (although that's reaping the fruits of seeds planted long ago - not sure there's much about macOS that makes it inherently better for those tasks these days). For development, its advantage is the hardware it's running on. To achieve any level of customization or to define my own workflow that isn't what Apple wants me to do or to work across multiple systems, I have to fight macOS rather than work with it. Linux on the other hand does what I tell it to do.

I’ve been using macOS because its creative ecosystem for decades. And over the last 10 years, it’s started to be apparent to me this is an expensive and unstable place to be. It will not be a place where tools find longstanding stability measured in decades. It is and will be a place where various sandcastle taxes are periodically assessed so the particular vision of the platform as a novel current luxury experience will be reinforced, and developers and users will be asked to keep pace on the treadmill and smile.

Edge Gallery by Research at Google

It seems like Halo's rampancy take on the breakdown of an AI is not a bad metaphor for the behavior of an LLM at the limits of its context window.

Does this app take 5 minutes to start? That's so much dynamic Spring magic. Also, how do you keep track of control flow when anything at anytime could have been overridden by something else? It seems like tracing and debugging this thing would be like exploring someone else's codebase every time.

> It seems like tracing and debugging this thing would be like exploring someone else's codebase every time.

Oh man, just wait till you start sprinkling some AOP in there. My debugger is damn near useless sometimes as I try to follow bizarre paths between parts of my code.

Totally! But it doesn't have to be this way.

The class loading magic means you need to be exceptionally careful about things that would otherwise be very innocuous. It’s the rule, not the exception - that your average spring boot app will be doing tons of expensive stuff at startup. Most of which is unnecessary and was not even intended.

The JVM doesn’t need this kind of thing either, and it gets a bad wrap from the J(2)EE days, and the “simple” replacement that Spring was supposed to be.

No doubt there’s some benefits to be had, but I don’t think the trade-offs are worth it, especially at larger scales.

The article talks about a specific solution they came up with. No way is this a representative example, they discard a typical pattern way at the top.

Who cares about startup times if apps is started only when new version is deployed?

And 5 minutes is a bit long, maybe someone is doing some database operations during start?

I care because every second of that startup time is lost productivity and focus. For me and any developer on my team. Hot reload only works if no class or method has changed so that's not a solution. I've worked on codebases of similar size and complexity in many languages, and the developer experience of a compile and restart that takes less than five seconds is game changing.

I can imagine a full build of the project(s) in TFA are on the order of several minutes to build/run the first, and maybe every time. I remember working on projects before SSDs were common that would take on the order of a half hour or more... the layers of abstraction were so that you literally had to thread through 15+ projects in two different solutions in order to add a single parameter for a query and it would take a couple weeks to develop and test.

That said, I did catch up on my RSS feeds during that job.