pcwalton

It's interesting that so many replies in this thread (and indeed, most Zig threads) are along the lines of "yes, it doesn't do X today, but Zig could just add X". I'd really like to see arguments in favor of Zig that rely on what it can do today, rather than what it might do someday. After all, you don't extend Rust the same courtesy, and Zig is not that young of a language. And in PL circles Zig has a bit of a reputation for promising things that it has yet to deliver (e.g. static detection of potential stack overflows, which I'm convinced just can't be done in a useful way in the presence of higher order functions).

How do you typecheck generics, with type inference, with comptime?

Or, more generally, address all the issues raised in [1]. You're saying that comptime can fully replicate all the features that a proper generics system has, which is plainly false.

[1]: https://typesanitizer.com/blog/zig-generics.html

I’m nostalgic about old Unix too, but it’s just that: nostalgia. In reality, Unix was the system that brought us such elegant well-designed APIs as gets(3) and strtok(3).

What POSIX systems in actual use (not historical Unixes) don't have the long options? macOS' BSD utilities I guess?

You should visit Canada sometime. It's quite a nice country. British Columbia in particular is gorgeous.

Java only has tearing for double and long, which are POD types and so are irrelevant to memory safety. Go has tearing for pointer-like objects (interfaces, slices), which causes the memory safety problems.

Data races on those pointer-like objects are undefined behavior in Go, whereas there isn't something comparable in Java. The reason why Go is considered a memory safe language is actually pretty mundane: it's simply that the data race issues are pretty hard to exploit in practice for a variety of reasons.

Because the article isn't about the identity of Asahi Lina. That may or may not be an interesting article (I'm deliberately being neutral so as not to spark off-topic discussion), but it isn't the topic of this article.

> Presumably with inline assembly both languages can emit what is effectively the same machine code. Is the Rust compiler a better optimizing compiler than C compilers?

rustc uses LLVM just as clang does, so to a first approximation they're the same. For any given LLVM IR you can mostly write equivalent Rust and C++ that causes the respective compiler to emit it (the switch fallthrough thing mentioned in the article is interesting though!) So if you're talking about what's possible (as opposed to what's idiomatic), the question of "which language is faster" isn't very interesting.

Ghidra is a fine example from the US government.

Chrome does prohibit ad blockers on mobile.

Arguably, Stack Clash is just a compiler bug--recursive code shouldn't be able to jump the guard pages. This was fixed in Clang in 2021 [1], in GCC even earlier, and in MSVC earlier than that.

[1]: https://blog.llvm.org/posts/2021-01-05-stack-clash-protectio...

That warning doesn't ensure that there's no recursion, as the caveats point out. Indeed, it's trivial to show that ensuring there's no recursion is impossible as long as you have function pointers. (This is also why languages that claim to be working on a solution to prevent recursion statically are going to fail.)

Abolishing the DoE is wildly unpopular, even among Republicans: https://all4ed.org/publication/voters-views-on-education-in-...

You're in a significant minority even within your own party.

Well, RIVA 128 didn't even have multitexturing, so not much of that is going to be applicable. I don't think that Voodoo era chips even used Pineda rasterization as that article details; they did fancy scanline rasterization.

From a glance it looks fairly standard for a fixed-function GPU of the day. These GPUs were primitive by modern standards; they didn't even have hardware T&L, meaning everything essentially had to be converted from 3D to 2D on the CPU†. The weirdest part is per-polygon mipmapping, which is not normal. (I didn't even know anyone even did this; it's clearly going to look terrible in many common cases, such as large textured floors. That being said, I can understand why they'd do this if they were in a rush; calculating screen space derivatives in both X and Y, as required for per-pixel mipmapping, is really annoying with a scanline algorithm, which they were probably using as Pineda rasterization hadn't caught on yet.)

†I know that normalized device coordinates are still 3D, so "converting 3D to 2D" is technically wrong, but it conveys the right intuition.

3dfx' proprietary Glide was still very popular in 1997. UltraHLE wouldn't come out until 1999 and that was famously Glide only.

Yeah, I was looking at infantry.cpp, and the quality is actually very good for 90s game code. The documentation is good, it's decently well-formatted, and there are assertions. Nice counterexample to the "all successful games have terrible code" conventional wisdom.

He didn't completely whiff it? The probabilities that Nate and the current team at 538 have given over the years are empirically very accurate. 538 is quite transparent about this stuff [1]. Their Brier skill score for Presidential elections is 0.8243.

[1]: https://projects.fivethirtyeight.com/checking-our-work/

> So we voted for Tulsi to take a chain saw to the CIA.

If "we" means "the minority MAGA base", then sure. But Gabbard has never been popular. Her favorability is at -13.7 in the RCP average [1], was never above water even during the heat of the campaign, and is at about -20 now.

[1]: https://www.realclearpolitics.com/epolls/other/tulsi_gabbard...

I'm actually quite impressed that LLVM is able to convert that dependent load of an array into a switch statement.

So wait, I'm supposed to wish success for everything, say, Gavin Newsom does because I voted for him? Is that how it works?

> It was used as a hash, and every TEA key has an equivalent alter-ego key or something, I forget the details.

It's that flipping bit 16 and 31 of a 32-bit word makes the end TEA state the same [1].

[1]: https://events.ccc.de/congress/2005/fahrplan/attachments/591...

The borrow checker is more influenced by substructural type systems, such as the one in the MLKit [1] and Cyclone.

[1]: http://mlton.org/Regions

I suspect that LeetCode is a factor too. Even if the hiring standards haven't deteriorated, the fact that you can "study to the test" nowadays in ways you couldn't in 2012 selects for a different set of candidates.

> I wonder if any of those who claim that the RISC-V ISA is simple can remember without searching the documentation how to implement the checks for integer overflow after each arithmetic operation.

I mean, I can't give you the Hacker's Delight magic numbers for expressing integer division by a constant via multiplication on AArch64 or x86-64 off the top of my head either, but that's what we have compilers for. The fact that you sometimes have to look up how to do simple things is just part of programming.

C and C++ (the latter unofficially, IIRC) have this with bitfield types, and they aren't very well loved, precisely because they aren't addressable.

At that cost of having your loads no longer be hardware load instructions, which would be bad for performance.

If your pointers have to have a bit offset, then now a pointer isn't just 1 hardware word, which would be odd to say the least for a systems language. (It would also be slow, because making a load anything other than a load is something you really don't want to do; you would lose the ability to fold into addressing modes on x86 in many cases for example.)

If some pointers have a bit offset but others don't, OK, I guess, but I'd argue that at that point it'd be a cleaner design to just have a "pointer plus bit offset" be a separate type from "regular pointer". And that would get back to the problem that you would have a type that you couldn't take a "regular" pointer to.

I'm not convinced, actually. The problem is that every proposal for safe C++ that I've seen sacrifices compatibility with the broader C++ ecosystem. Yes, you could graft borrow checking onto a C++-like semantics, but what you would end up creating is an incompatible dialect of C++--essentially a new language. So the resulting ecosystem would actually be smaller than that of Rust.

> Zig is good at all the areas Rust is good at.

Not memory safety.

> Zig is also good at game development which Rust is not good at.

Let's see. Over just the past year in Bevy I've implemented GPU driven rendering, two-phase GPU occlusion culling, specular tints and maps, clustered decals, multi-draw, bindless textures, mixed lighting, bindless lightmaps, glXF support, skinned mesh batching, light probe clustering, visibility ranges with dithering, percentage-closer soft shadows, additive animation blending, generalized animation, animation masks, offset allocation, volumetric fog, the postprocessing infrastructure, chromatic aberration, SMAA, PBR anisotropy, skinned motion vectors, screen-space reflections, depth of field, clearcoat, filmic color grading, GPU frustum culling, alpha-to-coverage, percentage-closer filtering, animation graphs, and irradiance volumes. In addition to extremely rapid general engine progress, there have also successful titles, such as Tiny Glade.

Whether Rust can be a productive language for game development was an interesting question a few years ago. At this point the answer is fairly clear.