1. 32
  1.  

  2. 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?