I think is a very rational take indeed, and while it means that the simulated nature of our universe cannot be disproven (nor proven), it does mean that we cannot simulate a universe like ours.

But the simulation theory does rely on the reasoning that there is a (possibly infinite) chain of simulated universes in order to argue that it is more likely that our universe is simulated than not. But if we cannot simulate a universe like ours, it also becomes pure conjecture to suggest another universe can, and therefore the chain is broken.

In fact, the universe “above us” would need to have mathematical rules that are beyond what we know to be true. At that point, even the discussion of determinism vs nondeterminism goes out the window, because our understanding of truth would no longer apply. But calling the/a/any universe a simulation implies knowledge of determinism, otherwise it no longer fits our understanding of algorithm. So if you believe the universe is a simulation, you may as well say that you believe in spirituality (not the hand-wavy non-scientific kind, but the kind that acknowledges an understanding that is at a higher level than ours). I think it’s hard to argue against a higher-level understanding beyond ours. But calling it a simulation has implications that don’t seem to hold. So maybe calling it spirituality is actually the fairer description.

I can take this one: Because he doesn’t actually care about creating anything of value. If he truly believed in it, you’re right, Twitter or even Tesla’s software engineers would be on the chopping block and he’d replace them with AI as soon as he can. But he doesn’t.

He knows this is a longshot. Most likely to fail, but very profitable on the near-impossible chance that it works. But he doesn’t care even if the odds are truly impossible. Because this is an investment opportunity, so people will throw money his way, no matter what the odds.

People assume he’s an idiot, and he is. But he’s not stupid, at least not in every way. He certainly has a skill for separating others from their money, which he happily takes advantage of.

Maybe not the best example then, but not the only example. If you unintentionally create something that resembles the original too much you may still become liable. It’s hard to draw the line, which is why many in such a position would prefer to be safe rather than sorry.

They’re included in the beta!

Specifically, you can create GritQL plugins for custom linter diagnostics. There’s certainly more we’d like to do on that front, but we’re first going to see how these are being received to decide where to prioritise next.

We don’t currently publish to Crates.io, but we do have CI integrations that can install without needing NPM.

Formatter and linter in one even :) I’ve updated the message at the top.

Ha, I better not tell you about the Apple Keyboard I use with my Linux laptop then. Don’t like macOS much, but I love their flat keyboards.

Sorry, but this mindset is hurting both Linux and security in general.

The reason we are seeing a lot of security vulnerabilities is because prior to about 10 years ago security wasn’t considered that important.

This is frankly quite obviously false. Microsoft started taking security more seriously around the release of Windows 2000. Are you saying the Linux kernel developers took another 15 years to realize security is important?

Security research shows that new code is more prone to common vulnerabilities than old code is. While old code may have been designed with weak (or no) security considerations, those are well-mitigated by now. On the contrary, new code still regularly contains exploitable memory safety issues that slip by review.

What we need is skilled programmers who understand security.

We have skilled programmers who understand security. Those also understand that we need more than that.

Continuing to use C doesn’t merely require skilled programmers, it requires programmers that never make any mistake ever. That’s an infeasible standard for any human to uphold, hence why C is considered a risk.

Yes, it has a few APIs of its own. I merely think they are negligible in this discussion because they only provide a minimal superset over Node.js’s own APIs and are also very minimal compared to what Deno provides.

I’ve updated my post to mention “noteworthy” APIs.

You’re ignoring the fact that for many projects it does work.

It only needs to be perfect if you want to run 100% Node.js software unaltered. While that may be a lofty goal, it’s also an infeasible one.

That doesn’t mean imperfect support is futile though. By your logic, Bun has no right to exist because it only supports Node.js APIs and doesn’t have noteworthy APIs of its own, and they’re not perfect either. Yet they seem to be at least as successful as Deno is.

Or for an example in a different domain: Your argument would state that a project like WINE shouldn’t exist because it doesn’t have perfect compatibility with Windows, and it disincentivizes development of Linux games. Yet it is largely thanks to WINE that Valve has been able to make the Steam Deck and that Linux gaming is finally taking off.

I think what your argument fails to take into account is that you need a significant amount of users to make any impact on the market. And many users have legacy requirements that they can’t throw out overnight, so you have to support those legacy environments. And even with imperfect legacy support you can support your users, especially if the users are willing to make a few changes here or there. But if you have no legacy support, you also get no users except those that have niche greenfield requirements.

So instead of trying to replace NodeJS or offering an upgrade path for existing Node projects, incentivize formation of ecosystem around Deno

They are incentivizing their own ecosystem. That’s what Jsr.io is all about. But the world isn’t black and white. They can do more than one thing.

I dunno, I still see a blog post. Which is hosted in their own issue tracker, which is of course odd, but also the point.

Maybe it went down for a bit?

I would love to see Go, Rust, Swift and Kotlin added to this. Anyone willing to take a shot?