Not Explicit

I'm torn on this. I prefer explicit types in declarations as well, but very much like the convenience of inferred types. I find myself thinking, though, that the demand for the convenience of inferred types in these languages is a result of the verbosity in the type specifications themselves, usually with generics (Rust) or templates (C++). I rarely use the convenience of inferred types for concise type labels (e.g. non-generic structs, integers, etc.). Maybe this is a deficiency in the languages' designs?

I think there is a lot of useful information, within a function body, that can be created by inclusion of specific types. I don't think your decision was bad. People obviously like the language and the compiler's type inference systems are apparently extremely advanced.

In my opinion this is an anti-pattern for beginning developers and complicates the development of IDEs. This is for a number of reasons.

    1. Saving screen space is not a good reason to omit types

Long long ago the people typing away at Bell Labs made these same decisions. All across the UNIX kernel and user space they used partial/shortened names. This did not help users nor did it help developers. K.T. is said to have joked that the missing "e" from "ceat" is his biggest regret from the UNIX system.

We don't use 80x40 terminal displays and most of us type at faster than 25wpm. The space or time saved when writing...

    let people = new List();

When compared to...

    List people = new List();

Is not worth it in my opinion. This is even more so when you have situations like this

    List people = getGuestList();

vs

    let people = getGuestList();

In my opinion this is considerably more difficult to understand what type I'm working with. I have to now go and read the header for `getGuestList()` to find out what I can do with my `people` variable.

    2. IDE development will be more difficult.

This is minor, and will eventually be a solved problem, but writing an IDE that doesn't have immediate type information for everything in scope will be more complicated. Some may even say this might be impossible to accomplish via static analysis. Because of this the development of things like the RLS are much more difficult.

    3. The seasoned but new developer will struggle to find how things work.

When I pick up a new programming language at this stage in my career I no longer read through a book or documentation. I sit down and I try and accomplish a project. I find a task, find some code that does the subsets of the problems I want to solve, read that code, then implement my own solutions with the knowledge that I've gained. With Rust this approach doesn't work (for me). I have not been able to pick up Rust. I don't know what kind of objects are being used to hold which kind of data without reading almost every single line of code in the program (or at least everything accessible from the scope I am interested in).

In Java, C, etc I get some clue as to what's going on. In Java I need to only read maybe the first few words on every line to get an idea of what will happen or what is being used.

    public boolean isOnGuestList(String person) {
        List people = ...;
        List plusOnes = ...;
        return people.contains(person) || plusOnes.contains(person);
    }

I might not know what a List is but I can easily find out.

This biggest effect this has is that since I have been programming for a long time I have an intuition where certain language features will be used. Every* language has a KV store, a list, some way to interact with file descriptors, etc. I know what kinds of programs will do those things and I can look at those programs for reference. Unfortunately for languages like Rust I need to already know the general types that people use to understand the code. All I would see is...

    fn isOnGuestList(person: string) -> string {
        let people = ...;
        let plusOnes = ...;
        people.contains(person) || plusOnes.contains(person);
    }

> We don't use 80x40 terminal displays and most of us type at faster than 25wpm.

But reading and understanding code is still the most time-consuming part of programming, and when a function or class stops fitting on a single screen that's a huge hit to readability, whether that's 40 lines or 100.

> have to now go and read the header for `getGuestList()` to find out what I can do with my `people` variable.

No you don't, you just mouseover it or press a simple key shortcut and get it.

> This is minor, and will eventually be a solved problem, but writing an IDE that doesn't have immediate type information for everything in scope will be more complicated. Some may even say this might be impossible to accomplish via static analysis.

Huh? The IDE already has to do all the work anyway because it already has to compile and check the code. It's no harder for the IDE to use the inferred types, assuming the compiler was suitably modular.

> When I pick up a new programming language at this stage in my career I no longer read through a book or documentation. I sit down and I try and accomplish a project. I find a task, find some code that does the subsets of the problems I want to solve, read that code, then implement my own solutions with the knowledge that I've gained. With Rust this approach doesn't work (for me). I have not been able to pick up Rust. I don't know what kind of objects are being used to hold which kind of data without reading almost every single line of code in the program (or at least everything accessible from the scope I am interested in).

Switching from an Algol-family language to an ML-family language is a bigger change than switching between two Algol-family languages. It's going to be more work. But improvements are always changes.

> Unfortunately for languages like Rust I need to already know the general types that people use to understand the code. All I would see is...

Why's that a problem? Particularly since you said you already know Python, isn't that a perfectly sensible bit of code to read? Write what you would in Python, but get faster feedback on whether it's right (compile failure rather than runtime error) - isn't that something worthwhile?

Another way to think about it is whether the IDE can do it for you. As a Java dev (who is admittedly a bit of a slave to IntelliJ) this is a huge part of my programming experience.

> vec something = new;

> might be better than

> let something = new vec;

I don't think this is right at all. The name of the variable is far more important than its type - ideally, the name of the variable should include a hint as to the nature of its type, whether it's explicit (e.g. parent and child in a tree navigation function are obviously references to the tree node type that is being navigated over) or very lightly suggested (e.g. pluralization, like children for a list of child things). The actual type is of secondary importance, chosen for implementation reasons (e.g. a map might be hash-based or tree-based, or a list might be a view over some other list, synthesized from some foreign collection, or a wrapper around an array in memory).

For me, the name of the variable is of paramount importance for understanding the code. The type is very secondary. Types are usually in two buckets: domain-specific (so the name typically is highly relevant to what's being done and is often the same as the type name or an abbreviation or agglutination), or common denominator library types (typically collections, strings, primitives, that kind of thing) where the name of the variable implies the type.

The name is the thing that you see over and over again in the code. You also don't get to see the type when you call a method. So readable code needs good consistent names that make type annotations helpful but far from mandatory for comprehension.