1. 32
    1. 4

      Ranged numeric types, especially combined with linear types (as per my understanding; not a PLT expert) are a pretty awesome feature, it’s encouraging to see the idea being put into practical use.

      Unfortunately, the language seems to target an extremely narrow niche. I get that it’s a Google-internal project, and that niche is probably worth a cool $100M+ for them so there’s no pressure to expand its scope.

      Things that look like they’re dealbreakers for just about anything I’d like to use this for:

      • It looks like you’re only supposed to implement “leaf” libraries with it. It doesn’t look like there’s any kind of FFI, so if what I want to implement would require internally calling down to a C API for another (system) library, I’d effectively have to extend the language or standard library.
      • Memory safety is primarily achieved by not supporting dynamic memory allocations. It’d be a different story if combined with something like Rust’s borrow checker. I mean the support for linear types is already there to some extent…

      On the other hand, the ability to compile down to C is a bonus compared to Rust.

      I guess if you fix those 2 aspects I mentioned you probably end up with ATS anyway… and I have to admit I haven’t quite wrapped my head around that one yet.

      1. 1

        Ranged numeric types…it’s encouraging to see the idea being put into practical use.

        Pascal had subrange types in 1970.

        1. 1

          It’s been a few decades since I worked with Pascal, but I’m fairly sure Pascal’s support wasn’t as comprehensive as this is. Without linear types, they’re fairly cumbersome to use comprehensively. Specifically, I’m talking about:

          if (a < 200)
             // inside here, a's type is automatically restricted with an upper bound of 200 exclusive

          I don’t think Pascal supported this?