First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.
> What's your point, that if we can't do everything perfectly in one step we can't do it at all?
My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.
You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.
Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.
First, we're talking about a massive rewrite of complex software project which no one has fully reviewed and which the people most familiar with the code base (the bun maintainers) aren't even qualified to do so. As such, the issues people have found are mostly surface level.
But second, you're right, this is an easy thing to search for (especially with LLMs). And yet, the example I linked has been there since may, surviving multiple rounds of review. From this, we can draw a few conclusions: 1) claude (including apparently mythos/fable) fundamentally doesn't "understand" how unsafe rust works, and 2) no one on the bun team is aware that they need to tell it to fix this (if they're even aware that this isn't allowed in the first place).
The reason such trivial defects in a codebase are a red flag isn't so much those specific issues themselves, it's what they reveal about the authors. If you find a lot of obvious defects in some code, it's very likely that there are also many more subtle harder to detect issues as well.
There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc.
It's funny, because editor choice is also an analogy I use, to argue for the exact opposite conclusion.
Your hypothetical developer wouldn't be using notepad because they're unaware of other editors, they'd be using it because they evaluated other editors and concluded that, for whatever reason, they would be worse for them. I'd be fascinated to hear why they came to that conclusion, but I'm not going to tell them they're wrong if they're performing acceptably, aren't constantly breaking CI because the linter rejects their code, etc. Everyone is different, and I'm not narcissistic enough to think the fact that I would be way less productive without my modal editor, LSP, linter, terminal multiplexer, etc. justifies forcing everyone else has to adopt my exact setup.
Normal users aren't using harnesses in the sense developers think of them. They're interacting with models where they've been shoehorned in for no good reason, or they're using them nearly entirely through chat interfaces.
(Sorry I'm being vague, but I'm not sure I'm not sure what's public knowledge)
The cap is moderately above the high subscription tiers, and managements/the executives were clearly extremely concerned about how expensive it would be if we all or even mostly came close to hitting it. I heard that they originally wanted to go lower but the developers in the pilot program blew past their planned limit very quickly.
As for the company, its almost entirely B2B SaaS (I think it has some offerings that are used by consumers, but they're mostly/entirely paid for by another business on behalf of their customers), and they have developers all over the world, although the headquarters and biggest group of developers is in silicon valley (my office is in the midwest).
Uber is not the only company that's putting a per-developer limit on AI spending. I know this because I work for another one (and we have a significantly lower limit). You just heard about Uber first because they're high profile.
I'm not sure I'd classify "double" as "the same ballpark", but either way C2Rust appears to just mark everything as `unsafe` (even when it's completely unnecessary), so I don't think that's a fair comparison. Further, I know for a fact that their are instances of the `unsafe` in the bun codebase right now that are just trivially incorrect in rust. A vaguely competent human programmer, even one doing a 1:1 translation (which is likely a bad idea anyway) would have caught those.
Yes and no. In theory, you could start to go through an factor out unnecessary unsafe blocks from the codebase now. In practice, writing safe rust often requires significantly different design decisions than writing in garbage collected or fully manually memory managed languages, especially if you want the results to be performant. There's a very good chance you'd be better off rewriting from scratch than trying to do a 1:1 translation/port.
Bun has about twice the density of `unsafe` compared to deno, which does roughly the same job (wrap a c/c++ javascript engine to make a server side runtime written in rust). So not as massive a difference as the linked post's comparison, but still significantly more unsafe than we'd expect.
> Comparing unsafe counts to UV makes no sense here.
Agreed. The better comparison is Deno, which does roughly the same thing (wrapping a c/c++ javascript engine to create a serverside runtime). Deno was smaller, but per line of code/file it had just over half the unsafe as the bun slop rewrite. There are also examples of unsafe blocks that are just locally incorrect [0], meaning you don't even need to read outside the function and it's definition to determine that the entity doing the porting (in this case claude) didn't understand how unsafe rust works.
> I am skeptical why Bun was even an acquisition target in the first place, other than pulling stunts like this.
From what I've heard, it sounds like the author had become fully hooked by LLM coding before the acquisition, so I don't think we know enough to conclude that this was premeditated by Anthropic. I think the more likely trigger is that Bun had just bragged about how they'd forked the zig language for a performance increase and attacked zig for it's no-AI policy, only for a zig core team member to point out that the code couldn't be upstreamed even if it had been hand written [1].
The better point, IMO, is how this is an example of how AI use/addiction makes developers who fall into it loose the ability to judge code quality, particularly for code they prompted for themselves. From what I've heard of Mr. Sumner and the team at oven from before AI, I very much doubt code of this poor quality would have been allowed anywhere near the main branch before LLMs.
First, you're very likely underestimating how much load SQLite can handle. SQLite is usually write limited, but for smallish writes it can easily handle thousands a second with very trivial optimization, and with more thought can scale to tens or hundreds of thousands of write transactions per second. In some cases, it can actually out perform traditional server based RDMSs because of reduced overhead and because holding locks on network timescales (which will likely happen even for databases with multiple writers, because eventually you have to deal with two transactions needing to write to the same place) is very inefficient.
Second, I think you're overestimating how hard sharding is here. There are plenty of use cases for which sharding isn't just easy to set up, but the natural thing you'd be likely to do even without scale. Things like e.g. a helpdesk SaaS, where each customer/organization has it's own independent data.
Third, a large part of the point is that you are unlikely to know ahead of time you're going to "scale like that". As I already pointed out, most SaaS apps do not end up having many users. For some that's intentional, but for others the reason is that they simply never caught on. For those cases (and they're the vast majority), cosplaying as a much larger app is a complete waste. It's much better to wait until you're successful enough to need to switch and then use the revenue you now have to solve the scaling problem you ran into.
Fourth, as an aside, ironically the other (slightly less) easy way to shard superficially resembles a common way people cosplay as netflix: splitting your data by domain as "microservices" (although there's a good chance they don't need to be independent processes/on independent machines).
I didn't say they did. What I said was that if the person I was replying to was correct that average Elo ratings had increased because of AI, the mechanism would have to be "AI makes lower ranked players give up" instead of "AI makes players better on average"
1. Your unit tests are exacting enough to fully specify the unit. In that case, congratulations, your unit tests are the code. They're also probably much more awkward to write, maintain, etc. Also, the compilation step to go from the unit tests to the actual code is now orders of magnitude more expensive, requires a SaaS to even work, etc.
2. Your unit tests are not that exacting and still leave ambiguity, edge cases, etc. In that case it very much matters what's in the blob of code, because while it could be a correct implementation of what you wanted, it could also be something else entirely that just happens to be correct for the part you did specify.
Right, but you have to give the new players some rating, and as long as that number remains constant it will also be the mean Elo. Therefore, "new players entering the pool" can't cause a rise in mean Elo. As for lower rated players leaving, that could indeed raise the mean (assuming you stop counting them in the average), but that changes the point from "players have gotten better because of AI" to "worse players are more likely to just give up on chess because of AI", which is a significantly less optimistic picture IMO.
Elo is zero sum. Each point gained by one player is lost by another. It follows that the mean elo is always exactly equal to the initial elo assigned to new players before they play any games, and can't change over time. If the highest ranked player are higher elo than before, the lower ranked players must be lower elo.
First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.
> What's your point, that if we can't do everything perfectly in one step we can't do it at all?
My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.