This gets posted every few months, so you probably got it from the internet

You may be correct about the level of models you can actually run on consumer hardware, but it's not fud and you're being needlessly aggressive here.

Copilot doesn't have users. They're rebranding their non-llm offerings as copilot to make it not look like a failure

Deno is a native implementation of a standard library, it doesn't have language implementation of its own, it just bundles the one from Safari (javascriptcore).

This is a set of linting tools and a typestripper, a program that removes the type annotations from typescript to make turn it into pure javascript (and turn JSX into document.whateverMakeElement calls). It still doesn't have anything to actually run the program.

Deno uses V8, which is from Chrome. Bun uses JavaScriptCore.

Ah, yeah. Easy mistake

I'm going to call it: a Rust implementation of JavaScript runtime (and TypeScript compiler) will eventually overtake the official TypeScript compiler now being rewritten in Go.

? Most JavaScript runtimes are already C++ and are already very fast. What would rewriting in Rust get us?

Nothing, but it will happen anyway. Maybe improved memory safety and security, at least as a plausible excuse to get funding for it. Perhaps also improved enthusiasm of developers, since they seem to enjoy the newness of Rust over working with an existing C++ codebase. Well there are probably many actual advantages to "rewrite it in Rust". I'm not in support or against it, just making an observation that the cultural trend seems to be moving that way.

In popularity or actually take over control of the language?

Eventually I imagine a JS/TS runtime written in Rust will be mainstream and what everyone uses.

By default, yes. You can configure it to not overcommit

Right, but as a programmer you rarely have control over that. And even if you do, you often can't handle out of memory errors gracefully.

Thus, for a typical situation it is reasonable to log the error and bail out, rather than adding extra custom error handling around every single memory allocation, which ends up being code that is never tested.

Not for years. If that is still the case for you, ask your server hosts to update to a version that supports ircv3

It absolutely theoretically can, but afaik neither V8 or the JVM can actually do it to a level where it outperforms the static optimisations of GCC or LLVM.

Is this still the case or am I going on outdated info on the matter?

Oh come on. It's massively wrong. It is always wrong. It's not always wrong enough to be important, but it doesn't stop being wrong

You should elaborate. What are your criteria and why do you think they should matter to actual users?

No, it’s not.

The reports I remember show that they're profitable per-model, but overlap R&D so that the company is negative overall. And therefore will turn a massive profit if they stop making new models.

* stop making new models and people keep using the existing models, not switch to a competitor still investing in new models.

Doesn’t it also depend on averaging with free users?

There is discussion about this in the Rust world, though no attempts at implementation (and yet further from stabilisation)