pcwalton

I'm surprised that the article didn't mention that Richard Garfield (creator of Magic) himself has a Ph.D. in combinatorial mathematics. I imagine that, if he's aware of this, that he'd get a kick out of it.

My feeling is that dependent types add complexity to a language that's already well-known for having a complex type system, so I'm nervous about blowing the complexity budget. But I'm bullish on tools like Verus, Prusti, and Creusot because they allow people who need to write low-level unsafe code to prove their code safe, while keeping the complexity of the safety proofs localized to that code, so most Rust programmers don't need to worry about it. This allows verification of Rust code without surfacing complexity to most developers. We can have our cake and eat it too.

You can mutate variables at compile time in D. See the compile time Newton's method example: https://tour.dlang.org/tour/en/gems/compile-time-function-ev...

> The important thing is that the feature performs the duty of those other features.

Zig's comptime doesn't do everything that Rust (or Java, or C#, or Swift, etc.) generics do, and I know you know this given your background in type theory. Zig doesn't allow for the inference and type-directed method resolution that Rust or the above languages do, because the "generics" that you create using Zig comptime aren't typechecked until they're instantiated. You can improve the error messages using "comptime if" or whatever Zig calls it (at the cost of a lot of ergonomics), but the compiler still can't reliably typecheck the bodies of generic functions before the compiler does the comptime evaluation.

Now I imagine you think that this feature doesn't matter, or at least doesn't matter enough to be worth the complexity it adds to the compiler. (I disagree, of course, because I find reliable IDE autocomplete and inline error messages to be enormously useful when writing generic Rust functions.) But that's the entire point: Zig comptime is not performing the duty of generics; it's approximating generics in a way that offers a tradeoff.

When I first looked at Zig comptime, it didn't evoke the "magic of Lisp" at all in me (and I do share an appreciation of simplicity in programming languages, though I feel like Scheme offers more of that than Lisp). Rather, my reaction was "oh, this is basically just what D does", having played with D a decent amount in years prior. Nothing I've seen in the intervening years has changed that impression. Zig's metaprogramming features are a spin on metaprogramming facilities that D thoroughly explored over a decade before Zig came on the scene.

Edit: Here's an experiment. Start with D and start removing features: GC, the class system, exceptions, etc. etc. Do you get to something that's more or less Zig modulo syntax? From what I can tell, you do. That's what I mean by "not revolutionary".

I tried ChatGPT 4o to help me reverse engineer some game code with the symbols missing and the results were quite disappointing. To say it had a tendency to hallucinate is an understatement. It didn't have any clue what was going on.

For me, those AI tools are much better at saving me time looking up documentation when doing simple things where it has examples of the exact code pattern I'm looking for in its training set. ChatGPT is great at writing one-off Blender scripts for me to give to artists, for instance.

The point is that comptime isn't dependent types at all. If your types can't depend on runtime values, they aren't dependent types. It's something more like kind polymorphism in GHC (except more dynamically typed), something which GHC explicitly calls out as not dependent types. (Also it's 12 years old [1]).

[1]: https://www.seas.upenn.edu/~sweirich/papers/fckinds.pdf

That's still just a function of type ∀K∀L.K → L with a bound on K. From a type theory perspective, a comptime argument, when the function is used in such a way as to return a type, is not a value, even though it looks like one. Rather, true or false in this context is a type. (Yes, really. This is a good example of why Zig reusing the keyword "comptime" obscures the semantics.) If comptime true or comptime false were actually values, then you could put runtime values in there too.

I think another way to put it is that the fact that Zig reuses the keyword "comptime" to denote type-level parameters and to denote compile-time evaluation doesn't mean that there's only one feature. There are still two features (templates and CTFE), just two features that happen to use the same keyword.

> This is one half of the innovation, dependent-types lite.

But that's not dependent types. Dependent types are types that depend on values. If all the arguments to a function are either types or values, then you don't have dependent types: you have kind polymorphism, as implemented for example in GHC extensions [1].

> The second half is how every other major feature is expressed _directly_ via comptime/partial evaluation, not even syntax sugar is necessary. Generic, macros, and conditional compilation are the three big ones.

I'd argue that not having syntactic sugar is pretty minor, but reasonable people can differ I suppose.

[1]: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/poly...

But Zig's comptime only approximates the features you mentioned; it doesn't fully implement them. Which is what the original article is saying. To use your analogy, using a touchscreen to eliminate a keyboard isn't very impressive if your touchscreen keyboard is missing keys.

If you say that incomplete implementations count, then I could argue that the C preprocessor subsumes generics/templates, interfaces/typeclasses†, macros, and conditional compilation.

†Exercise for the reader: build a generics system in the C preprocessor that #error's out if the wrong type is passed using the trick in [1].

[1]: https://stackoverflow.com/a/45450646

Well, if you strip away the curly braces and return statement, that's just a regular type definition. Modeling generic types as functions from types to types is just System F, which goes back to 1975. Turing-complete type-level programming is common in tons of languages, from TypeScript to Scala to Haskell.

I think the innovation here is imperative type-level programming--languages that support type-level programming are typically functional languages, or functional languages at the type level. Certainly interesting, but not revolutionary IMO.

When we're responding to quite valid points about other languages having essentially the same features as Zig with subjective claims about ergonomics, the idea that Zig comptime is "revolutionary" is looking awfully flimsy. I agree with Walter: Zig isn't doing anything novel. Picking some features while leaving others out is something that every language does; if doing that is enough to make a language "revolutionary", then every language is revolutionary. The reality is a lot simpler and more boring: for Zig enthusiasts, the set of features that Zig has appeals to them. Just like enthusiasts of every programming language.

For fun, try searching YouTube for "speaking latin at the vatican". It's hard to find people who can speak it even there!

Stolen from one of the mathematician Underwood Dudley's essays on cranks :)

> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compiler, dudes.

That exists; it's called garbage collection.

If you don't want the performance characteristics of garbage collection, something has to give. Either you sacrifice memory safety or you accept a more restrictive paradigm than GC'd languages give you. For some reason, programming language enthusiasts think that if you think really hard, every issue has some solution out there without any drawbacks at all just waiting to be found. But in fact, creating a system that has zero runtime overhead and unlimited aliasing with a mutable heap is as impossible as finding two even numbers whose sum is odd.

> I wonder if this kind of trick can be implemented in rustc itself in a more automated fashion to benefit more projects.

It partially is, with codegen units. The problem is that you can't generally do that until codegen time, because of circular dependencies.

I mean, if what you want is P4-class performance, the modern semiconductor industry is excellent at delivering that with low TDP. An Apple A18 Pro [1] gives you over 7x the single thread performance of a Pentium 4 Extreme Edition [2] at 8 W TDP, compared to 115 W for the latter.

[1]: https://www.cpubenchmark.net/cpu.php?cpu=Apple+A18+Pro&id=62...

[2]: https://www.cpubenchmark.net/cpu.php?cpu=Intel+Pentium+4+3.7...

It's Bournegol [1]!

[1]: https://oldhome.schmorp.de/marc/bournegol.html

Not sure why you think WGSL is owned by the Rust community--it's clearly owned by the W3C. (That's part of why it moves so slowly.) WESL [1] is the community-owned set of extensions to WGSL that, while incomplete, promises to move it much closer to Rust.

[1]: https://github.com/wgsl-tooling-wg/wesl-spec

That's a great article. Niche optimization might seem minor, but it actually results in substantial memory usage savings in real-world Rust applications, because idiomatic Rust uses enums everywhere.

> But, more importantly, the amount of cycles that would be needed to text-wrap most websites is effectively zero.

I've measured this, and no, it's not. What you're missing is the complexities of typesetting Unicode and OpenType, where GSUB/GPOS tables, bidi, ruby text, etc. combine to make typesetting quite complex and expensive. HarfBuzz is 290,000 lines of code for a reason. Typesetting Latin-only text in Times New Roman is quick, sure, but that doesn't cut it nowadays.

Remember the days of Zuck saying "going with HTML5 instead of native was our biggest mistake"? Though hardware improvements have done a lot to reduce the perceptible performance gap between native and the Web, browser developers haven't forgotten those days, and layout is often high in the profile.

This is sort of true in theory, but in practice there's a major difference in that nearly all the libraries in Swift use a reference-counted (i.e. GC'd) shared-everything model, while in Rust nearly all the libraries use ownership and borrowing. The "normal path" of least friction in Swift is a reference-counted world, while the "normal path" in Rust is the ownership-and-borrowing world.

This is not a knock on Swift--it's really the inevitable outcome of seamless compatibility with the COM-like model of Objective-C and Core Foundation being a guiding principle of the language.

Rayiner of 10 years ago started his arguments from axioms other than "the Republican Party is correct" as he does now. I miss old Rayiner. His arguments against the Democratic position on e.g. Citizens United and Bush v. Gore were persuasive back then. Nowadays virtually nothing he says is persuasive, because it's incredibly obvious that he's starting from the position that the Republican Party is correct and working backwards from there.

(He's also getting about as close as you can get to the "out-and-out racism" line as you can get without maybe technically crossing it. Though I think he did cross it when it comes to Irish Catholics.)

I notice that you've retreated to cherry picking polls on specific issues now that Trump's overall approval rating according to poll aggregators is negative (in record time, in fact, with the exception of Trump's first term).

What does "unspecified" mean in this context? If you mean "the value of a signed integer is unspecified if it overflows", then I can still construct cases in which you lose the optimization that widens a loop induction variable from 32-bit to 64-bit. For example, take this code:

    for (int i = 0; i != n; i++)
        sum += a[i];

If n is -2, will this function include the element at a[(uint64_t)INT_MAX + 1] in the sum? If signed overflow is UB, then the answer is "maybe", and thus i and n can legally be promoted to 64-bit. If signed overflow is unspecified, but the result must still fit in a 32-bit integer, then the answer is "no", and i and n can't legally be promoted.

> But if -fwrapv semantics were mandated by spec, then presumably compilers would at least hardcode a check for such a common optimization (if they are not doing so already).

I don't know what this means. The optimization becomes invalid if fwrapv is mandated, so compilers can't do it anymore.

> Even if it is the most common method in text books (I’m not sure that’s true), it’s also almost always wrong. The index must always be sized to fit what you’re indexing over.

"The code was wrong, so it was OK that I made it slower" is a message board argument, not a business argument.

> As for your compiler statement — yes. At least at Apple, there is ongoing clang compiler work, focused on security, that actively makes things slower, and there has been for years.

The performance of code that runs on consumer devices has less of a measurable economic impact than that of code that runs on the server.

Have you measured the performance cost? I highly suspect it is not negligible, given that it's the most common way to write inner loops, which are the most performance-sensitive type of code.

> And obviously there are better justifications for this than "we made the semantics of the language easier for programming language nerds to understand".

There are not. For all the noise that we make on message boards about signed overflow being UB, there are very few actual security problems traceable to it. The problems from it are largely theoretical.

That entire blog post talking about the 0.3% regression illustrates just how much of an effort it is, and how unusual it is, to make those kinds of changes. The reason why Google engineers managed to justify that change is that memory safety results in actual measurable security improvements by enforcing spatial safety. Signed overflow being UB just doesn't make the cut (and let's be clear: at that scale the cost of a 0.3% regression is measured in millions per year).