I am curious what happens to Tesla stock now. I always viewed it as a way to invest in Musk, rather than in a car company. But SpaceX would seem a better fit for that now. Teslas underlying value is much lower.
But the SpaceX float (a term I didn't know about before this IPO) is low enough that this effect may not even show up at all.
Assuming the website I just looked up the numbers on was not itself the hallucination of an AI[0], 75% of Tesla's shares are actually traded, so if I take their market cap as US$1.5T then people are trading US$1.125T of Tesla shares, whereas SpaceX only floated $75 billion of theirs, so it won't dilute the available market for people who want to ride Musk's coattails.
Not long unless they bend the rules. The voting control, the restrictions on shareholder lawsuits, the fast track rules for NASDAQ, the shell game of different companies, etc is all meant to prop up a price that doesn’t make sense. Otherwise they would behave like everyone else and do a normal IPO. They can’t do that because it won’t keep its price.
Goldman Sachs projects SpaceX’s total revenue to reach $474 billion in 2030, up from $18.7 billion last year. That’s 25x in just 4 years. It shouldn’t take long to check if real growth is along this predicted trajectory. But by that time Elon Musk will have sold enough of his shares. We will pay through index funds in our 401(k).
Goldman is also the lead underwriter of the IPO as I recall, so their valuation analysis is a conflict of interest. See Morning Star, who values SpaceX as half the value they’re seeking:
An aside, but I'm still amused that Morningstar Inc., the American financial services firm, shares a name with the Morning Star, a left-wing British daily newspaper originally founded in 1930 as the Daily Worker by the Communist Party of Great Britain.
Zig has been doing fine before Bun and will be fine also after.
I'm personally thankful to Jarred & Bun for supporting Zig Software Foundation financially before they got acquired by Anthropic, but the reality of interacting with individuals in the Zig community is that the people who actually show up to Zig events and who do have compelling open source projects are almost never people who were interested in Zig because of Bun.
Bun did give us a bunch of visibility, but most of it was superficial interest.
Understandably, Bun is a JS runtime and so the people who discovered Zig that way were likely interested in doing webdev, and Zig is just now polishing the I/O implementation, so it doesn't have yet a particularly compelling web development experience to offer.
More like RIP bun. Wouldn't have paid any attention bun if it weren't for Zig. Now I need to figure out what the "normal" runtime is to switch my work typescript stuff to.
I think the issue is that Zig lost their biggest project, which was a posterboy project for real uses of Zig. Worse, the project felt like Zig wasn't meeting their needs, to the point they abandoned Zig and rewrote their entire project in a different language. Really bad signal for anyone thinking of using Zig for a big project. It is still in beta, but has there been any situation like this, where a upcoming programming language was abandoned by its biggest external project and still was able to be considered a successful language after that?
Well they haven't lost anything yet. Somebody is vibe coding a rewrite in another language and we don't know much else. The author said he will write a blog post about it soon. So far all we know is it is passing most of the test suite.
But Bun has open issues and bugs. The test suite doesn't tell us whether it has introduced many new bugs, solved existing ones the test suite doesn't catch, or anything else. Not to mention, the rewrite is 960K lines that nobody understands. How long will it take for the Rust version to be better, and be understood as well as its current maintainers understand the Zig version?
Having a project consider a rewrite isn't so big a deal. Zig has been designed from the ground up with a vision, and isn't worried about taking a while to create a stable API to achieve that vision. The self-hosted backend shows how incredibly fast incremental compilation is when the language is built for it ground-up. Compared to other languages that implement weaker forms of incremental compilation it isn't even close.
>I don't agree that them actually doing an entire draft rewrite can just be characterized as them considering a rewrite.
You're right, a rewrite is in existence, and whether it is good enough to be used or expand upon is what is being considered. I don't think that changes the fact that languages don't live or die by whether or not 1 large project using them continues using them. Especially a language like Zig which has taken plenty time making breaking changes. They know this is par for the course.
>I wonder if that's the mentality that got them in this situation in the first place.
I highly doubt it. To my knowledge, the only "why" Jarred has given is frustration with memory issues. Speculated reasons I see are:
1. Anthropic wants a rewrite to a language with a more favorable AI contribution policy, to avoid bad press by acquiring a framework written in a language that is skeptical of AI code quality.
2. Rust is more stable and a better target for AI-assisted programming or entire vibe coding.
3. Bun is upset Zig does not want to merge their fork into main.
Focusing on the issue Jarred gave as why he started the rewrite, I don't see how Zig got themselves into the situation at all. Zig was always upfront that it aimed to be a modern C: simple language, powerful modern features, and excellent compatibility with all things C. While it certainly has much better behavior concerning memory safety and undefined behavior, it has never aimed for Rust or GC level memory safety.
It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error. I think Jarred is in this situation because he wants to be, simply. He works for Anthropic, probably has no limit on how many tokens he spends, and may have access to their most powerful internal models like Mythos. I would guess he pointed agents at this problem and let them go, because why not? He has likely has no opportunity cost.
>It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error.
Huh? The patch that Bun submitted was for Zig was about compilation times, and making Zig's type resolution faster. I am sure the Bun developer who is submitting patches to Zig is well aware that manual memory management is a core tenet of Zig. The issue is that Zig has to "pick a struggle"; When using C, you manage all of the memory yourself, and get blazing fast compile and run times. In Rust, Rust uses the borrow checker to reduce the amount of memory safety bugs, however Rust can also have slower compile times due to this. Why would it make sense to use a language that is not helping you manage memory and is slow to compile, especially if you submit a patch to the language to address the issue and get rebuffed?
>Why would it make sense to use a language that is not helping you manage memory and is slow to compile, especially if you submit a patch to the language to address the issue and get rebuffed?
You're right, other things constant, this would not make sense. But this is a strawman. Zig has fast compilation on average compared to systems languages with more automatic memory management, like Rust. In addition, Bun's fork is based on 0.14 Zig, while 0.16 has become much faster.
In short, the Bun fork introduces non-deterministic compilation errors, a terrible problem for a language and its compiler to have. Zig just made changes to type resolution in 0.16 specifically to allow them to implement parallel semantic analysis, but properly without the bug the Bun fork has.
In addition, they have chosen to spend their time building the self-hosted backend and perfecting incremental compilation, which will have orders of magnitude more benefits to compile times than. Matthew already demonstrates a 4x speedup, what Bun claims to achieve, using the self-hosted backend, and 300x speedups with incremental compilation on a large project (Zig itself).
I am sure it is frustrating for Jarred to not get his patch in, but he was rebuffed for good reason. Bun's fork may have worked for them but many people, including the Zig team, would rather Zig do things properly than introduce bugs and tech debt to make flashy headlines.
I hate to do this, but are you using a LLM for your responses? It seems like your basic programming knowledge is extremely inconsistent between replies.
Side note, but Rust's long compile times aren't due to lifetime analysis, it's more about type resolution, monomorphisim, and LLVM codegen. Zig has fast compile times because they've been willing to remove features that don't play well with compiler parallelization (like removing usingnamespace).
So I have barely heard about Ghostty, and not at all about Tigerbeetle. Honestly, even Bun is a 2nd/3rd tier JS engine. Regardless, I think that if Bun goes forward with the port, the biggest issue is that for a language to so not live up to expectations that someone was willing to rewrite a ~1M LOC project to an entirely new language is insane. The most common case when there are some deficiencies in a language stalling development is to rewrite/refactor parts of their code base to another language that they feel as though would be better suited, not completely rewrite everything.
Zig is a very interesting LOW level language, but honestly I think it should be considered for what it is: a better C. I don't think it fits for anything that someone would have written in C++, Java, Haskell or C#. Instead, Rust is competitive with all of these languages when it comes to safety, abstractions and speed. And also C and Zig itself.
Zig has a couple very interesting ideas that make it stand out: comptime and the zig build system.
Alas, Zig is still far from being stable. Rust came out to the public in 2012 and became stable (1.0) in 2015. Zig came out to the public in 2016, and it's 10 years now and someone says it's still years away from 1.0.
So, while rust took 3 years of public development to become stable, zig is taking 10/15 years. I love the language, but TBH I don't see a great future ahead, especially with LLMs advancements that can use safer languages to do the same work. There's no point in risking more memory bugs when the effort for writing code is the same.
Honestly I think, at least to the Zig community, But isn't the biggest name we'd think of. There's been some philosophical friction between the Zig project and Bun (Zig is pretty anti-AI and favor methodical thinking through of problems, while Bun is more move fast and break things). I think TigerBeetle is a better representation of what Zig can do. TigerBeetle is fuzzed within an inch of its life, and is absolutely rock solid. The people who work on it are brilliant programmers who care a lot about correctness. They find that Zig lets them express their ideas succinctly, while still giving them the needed power.
When I read about Bun, I get the sense that Jarron has different priorities, mainly moving quickly. Bun also implements a lot of userspace APIs, since the core engine is JavaScriptCore which is written in C++. I think Rust really shines in applications programming, so I guess it makes sense that Rust has lined up with Jarron's needs. I'd be interested to see what JavaScriptCore would look like in Zig versus Rust, I think Zig might have an edge in the core interpreter and JIT.
Even if AI could cure all diseases today, and for free, people would still die from curable diseases.
Because nowhere in this fucking planet a company would let people get something without extracting every single possible penny from them, even if this would kill everybody that can't afford it. Well, this is something they already do.
Even if AI could solve all the problems of the entire world, people would still live a miserable life, with famine, disease and poverty, because it's from all this shit that big companies make big profits.
If you are an American citizen, you should not worry about the ayatollahs ruling thousands of miles away from you, but you should be doing something about the tyrant ruling near you.
AI will never be ethical because the copyrighted material used for training the AI without proper copyright payments is not only unethical but illegal.
Unfortunately law enforcement decided the copyright law only applies to regular citizens like me and not to billionaires owners of AI companies.
reply