1. 74
  1.  

  2. 15

    Will there be an anteup tool…

    1. 15

      I’m worried that ante may be trying to do too much at once. It is trying to innovate on at least:

      • the syntax
      • ergonomics static verification with SMT-checked refinement types
      • low-level aspects / efficiency among functional languages, by playing on memory layout (hinted at but not described in the documentation) and memory management (lifetime/region inference)
      • pervasive use of effect handlers as an effect-definition feature

      This is a lot of topics (some of the research-level or at least very difficult) to tackle at the same time! And several of those goals are in tension, for example it is extra difficult to verify effect-handling programs or to make them efficient. (Efficient implementation of effect handlers that make them competitive with built-in effects for generators, etc. is an active research area).

      If it all works out, great! But there is a good chance that the people (person ?) working on this end up spread much too thin and not clearly meet any of the goal that have been set.

      1. 3

        I didn’t want to say anything in particular about it but I’m glad to see my thoughts are pretty much what’s on other’s minds too.

        This is why I’ve really come to love Standard ML. it hits the sweetest of spots: speed, syntax, low level, type checking, all achievable by one person. If Ante can achieve Standard ML levels of implementation simplicity it will go far… Otherwise, no one has any reason to use it over something like Rust which has huge developer buy-in.

        1. 3

          SML is not low level like this, surely, though?

          1. 1

            Why “surely”? It has references and FFI. I looked at Ante’s language reference quickly and it doesn’t look to do anything like C’s union or using bitfields. Actually it specifies references exactly like SML: ref keyword.

            You could write a device driver in SML for sure with assembly and its FFI.

            1. 3

              Actually it specifies references exactly like SML: ref keyword.

              it seems to me that, while the two features in SML and ante share name and syntax, they have completely different semantics. Different in the sense of orthogonal — these are completely independent language features.

              Refs in SML are for storing mutable data. They are analogous to RefCell in Rust — something with a set operation, which nonetheless exists in pure functional world.

              Refs in ante are pointers: values are unboxed, and you, as a programmer, have a choice between passing/returning stuff by value or by reference.

              1. 1

                I didn’t see anything which signified being able to set the pointer to an arbitrary memory address and access it - could you please point me to it? (hehe) If so then for sure it’s not the same. ref in SML is as you said more or less: lets you box values.

                Otherwise the semantics between them is pretty much the same… as far as I can tell anyway

                1. 4

                  ref in SML is as you said more or less: lets you box values.

                  I am 0.9 sure this is wrong. In SML, refs denote mutability, they are orthogonal to in-memory representation.

                  As for in-memory representation, as far as I know SML just doesn’t give you control over it. All values have the same size_of of a single pointer. In other words, everything is boxed anyway. As an observable effect of that, ints are 31 bit long, to implement small object optimization for them.

                  (*) of course, compiler can optimize and stack-allocate and SROA stuff, especially in SML land where closed world whole-program compilers are popular. But in general everything’s a pointer, and programmer doesn’t have control over that (like Java, and in contrast to go)

                  1. 3

                    actually i think (0.9 sure) you’re right too ;)

                  2. 1

                    I didn’t see anything which signified being able to set the pointer to an arbitrary memory address and access it

                    If it doesn’t have this then it’s not low level at all…

                    OTOH, many high level languages can do this, such as Haskell.

        2. 7

          Reminds be a bit about roc, which also tries to be a small and efficient functional language.

          1. 1

            https://www.roc-lang.org has links to a few more videos but sadly there’s no written material about it.

          2. 5

            Saw it was written in Rust and wondered if it was already tracked on langs-in-rust, and it is (though I should update its star count)! https://github.com/alilleybrinker/langs-in-rust

            Cool language; seems ambitious in its design!

            1. 2

              Ante aims to help bridge the gap between low-level languages like C++/Rust and higher level garbage-collected languages like Java, OCaml, or Haskell.

              Isn’t rust already this? Can write it as high level or low level depending on your needs and taste.

              1. 3

                But even high-level Rust code isn’t garbage-collected, and that imposes significant effort (and design constraints IMHO) on the developer. One of Ante’s claims is to manage memory with lower conceptual overhead.

                I guess you could say both Ante and Rust bridge the gap, just at different locations. (Same is true of Nim — it’s at a similar level as Rust, but its automatic ref-counting sets it apart.)

                1. 2

                  Rust code can be garbage collected, but since there’s nothing in stdlib for it I guess that not fair it’s like saying “C can be garbage collected”

                  Arc and/or calling clone a lot is pretty close for many purposes, but you’re right it’s not “all the way”