I’m not sure I agree with the “no one claimed” part, because I think the proof is specifically targeting the claim that it is more likely than not that we are living in a simulation due to the “ease of scaling” if simulated realities are a thing. Which I think is one of the core premises of simulation theory.

In any case, I don’t think the reasoning only applied to “full scale” simulations. After all, let’s follow the thought experiment indeed and presume that quantum mechanics is indeed the result of some kind of “lazy evaluation” optimisation within a simulation. Unless you want to argue solipsism in addition to simulation theory, the simulation is still generating perceptions for every single conscious actor within the simulation, and the simulation therefore still needs to implement some kind of “theory of everything” to ensure all perceptions across actors are being generated consistently.

And ultimately, we still end up with the requirement that there is some kind of “higher order” universe whose existence is fundamentally unknowable and beyond our understanding. Presuming that such a universe exists and manages our universe seems to me to be a masked belief in creationism and therefore God, while trying very hard to avoid such words.

The irony is that the thought experiment started with “pesky weird behaviours” that we can’t explain. Making the assumption that our “parent universe” is somehow easier to explain is really just wishful thinking that’s as rational as wishing a God to be responsible for it all.

I’ll be straight here: I’m a deist, I do think that given sufficient thought on these matters, we must ultimately admit there is a deity, a higher power that we cannot understand. We may as well call it God, because even though it’s not a religious idea of God, it is fundamentally beyond our capacity to understand. I just think simulation theory is a bit of a roundabout way to get there as there are easier ways to reach the same conclusion :)

It’s possible yes, but the nice thing is that we know we are not merely talking about “advanced people with vastly superior technology” here. The proof implies that technology within our own universe would never be able to simulate our own universe, no matter how advanced or superior.

So if our universe is a “simulation” at least it wouldn’t be an algorithmic one that fits our understanding. Indeed we still cannot rule out that our universe exists within another, but such a universe would need a higher order reality with truths that are fundamentally beyond our understanding. Sure, you could call it a “simulation” still, but if it doesn’t fit our understanding of a simulation it might as well be called “God” or “spirituality”, because the truth is, we wouldn’t understand a thing of it, and we might as well acknowledge that.

No worries, I understood that you were playing devil’s advocate somewhat. And indeed I don’t like it either, and fwiw, I’m not American either (European, so I don’t really have skin in this particular issue).

But when you say it’s a “rather valid decision with its motivations and reasons”, then yes, that’s basically what it means when I say it’s justified. But then you still have to ask the question as to who it is justified for. If you say it makes “sense on an economical and geopolitical level”, that’s well and good, but which economical and geopolitical level are we talking about? A deal such as this is unlikely to benefit the economy as a whole, so who are the beneficiaries? That’s the question of perspective. Probably this benefits Trump and his billionaire friends, hence why it’s justified from their perspective. But Average Joe, or the Argentinian equivalent, are unlikely to ever see a benefit from this.

I think you’re both right. The problem in this discussion is that “justified” really depends on perspective. I agree with the other guy it is justified… from Trump’s perspective. I agree with you it is not justified for the American people.

That’s not just pedantry, that’s unnecessarily narrow-minded. Ever heard of the corrupted heart? According to your definition, that’s an impossibility, unless the heart belongs to someone in authority, or something, I guess.

The point is, there is more than a single interpretation of things, and there is not a singular definition of corruption. Anyone can be corrupted, and giving examples that show that lawlessness permeates every level of society is a great way of showing that corruption is likely endemic in the culture.

I’m Dutch too, and I used to work 8h/day 4 days a week. And my productivity became even better than when I worked 5 days a week. I could kill it those 4 days, and be rested enough the next week so I could kill it again. It worked wonders.

I like the rhetoric, because it means that my employer got something out of it too. But I don’t think it implies that was the only reason it should be given. I obviously enjoyed the time off for my own reasons.

I don’t understand why you’re getting downvoted. While I don’t share your conviction, I do admit it’s certainly a possibility.

The advantage of doing things that way is that code becomes much more portable. We may finally reach the goal of “write once, run anywhere”, because the AI may write all the platform specific code.

It does make a big assumption that the AI output is reliable enough though. At times people will want to tweak the output, so how are they gonna go about that? Maybe if the language is based on Markdown, you can inject snippets of code where necessary. But if you have to do that too often, such a language will lose its appeal.

There’s a lot of unknowns, but I see why it’s a tempting idea.

tsc is (very) slow and there are also no convenient ways to interact with it from Rust.

So it saves a lot development and CI time to roll our own. The downside is that our inference still isn’t as good as tsc of course, but we’re hopeful the community can help us get very close at least.

I see this argument repeated here every now and then, but it’s not true: https://aoav.org.uk/2020/the-effects-of-strategic-bombing-in-wwii-on-german-morale/

To summarise: Bombing had a profound effect on depressing morale through inducing defeatism, fear and apathy. Bombing did not harden popular resolve against the US. The hate and anger it aroused was directed against the Nazi regime, not the Allies.

It’s that the compiler doesn’t help you with preventing race conditions. This makes some problems so hard to solve in C that C programmers simply stay away from attempting it, because they fear the complexity involved.

It’s a variation of the same theme: Maybe a C programmer could do it too, given infinite time and skill. But in practice it’s often not feasible.

Which one should I pick then, that is both as fast as the std solutions in the other languages and as reusable for arbitrary use cases?

Because it sounds like your initial pick made you loose the machine efficiency argument and you can’t have it both ways.

I’m not saying you can’t, but it’s a lot more work to use such solutions, to say nothing about their quality compared to std solutions in other languages.

And it’s also just one example. If we bring multi-threading into it, we’re opening another can of worms where C doesn’t particularly shine.

Well, let’s be real: many C programs don’t want to rely on Glib, and licensing (as the other reply mentioned) is only one reason. Glib is not exactly known for high performance, and is significantly slower than the alternatives supported by the other languages I mentioned.

I would argue that because C is so hard to program in, even the claim to machine efficiency is arguable. Yes, if you have infinite time for implementation, then C is among the most efficient, but then the same applies to C++, Rust and Zig too, because with infinite time any artificial hurdle can be cleared by the programmer.

In practice however, programmers have limited time. That means they need to use the tools of the language to save themselves time. Languages with higher levels of abstraction make it easier, not harder, to reach high performance, assuming the abstractions don’t provide too much overhead. C++, Rust and Zig all apply in this domain.

An example is the situation where you need a hash map or B-Tree map to implement efficient lookups. The languages with higher abstraction give you reusable, high performance options. The C programmer will need to either roll his own, which may not be an option if time Is limited, or choose a lower-performance alternative.

Of course, but it needn’t be black and white. You can also diversify, make yourself less reliant on a single platform. And by doing so, enable your audience to follow you elsewhere. Or diversify into different activities altogether. And when it’s no longer half your income on the line, then switch.

But doing nothing and saying, “but half my income!”? That’s not only a choice, but also complacency.

Great points, except:

People can’t leave for anything smaller.

They can and some do. It’s still a choice.

I’m not arguing against that. Merely providing some counterweight to the idea that the author was “flinging shit in the trenches” 😅

I found the title of that section slightly triggering too, but the argument they lay down actually makes sense. Consistency helps you to achieve correctness in large codebases, because it means you don’t have to reinvent what is correct over and over in separate pockets of the codebase. Such pockets also make incremental improvements to the codebase harder and harder, so they do come back to bite you.

Your example of vendors doesn’t relate to that, because you don’t control your vendor’s code. But you do control your organisation’s.

There is a serious attempt for that actually: https://www.assemblyscript.org/

It doesn’t offer full compatibility with the regular TypeScript though, despite being very similar.

Feel free to just use React on the frontend if you’re more familiar with it, but make sure you couple it with Redux. Then when the time comes you want to bring some Rust into the frontend, you can do so by writing your Redux reducers in Rust.

PS.: The blog post mentions using fp-bindgen for WASM bindings, but nowadays you’re probably better off using wasm-bindgen.