https://github.com/rust-lang/rustc_codegen_cranelift/issues/...

How is that a non-sequitur? You're the one who brought up the topic of credibility in the first place. The comment was simply made in response to that.

If you look at brutalist buildings, it becomes obvious that its looks are the results of intentional design completely removed from its underlying "structural" concerns. You don't accidentally arrive there by refusing to think about aesthetics or by just being "honest".

I wonder which of these camps are right.

But the lineup of high-quality games in production with Bevy just never stops to impress me. I'm always surprised by the new cool stuff they're making every time I take a peek at their community. Yes, most of them are not finished yet, but the engine is still young so that's understandable (gamedev can take years).

On the other hand, I'm still not really seeing any games being made in Fyrox despite it being a few months older than Bevy. Huge respect to the dev though, he's making great stuff.

But if I ever need to pick a pure Rust game engine at all, it's def going to be Bevy.

I had a pretty good experience with it while trying out Love2D.

Most of these installation scripts are just simple bootstappers that will eventually download and execute millions lines of code authored and hosted by the same people behind the shell script.

You simply will not be capable of personally auditing those millions lines of code, so this problem boils down to your trust model. If you have so little trust towards the authors behind the project, to the point that you'd suspect them pulling absurdly convoluted ploys like:

> the web server behind mywebsite.com/foo.sh provides malware for the first request from your IP, but when you request it again it will show a different, clean file without any code

How can you trust them to not hide even more malicious code in the binary itself?

I believe the reason why this flawed argument have spread like a mind virus throughout the years is because it is something that is easy to do and easy to parrot in every mildly-relevant thread.

It is easy to audit a 5-line shell script. But to personally audit the millions lines of code behind the binary that that script will blindly download and run anyways? Nah, that's real security work and no one wants to actually do hard work here. We're just here to score some easy points and signal that we're a smart and security-conscious person to our peers.

> which are hosted by microsoft, and therefore easily MITM'able by government agencies.

If your threat model includes government agencies maliciously tampering your Deno binaries, you have far more things to worry about than just curl | sh.

> Odyc.js is a tiny JavaScript library designed to create narrative games by combining pixels, sounds, text, and a bit of logic.

[^1]: https://odyc.dev/doc/getting-started/intro

This is only true if you use the disko-install tool, which is a horrible footgun[^1]. The safest approach is to just use the default disko command, then nixos-install.

[^1]: https://github.com/nix-community/disko/issues/947

This is what the Try[^1] trait is aiming to solve, but it's not stabilized yet.

[^1]: https://rust-lang.github.io/rfcs/3058-try-trait-v2.html

How's the LSP support nowadays? I remember reading a lot of complaints about how badly done the LSP is compared to Visual Studio.

I looked into it, but it looks like that you need to manually build the image and fiddle around with qemu.

Functions with plain arguments and a struct both produce identical assembly output.

Seems to have paid off for them: https://play.google.com/store/apps/details?id=com.lightfoxga...