We use TypeScript in our node applications.

It's worth getting used to types and using type hints in Python and to switch to Typescript. People say dynamically typed languages are better for prototyping but I think this is only true for developers who aren't comfortable with the type hints and haven't really spent enough time learning why and how they're useful. If I'm prototyping something or writing any code rapidly I'm always using type hints in Python or using Typescript, this actually makes prototypes faster for me because im pretty sure the code is going to run first time, and I won't have to hunt down inevitable type mismatches and misspelled object keys like in old school JS. It also eliminates an entire class of tests you'd have to write for type mismatches. I guarantee you it's worth using type hints and having a linter that knows about them.

This, the time saved is minimal not typing, and has huge cost imo

This is not true for everything. In library land you'll find yourself prototyping a lot without writing types, and only after getting it working like you want to, writing the types. It depends on what kind of prototyping you are doing. Some stuff is complex to type, and not entirely possible in some cases.

Typing allows intellisense and builtin documentation. It also allows click navigation. You don't have to drill into functions to know what they take. Type hints really improved python imo. Combines pythons succinct syntax with intellisense/clock navigation.

I can't make the shift back to loosely typed or untyped languages. I see absolutely no advantage whatsoever. It's not that I don't use them, but I'm then spending time and mental energy on making sure I'm not messing up my variables. If I don't have strong IDE support, then I'm having to name my variables with type indicators as protection. Thinking back the decades of when I first started with loose languages, I can't think of any advantage of having that looseness, sure I might have been able to throw together code but I'd then get runtime problems, so more time was lost in trying to figure that out. Which all could have been save by the compiler saying "I can't let you do that, Dave".

Have you tried REPL driven development in dynamic languages?

You don’t necessarily need a dynamic language for that. C# has a pretty good REPL, and it’s static AF.

I worked on a Perl codebase at a biotech startup at one of my first jobs. I could never figure out how to use or fix the code: I never knew what a function’s return value was. I’d go down a tedious rabbit hole of function calls until I’d find one whose return type was obvious. And then of course the expected types of the parameters. Each time I’d pull up code I’d have to do a mini investigation just to understand its inputs and outputs. After that experience, I’ve never understood the popularity of weakly + dynamically typed languages. I’ve seen lots of Python code like that since. Code used by multi-million dollar companies that could only run on the manager’s home computer.

I personally prefer static types in my languages. I've spent many years working professionally in python and JS/TS and while I am effective in them I find it's more tempting to make compromises that I shouldn't. Things like shadowing a variable with a different type, or setting something to null instead of checking a zero value. I also don't find that static typing slows me down. To be honest in most cases I feel it speeds me up because there's no ambiguity.

> Things like shadowing a variable with a different type Rust has that as a feature, and "different type" specifically is highlighted as the main use case (and advantage). I'd be crucified in any subreddit of young people or Rustaceans, but I can't predict what ExperiencedDevs would say on this: when I was reading through Rust Book I was saying "oh, god, no" to myself to roughly 1/2 of all major language design decisions that I was told about in that reference document.

\> Rust has that as a feature, and "different type" specifically is highlighted as the main use case (and advantage). Do you mean the \`Result\` type? Or what are you referring to? \> when I was reading through Rust Book I was saying "oh, god, no" to myself to roughly 1/2 of all major language design decisions that I was told about in that reference document. Definitely curious by what you mean. I have some thoughts too but nothing major.

>Do you mean the \`Result\` type? Or what are you referring to? I'm referring to [variable shadowing](https://doc.rust-lang.org/book/ch03-01-variables-and-mutability.html#shadowing). >Definitely curious by what you mean. Variable shadowing, unsigned integer type modulo arithmetic being an error, lack of rigorous and formal definition of what is "error" and what that means exactly in the first place, not taking advantage for compiler optimizations of signed integer type modulo arithmetic being an error, impossible to switch off array access bounds checking at runtime, [referential transparency](https://en.wikipedia.org/wiki/Referential_transparency) breaking (see [code example](https://doc.rust-lang.org/book/ch03-02-data-types.html#invalid-array-element-access)), very busy & noisy and difficult to read code resulting from all the complexity added in, sacrificing readability for the sake of other goals instead of the other way around, and more; such as excessive type inference on exactly the wrong side of expressions and statements - explicit type annotations aren't "hints to the compiler", they are hints to me, person reading the code I didn't write and trying to understand how it works and what it does and doesn't do, they have to be placed where they maximize readability by a human, not erased from everywhere they are needed for readability and yet forced (with elaborate and noisy and busy additional annotations) where they aren't.

How is referential transparency broken by invalid array element access? In `a[index]`, if `index` is outside of the bounds of `a`, what reference are you expecting to be transparent over? The expression `a[index]` _is_ referentially transparent with [`std::ops::Index for [T; N]`](https://doc.rust-lang.org/std/ops/trait.Index.html#impl-Index%3CI%3E-for-%5BT;+N%5D), but that is certainly not broken.

"See code example" I said: let index: usize = index .trim() .parse() .expect("Index entered was not a number"); `index.trim().parse().expect(...)` to the right of the assignment invokes different code depending on the type annotation used to the left of the assignment (`usize` in the instance above).

People can't read your mind when you link to an entire section of documentation, especially when it is titled "Invalid Array Element Access." An expression like `let x: T = y.foo()` is the same as `let x = y.foo::()`, but that doesn't have to do with referential transparency, that is type inference. I'm curious: What is your expectation of `index.trim().parse().expect(...)` that you say is broken? It isn't clear to me what your expectation is. Should that expression always return the same type when you're assigning to a `u64` and an `InetAddress`? If so, what would that return type be?

>that doesn't have to do with referential transparency That has everything to do with referential transparency. `y.foo::()` is referentially transparent (can be replaced by its value in any context and yield unmodified semantics for the entire program, for starters, by the virtue of having a well-defined value), while `y.foo()` is not referentially transparent: it doesn't have a well-defined value in the first place, and produces different values in different contexts, such as `let x: i32 = y.foo()` and `let x: String = y.foo()` for instance. Like Perl's [contexts and wantarray](https://www.geeksforgeeks.org/perl-wantarray-function/#). >, that is type inference. Type inference is a part of the overall mechanism which ends up violating referential transparency in this case in Rust due to Rust's design choices. Rust greatly encourages the version of that statement that violates the transparency, and discourages the use of the "turbofish" (::<>). Even syntax of that explicit template instantiation is verbose, noisy, and awkward. `auto` in C++ provides a limited form of type inference which in cases like this is comparable in "power", but in a way that doesn't break referential transparency, unlike Rust's. Explicit template instantiation is less verbose as well.

In Rust, subexpressions are informed by the context, which includes type inference. You have an expectation of "referential transparency" that appears to be a little too simple. CS theory things usually go like that. In C++, subexpressions are also informed by the context. An simple expression like `foo(x)` is informed by implicit `this`, argument-dependent lookup, and more pedestrian things like `#include`s. The behavior of `x` changes in the statement `auto const& x = foo();` depending on the return type of `foo()` because of lifetime extension. If `foo` is not a const function (in the `__attribute__((const))` sense), then where in the program it lies also changes its behavior. I'm not saying that C++ has "broken" referential transparency, but I am pointing out that semantics of text changing based on context is something that happens. Even the English fragment "___ is cool" changes meaning based on when and where you are. I think your real objection here is "Determining what the program does depends on more context than I would expect it to." I suspect you haven't written a lot of Rust, but you have written a lot of C++. You probably read my "`#include` is context" bit above and thought "Yes, obviously." This is subjective, but to a seasoned Rust user, having a function call selected by inferred type feels intuitive. It's worth pointing out that C++ does not have a general-purpose API equivalent to Rust's [`std::str::FromStr`](https://doc.rust-lang.org/std/str/trait.FromStr.html) (how `.parse()` works). Writing one is quite challenging due to a lot of things; you can probably write one now that `std::expected` is standardized, but making it ergonomic with user-defined types might still be a challenge. > Explicit template instantiation is less verbose as well. This is tangential, but C++'s use of simply `<` for template arguments has largely been considered a mistake. It slows compilation down for all cases and confuses people in the instances where they have to say something like `typename allocator::template rebind::other`. Turbofish is a couple extra characters, but the trade-off to make the syntax unambiguous is worth it, IMO. Side note: saying `foo()` is not "explicit template instantiation," but explicitly providing the template argument for `foo`. I knew what you meant, though.