Crabtime: Zig’s Comptime in Rust

It's scary how good TS is at inferring the type, it'll even infer an instance of a class from a literal, so the interop with class-based code is almost seamless (almost: just don't try destructuring a "real" object or re-binding `this` on a static closure)

PHP basically has arrays and maps merged into one. Basically like Lua does.

It is pretty handy. Not sure what you find insane about it.

Of course the functions for arrays in the standard library are consistently inconsistent but that is just a general PHP thing. Isn't a big deal when you use an IDE.

A lot of the fixes are just removing the old broken way of doing things.

I'd still probably change 'for x of ...' to implicitly be 'const x' and require let if you are doing shenanigans with changing the values.

I am surprisingly ok with null and undefined. Null means not a thing, undefined means there is not even the notion of the thing.

I'm pretty sure there are more than three ways to declare a variable.

    x=5
    let x=5
    var x=5
    window.x=5
    window["x"]=5   //arguably the same as above.
    Object.defineProperty(window,"x",{value:5}) 
    Object.assign(window,{x:5})

To make matters even worse, there's a difference between setting an object property to undefined as opposed to omitting it. So one could say there are two different "undefined"s.

FWIW Python has three (default, nonlocal, and global).

And many languages have two.

  fn List(comptime T: type) type {
      return struct {
          items: []T,
          len: usize,
      };
  }

  // The generic List data structure can be instantiated by passing in a type:
  var buffer: [10]i32 = undefined;
  var list = List(i32){
      .items = &buffer,
      .len = 0,
  };

I barely participate in Hacker News anymore because it seems to have collectively lost the ability to extract meaning from words, unless an exhausting and totally excessive amount of attention is put into satisfying a misplaced sense of precision. There's no intellectual charity left and it sucks.

    fn MyType(T: type, comptime tag: [] u8, comptime count: usize) type {
      const capitalized = some_module.capitalize(tag);
      return struct{
        fn name() []const u8 {
          return capitalized;
        }
        array: [count]T,
      };
    }

you could probably cobble together an interface system with @comptimeError, but because of the time order of compilation stages, a failed method call will trigger the compiler error before your custom interface code, making it effectively useless for the 90% of cases you care about.

if I'm not mistaken in principle a small change to the compiler could amend this situation

Now, I'm not saying that Zig's choices always dominate and that all languages would be better off with its approach; far from it. I am saying that it introduces a novel tradeoff that is especially compelling in cases where not only generics but also macros, conditional compilation, and constexprs are otherwise required. In a language like Java these extra features are not required, and so Zig-style comptime would not simplify the language nearly as much.

But even in cases where all these features are needed, I don't think everyone would take Zig's choices over C++'s or Rust's, or vice-versa. To those, like me, for whom language complexity is the biggest problem with C++ or Ada (I used Ada in the nineties), Zig is a revolutionary step forward. I don't think any low-level language has ever been this simple while also being this expressive.

2. if you want to restrict the use of a function to comptime (why you would want to is beyond me) it is possible to do with @inComptime builtin.

the only tricky bit is that your function could try to call a function inaccessible to you because it's transitively restricted and you'd have a hard time noticing that from the code but it's not possible for that code to be compiled (barring errors by the zig team) so its more of an annoyance than a problem.

And you can add reflection [2]. So if you can add what you need via crates, is the language actually missing it or is it just not as ergonomic / performant as it needs to be or is it an education problem?

[1] https://docs.rs/typed-builder/latest/typed_builder/

[2] https://docs.rs/reflect/latest/reflect/

But in Rust that's not what you're getting. Rust's const fn is none of the options C++ decided it needed, Rust says if the parameters are themselves constants then we promise we can evaluate this at compile time and if appropriate we will -- this means we can use Rust's const fn where we'd use C++ consteval, but the function can also be called at runtime with variable parameters - and we can use Rust's const where we'd use C++ constinit, calling these const fn with constant parameters.

Because Rust is more explicit about safety of course, we can often get away with claiming some value is "constant" in C++ despite actually figuring out what it is at runtime, and Rust isn't OK with that, for example in my code

   const OVERSIZE: u32 = SIG_BITS.next_power_of_two() << 1;

   pub(super) static SHORT_80: LazyLock<Rational> = LazyLock::new(|| Rational::fraction(1, 80).unwrap());

Zig's comptime functions only run at compile time, so they can do extra things - in particular manipulating types - that you can't do if your function needs to run at runtime. (Don't mention dependent types.)

Just because a blog doesn't go full type theory doesn't disqualify it from drawing conclusions based on experience and limitations incurred during actual use.

Something can be very well typed but still suck to use.

Intution doesn't need to be based on formal understanding. See Table of elements. Created by grouping elements by behavior, it turned out to be based on electron orbital configuration.

Jesus, we very much aren't. The only real step improvement was in C++11 which added constexpr which (in the following years) gradually obviated the need for C++98 style TMP. But there really hasn't been much of a generational improvement since (OK, concepts I guess), and it remains cumbersome and error prone and difficult to debug.