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.