Game Jam 2 Results

> That sounds an awful lot like bypassing the borrow checker.

I guess you could argue it's bypassing borrow checker in weakest possible sense.

Borrow checker checks borrow. You aren't borrowing you are doing pointer manipulation, and presenting it with stuff that isn't its duty to check. I argue for this because people think that unsafe region is no mans land and that rules of borrow checking don't exist there.

That said, miri should be able to check your unsafe for undefined behavior. https://pramode.in/2020/11/08/miri-detect-ub-rust/

> Rust is going to force you to write your program in a certain way to achieve this. There are many other approaches you may be able to use in an unrestricted language which reach a correct and potentially more performant result which are correct, but which rustc cannot verify are correct.

Yes. It is a small downside, with a huge upside. Seatbelts prevent full mobility but I bet you wouldn't advocate for removing them because crashes rarely happen, and they limit your ability to move during driving.

> but that's not the only way to write a correct program which guarantees that

Rust has a provable way to eliminate a set of errors. You'd need to offer hard proof that code you wrote in alternative way, wouldn't have those issues.

And that alternative way might still be expressible in Rust using some abstraction/unsafe.

> How exactly do you come to the conclusion that Excel and Access are better at delivering value than other programming languages?

You mentioned how Python enabled more people to code. I'm willing to bet if only enabling to code then Excel and Access brought programming to more people, yet we don't see them in use, because maintaining is painful and hair tearingly frustrating. And performance is meh as well, but Python isn't winning any speed medals either.

> It takes it for granted that lack of memory safety in a systems language is "a regression". That's not an established consensus.

I value code that has less footguns than more footguns. Rust showed we can eliminate several cases of footguns, so why add them back? In that sense it's a regression. If you don't value memory safety and enjoy figuring out debugging data races, go nuts. Remove the seatbelts, you probably won't crash. However, if you do - It won't be pretty.

> That's one opinion. There are many who disagree.

3+ billion humans use spaces and punctuation as a error checking mechanism. IDOUBTYOUWANTTOGOBACKTOHOWROMANSDIDIT

> and he's arguably correct on that front: no mainstream (even in the broadest sense) language that ever came after C++ was memory-unsafe.

I don't understand that logic, as we're only talking about low-level languages. Of all the low-level languages developed after C++, including D, Rust, Zig, Odin, and JAI, the majority aren't memory safe.

> It is the consensus in PL design, whether you like it or not

It clearly isn't even the majority opinion in low-level PL design, let alone the consensus.

> but it's doing things that have not been done before, and it's a hell of a success for a programming language designer!

Sure, by that metric it is a great success.

> it just claim it can prove memory-safety and thread-safety

I know, but the reason it does so is as a means to an end. The reason why anyone wants memory safety is that it eliminates certain classes of bugs that can be quite harmful. The reason why we may not want memory safety is that sometimes it can come at the cost of other bugs, overall not helping correctness. Anyway, software correctness is a complex issue, and it is not currently known whether Rust's approach or Zig's -- if either -- is more effective at achieving correctness.

> Ctrl-F for Rust on this page returns no results…

Yeah, it's an image or something, but it's there.

> you should probably refrain yourself from insulting one of its designer.

Sorry about that.

> shows you're really not familiar with the PL design space (which is fine actually but you should probably not be arguing about academic domains you're not familiar with).

Oh, I'm familiar enough (my job requires me to be), but I wanted to list languages people here have heard about. Also, I'm not arguing about an academic domain. Having spent just the other night at a gathering with PL researchers in the UK, some interested in Zig, I know that even if we restrict the discussion to academia alone there is absolutely no consensus over the matter. It is an empty and false assertion, plain and simple.

Also, let's not forget that Rust leans quite heavily on a garbage collector, too, albeit a rather crude one.

> The idea that Rust may cause more bugs than it avoids is backed by zero evidence.

I never claimed that it does. I said we don't know which approach leads to more correct software, and that anyone who says we do is simply unfamiliar with the field or misleading. I explain more below.

> that “maybe Rust some unknown type of bugs we cannot be sure” is a fallacy

That's not what I meant at all. Just as an example of things that Rust's design could adversely affect to the point of adversely affecting correctness, consider two techniques that have proven extremely valuable in improving software correctness: code reviews and tests. A complex language with a lot of implicitness, long compilation time, and possibly longer code-writing time, can slow down or hinder these two techniques. Those issues are related to why so many in software correctness research today focus on reducing soundness; soundness has a cost of slowing down very effective unsound techniques, and given that full-soundness is something most have given up on, whether the price is worth it is always a hard question with no easy answers.

> Zig doesn't particularly address “correctness”, more than any typical language...

I think it does, and Zig's designer thinks so too (in the sense that he's designing the language and it tools with correctness as a primary goal) -- I don't know if it's more than any "typical" language (working on a "typical" language myself and caring a lot about correctness, too), but certainly not to any lesser extent than Rust. In particular, there's a very strong emphasis on explicitness over explicitness (no hidden control flow, local reasoning) and there's a strong emphasis on fast compilation and good testing support (including a design that makes isolating units and testing them easier) to facilitate faster and more rigorous testing.

Those who arrive at correctness from academic PL are often unfamiliar with such reasoning, which is now increasingly more common in formal methods research where the power of unsoundness is now appreciated.

> There is no trade-off in correctness between those two

I gave an example above that explains why some people think there could well be. No one can claim that either Zig or Rust yield more correct software, because we really don't know.

> One can argue that “programming mistakes” ...

That's not the argument at all. Memory errors are, indeed, both tricky and dangerous, and it is important to avoid them, but not at the expense of missing other, equally tricky and equally dangerous bugs.

> If you want to see “Zig safety story” in action, have a look at the only commercial user of the language, and go search for “segfault” in the github issues…

If you choose to eliminate bugs of class Y, you'll have none of them, and if you don't -- you will. This has no bearing at all on the question of overall correctness, which is what memory safety ultimately aims to serve. That is why there's no consensus over it.

> Also, let's not forget that Rust leans quite heavily on a garbage collector, too, albeit a rather crude one.

How do you want anyone to take any your words seriously when saying things like this… Rust has reference-counting primitives in its standard libraries, but saying in “leans heavily” on it is a “very original” take (in fact, Rust leans more on “epoch-based memory reclamation” than it does on reference counting, but even if you had that in mind, it's still quite far from “leaning heavily”).

> That's not what I meant at all. Just as an example of things that Rust's design could adversely affect to the point of adversely affecting correctness, consider two techniques that have proven extremely valuable in improving software correctness: code reviews and tests

It “could”, in the same sense that “vaccine could cause autism” or “the US could never have put men on the moon and staged the moon landing in Hollywood”

> I think it does, and Zig's designer thinks so too

Interestingly enough, you spend much, much, more time talking about it than himself…

> I gave an example above that explains why some people think there could well be. No one can claim that either Zig or Rust yield more correct software, because we really don't know.

So the gist of your argument is that we don't know because for “some reason” Rust could make testing (this is ironic when you know how much of an improvement Rust testing story is compared to most languages) and code review less practical, to a point where it would more than compensate for a class of bug that have empirically proven really really hard to avoid with conventional methods like testing, code review or runtime tooling. Wonderful.

> If you choose to eliminate bugs of class Y, you'll have none of them, and if you don't -- you will. This has no bearing at all on the question of overall correctness, which is what memory safety ultimately aims to serve. That is why there's no consensus over it.

I was referring to this quote of yours above: “Zig has a pretty good memory safety story”. Which is empirically not so good.

> You can't simultaneously argue that unsafe languages are categorically bad and also use unsafe rust as an argument against rust's limitations. Unsafe is either bad or it isn't.

I'm not arguing philosophically. I'm arguing from a safety viewpoint. A language that's 100% unsafe is worse than a language that's 1% unsafe.

Saying it's not perfectly safe is sophistry. Nothing is perfectly safe, but you still don't hand out your sensitive bank information to random person on the Internet/street/etc.

> Again, once you use unsafe Rust, why not just use an unsafe language?

Assume data race happen. Would you prefer to audit 30k lines or 3? Unsafe language is unsafe everywhere. In Rust, you can limit your search to unsafe regions.

> Static analysis tools outside of the language would also be the way you would check for UB and unsafe behavior in languages like C and Zig.

Define outside language? Miri is maintained by rust-lang team. And Clippy and so on. Sure valgrind and so forth aren't, but their checks are somewhat complementary.

> For instance, let's say I am making an HPC program for identifying pricing arbitrage in the market which generates 10 million dollars a day when it's operating. If it takes 10 days longer to implement in Rust, that cost me 100 million dollars. I am not going to care if it crashes twice a day because of an NPE I didn't catch.

Sure, but if your implementation has a data race error, that when triggered happens causing massive loss of funds. First you'll have to find the issue (good luck searching most of language and deps). Then you need to patch it to prevent future errors. And it can happen again. So maybe 3 days here, 5 days there, 4 days there, and so on.

Granted it's a contrived example, but hey... If you want HPC and safety use Java/C#/Lisp, no Rust necessary.

Point being - Strength of Rust isn't in speed of development, so much as in avoiding certain sets of bugs. And borrow checker isn't the only tool to achieve this.

> Depending on use-case.

On that I agree. If your game is one and done (no maintenance), no user content, no MP, basically worse that can happen is crash sure go ahead. Jams are in that way perfect candidates for small langs where speed of development is crucial.

I'd argue most sold games aren't one and done.

> I don't even know what to say to this. Spaces and punctuation got accepted because they're more ergonomic and universally accepted by consensus as the better solution for making text readable.

Keep in mind that in Rome everything was written without spaces for hundreds of years. From their POV the spaces would be just unnecessary fluff. And there are still languages that have little to no spaces, so spaces aren't even universally accepted. See Chinese and Japanese.

> Most system programmers do not program in rust.

I don't understand, this wasn't specific about just systems language? Going from C# to Zig is a safety downgrade (but a possible performance uplift). And GC langs have been used in OS implementations.

> There's no consensus that it has chosen the right tradeoffs.

Sure, but consensus is a matter of current status and it's not set in stone.

Status quo is C, which has null - a trillion dollar mistake (adjusted for inflation and software spread :P)

> What's your point? Python is not the easiest code to maintain...

My point that we use Python won in ML because allowing people to achieve value isn't the only important aspect. There are many aspects. Sure you get to pick your own, but I've seen too many CVEs caused by memory unsafety.

But safety and reducing footguns should be ideals for any language to strive. Reintroducing footguns? What's next? Return of GOTO Spaghetti monster.