I was confused by that too. Under the "Types" page of the guide[1], they say:

> Every value in Acton is of a certain data type, which tells Acton what kind of data is being specified so it knows how to work with the data. Acton is a statically typed language, which means the type of all values must be known when we compile the program. Unlike many traditional languges like Java or C++, where types must be explicitly stated everywhere, we can write most Acton programs without types. The Acton compiler features a powerful type inferencer which will infer the types used in the program.

> Acton implements the Hindley-Milner (HM) type system, which is common in languages with static types, like Haskell and Rust. Acton extends further from HM to support additional features.

The language also has inheritance (and thus presumably subtyping), protocols (interfaces, I think), and generics. Historically, those features have not played nice with HM inference, so I'm not sure what's going on there.

[1]: https://acton.guide/types/intro.html

Static: the types could be inferred. I haven't looked too closely yet.

Strong: Python is strongly typed with a similar syntax.

Strong vs weak typing means "how much information does the type system provide to me." Static vs weak typing means "when does the type system do its work."

I see no reason why a language with syntax like this could not be strongly typed. The static part is hard to claim until the type inference rules are explained.

I think the word I'm looking for is explicit. It's not required to have explicit types in the functions, which I find disappointing.

why? type inference is generally quite nice. Makes for clean code. One of the things I've enjoyed from using things like F#. All the advantages of strong and static typing without the cruft.

It depends how it's applied. I like type inference when I'm defining a variable, for example. In Go, I can just write this:

    message := "hello world"

...and the compiler knows it's a string, and I know it's a string because I can just hover it with my mouse and my IDE will tell me that. That's good enough for me.

But when we are talking about functions..:

    # some fictional function I just came up with
    def install_requirements(dependencies, opts):
        run_setup(dependencies, opts)
        return assert_requirements_installed(dependencies)

Now I'm confused. What is the data type of "dependencies" and "opts"? Is the IDE smart enough to tell me that? What if I'm building a function that assumes "dependencies" to be of type A, but the compiler thinks it can also be type "B"?

I don't know enough about compilers and type inference to know whether this is actually a problem in Acton or not. I wish they explained more. My gripe against this kind of inference is that it's impossible for my IDE to tell me what is being passed around. In Java, for example, I can CTRL+Click on a data type and the IDE will show me the definition; can Acton do the same?

It's about the same in Acton

    message = "hello world"

message is a `str` since we know the literal "hello world" is a str. Some literals can be multiple types, like 123 can be `int` or `u64` or some other fixed int type.

You can specify the type explicitly if you want to

    # some fictional function I just came up with
    def install_requirements(dependencies: set[str], opts: dict[str, str]):
        run_setup(dependencies, opts)
        return assert_requirements_installed(dependencies)

which makes it easier to read the code which is a little bit more involved. It also helps guide the type inferrence & checking. Hindley-Milner type checking is notorious for doing a good job at type unification and a lousy job at error messages. Acton is no exception and is arguably worse than many other users of HM implementations since it is relatively young and all effort have gone into actual type checking and not much into errors.

Broadly speaking, I think the modern solution to IDE insight into types is to implement an LSP that provides types and other information to the editor. Acton does not have an LSP but it will.

Cool. Thanks for explaining!

> In Java, for example, I can CTRL+Click on a data type and the IDE will show me the definition

Java doesn't track the types as well as HM does.

Specifically, if I treat a Stream as a Mappable, I lose the static type info, and can only get it back via casting.

In an HM language, e.g. Haskell, my object is statically a Stream type everywhere it's used, even if I'm doing Mappable stuff to it.

It could be both if all types are inferred.

I think Kotlin is an example of both.

In case you're not aware, Elixir is in the process of implementing gradual set-theoretic types.

https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...