"Downstream of" is doing a lot of work in that sentence. Language has an effect on, but in no way determines, the reliability of software written in it.
The original claim is one of determinism. Your use of the term "downstream" is hiding the distinction; it can be read in either way, so it bridges the gap between the position you want to defend ("using Zig causes a higher probability of memory bugs") and the position you're forced to defend ("using Zig results in extremely many memory bugs").
In short, I'm accusing you of doing a motte-and-bailey.
It's not deterministic, it's probabilistic. Bun does have memory bugs that would not be there if they'd written in safe Rust instead of Zig. You could imagine a scenario where ZigBun has zero memory issues, but it is not the most likely outcome, and is arguably an incredibly unlikely outcome given the entire history of software written in memory-unsafe languages.
I am less motte-and-bailey'ing, and you are more not subscribing to the principal of charity, choosing to interpret the original comment as its weakest possible version rather than the strongest.
It is very ironic that this post comes from "The Privacy Guy", given that the whole point of this model is to run inference on your own device rather than sending queries to the cloud, which is also much less power intensive than sending a query to OpenAI.
It would also imply that it costs Google ~7¢ in only energy cost to deliver that file to you (using average EU energy costs), which is clearly non-sensical given the rates hyperscalers charge for network egress.
Additionally, the cited number also conflates wired internet (low power consumption) with mobile internet (higher), even though this model is only being downloaded to Chrome Desktop AFAICT.
You could say the same thing about shipping V8 with Chrome. Some users disable JS so shipping V8 with Chrome is additional software they didn't ask for.
The old unix administrator would expect a platform to ship choice of JS that would be in /usr/bin/JS. The local administrator would add their local choice of JS /usr/local/bin/V8.
The browser would then have a configuration option of which JS interpreter to use.
Bad analogy. "Some users disable it" is very different from "it was introduced without any notification or information about what it does and the vast majority of laypeople have negative sentiment toward it".
Local subreddits are filled with posts "calling out" usage of AI by local businesses or governments. Consensus is that persons who are found out to be be AI users should be fired or resign, businesses that use it should be boycotted / shamed, etc.
ChatGPT (a 3 year old product) has nearly one billion WAU.
Some people detest businesses slopping AI at them, but the evidence suggests consumers love using AI, which is presumably one of the primary uses of a micro LLM model that runs locally on your computer and is embedded in your browser.
People that post on "local subreddits" and the randos that protest datacenters are once again a vocal minority. Reddit in particular is probably the most echo-chambery destination on the web.
There's an important distinction between chatbots people go to on websites or download from the app store versus a product downloading without their consent. There's also a massive difference from large power and water hungry data centers being built near people. I don't think those are particularly popular across party lines regardless of ChatGPT usage.
So yeah in general AI as a helpful tool people use online is popular. AI to replace jobs, build data centers and do unknown things on your device without consent, not so much. AI to potentially replace workers, not popular at all.
I'm not sure you understand the distinction you are making.
The model Google is shipping with Chrome runs on device. ChatGPT does not. The people that dont like data centers should love this feature. Same with people who are concerned about privacy.
For all of it's history (up to and including now possibly?) Github was a big Ruby on Rails monolith. [0] Obviously some things run in their own service, but I'm seeing the core github features fall apart which should be the features packed into the big monolith. If load is this much a problem, not being able to only vertically scale the processes that need the extra headroom is a big problem. Scaling horizontally by just throwing more machines at it, or at least cordoning-off some machines as "the ones that people actually pay for" is all I can think of for an application I can only describe as "accidentally working". Urgency is most-definitely high and that pushes decision making towards permanently-temporary patches instead of actual infra/architecture improvements.
reply