Even if your 94x multiple held perfectly (a big if), Google's "return" here is unrealized appreciation on an illiquid, minority stake. They can't spend it. And if they try to sell post-IPO, the act of selling a large block would push the price down, shrinking the very gains you're describing.

Meanwhile, the $11B/year in cash going out the door is very real and liquid and hits Google's income statement immediately. So the actual trade is: guaranteed cash expense now, in exchange for speculative paper gains later on a stake they can't easily exit. Even if you assume bad faith on Google's part here, no CFO in their right mind would see this situation as an easy 5:1 return.

The simpler explanation is the one Google gave: they need bridge compute capacity because Gemini Enterprise demand is outrunning their own datacenter buildout, and SpaceX has 110K GPUs available now.

This deal can't just be financial engineering, since that wouldn't make sense. They must be getting something out of this, i.e. compute.

Google is buying compute because they need it. That explanation works a lot better to me than one where Google is doing this purely for unrealized future gains on a minority stake in SpaceX.

The explanation that this is just financial engineering (which to me, means neither Google nor SpaceX is getting anything out of this other than looking better on paper) doesn't make sense to me. How does this financial engineering benefit Google?

Even if they have an exit option, why is Google (a private, separate, self-interested firm) giving a single dollar to SpaceX if the deal isn't mutually beneficial?

As far as I know they really will be paying $11 billion annually in liquid cash to SpaceX (not a small ask) starting this year, and all they get in return is more money on paper?

What incentive do they have to help SpaceX out like this at great cost, if they're not actually buying something valuable? Why are they incentivized to do this if it's just an empty deal and financial engineering? Genuine, good faith question: what are they getting out of this?

HN relatively, is a very intellectual part of the internet, yet even still, it's really common to see very uneducated opinions here. Not that everyone needs to be very educated, but posts with plainly wrong assumptions and biases shouldn't go completely unchecked so rampantly.

The solution might be well out of grasp now, but think 10, 20, 100 years from now. Somebody smart with a new perspective will eventually come around and tear out the roots, and we'll all be better for it. Perhaps what's holding us back isn't the problem itself, but the way we approach it and the assumptions we bring.

Trying is at least worth the effort, especially since "better" is very achievable, rather than total perfection.

Even though I'm a fan of React, and use it for practically every web application I build, my biggest and most obvious issue has been that writing UIs through React doesn't feel as natural as, say, writing command line tools in Go, or live/realtime apps in Elixir.

Some languages just feel incredibly natural and frictionless for certain things, and nobody has really nailed UIs yet. Swift, JSX/HTML, Svelte, or whatever framework of the week: they all feel like they're working around the problem to some extent. Like at some point in the process, the designers of the language/framework had to compromise and implement some hacky/weird/painful syntax to satisfy project requirements.

UI's natural interface is visual, so tools like Figma can serve as an essential part of the solution, but nonetheless, I feel there's something missing. There must be a more intuitive way to represent the visual through code. The current solutions, although I find it hard to describe precisely, are always tantalizingly lacking in one way or another.

It was uncertain then, and not so uncertain now.

There is reason to be suspicious of LLMs, but people should stop getting so wrought up over _how_ the Bun team writes their software, until they have complaints over the software itself.

Just let the team do their thing. You're free to reject the end result.

Can you setup wildcards? Like for example *.[name].san-fransisco.ca.us? That way I can do this once for my own name and have it setup for all future needs as well.

I think the Quixotic accelerationists of AI are more or less a vocal minority of the people who make software, and the choice of online APIs over local systems is largely a choice made for users, rather than developer’s laziness.

You can do more and better with private AI today than with local models. There is no getting around that. Even if local AIs get better, being on the cutting edge of LLM performance is often a very worthy investment.

Most people won’t settle for a product if it’s not the very best and incredibly convenient. That’s a high bar, and local AI often doesn’t meet those standards.

HN’s insistence on treating all users like they are open-source, privacy-first, self-hosted Linux fanatics is painfully corny.

So imagine whatever Rust has with C but with many other languages.

I was reading the Swift 6.3 release, and better C interoperability was one of the main new features. As a Swift developer, I know that a lot of people love Swift because of how great it is to work with alongside C. So this brings forward the question: why doesn't Swift also work with Rust, or Python, or many other languages?

(Specifically with Swift, I don't know how useful interoperability with Rust or Python would be (probably not very useful), and it certainly wouldn't be a trivial engineering challenge, but aside from that: why not?)

More generally, why isn't interoperability between languages a bigger thing? There are of course challenges, like interpreted vs compiled, or JIT vs AOT compilation, but I think there are serious benefits to be had. Perhaps in a perfectly setup project you wouldn't need interoperability, but in the real world plumbing between languages is a constant problem. To demonstrate this, if one language could easily communicate with many others, here are some possible use cases.

- All libraries of all languages become compatible; this is the big one. It would be pretty freeing (although perhaps not always architecturally wise) if when searching for libraries to do what you want, you could pick from literally anything. - Certain languages are suited to certain applications, with interoperability, you could be incredibly versatile. If one language is really good at one thing, and another language is really good at another thing, and you're project needs to do both thing, you don't have to compromise if both languages are interoperable. - Multi-language projects could not only be possible, but even easy. If you could do backend in Go and frontend in TypeScript, it would be phenomenal if you could freely import abstracts in-between languages. Imagine end-to-end type safety even, with no additional work. - Performance. Simple languages are faster to write, though sometimes run into problems later when performance becomes a bottleneck. This would be solved if say, Rust and Python could work together. You could write everything in Python, then when you need the power, switch to Rust. This already exists with Maturin and PyO3, and as a frequent user of this structure, it's pretty great. Imagine if it was available for all languages.

There are just some of the overlapping benefits, but I am sure there are more. In any case, these are things that would be great to have! Why hasn't somebody, perhaps in a performant low-level language, built a plumbing layer which connects many different programming languages? We live in an age with really powerful IDEs, that, if given the right tools, could definitely support much deeper interoperability.

What if programming with two languages in one project didn't feel different from just using one? Sure, some people just want to get from point A to point B, but I think the freedom to use anything could really create a lot of productivity.

While I am well aware that this would be a behemoth engineering project, I think a small group of ambitious developers could make significant headway. It wouldn't need to be all the way, and you'd be wise to take it slow, but I feel the benefits of such a project would be well worth the considerable effort.

Comments URL: https://news.ycombinator.com/item?id=47534632

Points: 3

# Comments: 5

And from this is where you get "rent-control is a terrible idea". Essentially: trying to artificially drive down housing prices in any way is generally inadvisable if you can just build more housing.

Sure that's technically an opinion, but it's one based in facts, and it certainly doesn't have "zero evidence".

https://www.brookings.edu/articles/what-does-economic-eviden...