Why make it complicated?

Good, now invent a keyword for variables you don't want to declare the type. And now that you have a mix of keywords and identifiers on the same place, you can never update your language again.

Also, make the function declarations not use a keyword too, so you get the full C-style madness of code that changes meaning depending on what libraries you import.

C++ has auto, which determines the type automatically.
I don't understand how not using a keyword to define a function causes the meaning to change depending on imports. I've never run into an issue like that before. Can you give an example?
- Some declarations terminate on the name, other declarations go one requiring more tokens. In C, the only thing that differentiates them is the type.
  Parenthesis in particular are completely ambiguous. But asterisks and square brackets also create problems.
In C#, you can use 'var' to have an impilict type variable.
String name = ""
var name = ""
- So, a keyword
Good, now invent a keyword for variables you don't want to declare the type.
auto. Also in D, you only need const if you don't want to specify a type for a constant, the compiler automatically inferres it to you.
Function declarations can be easily decyphered from context, no problem.

python:

a: str = 1

And then assign an int to a string just to mess with the interpreter.
- only the linter gives a hoot - the interpreter will happily leave that footgun for later

You're encoding more information in the typescript one. You're saying it's a string that will get updated.

Yeah, it's explicitly distinct from const a: String which says it won't change, and var a: String, which means this is legacy code that needs fixing.
- If there's only two options you only need one keyword
You aren't though. In most languages that use the latter declaration you would prefix the declaration with final or const or the like to specify it won't be updated.
That looks like rust ngl
- I was thinking the same thing. who would write typescript if they could just do Rust?
- It's also valid rust syntax.
  But if it were rust, this meme would not make sense, since you would just type let a and type inference would do its thing. Which is much more ergonomic.
C# has const string a = "Hello, World";
var in js is legacy, and default should be let, but changing that would break everything
Meanwhile if it's rust it's the opposite. (Variables that can change must specify that they are mutable)

The actual reason why let ... in syntax tends to not use C-style "type var" like syntax is because it's derived from the syntax type theory uses, and type theorists know about parameterised types. Generics, in C++ parlance, excuse my Haskell:

let foo :: Map Int String = mempty

We have an empty map, and it maps integers to Strings. We call it foo. Compare:

Map Int String foo = mempty

If nothing else, that's just awkward to read and while it may be grammatically unambiguous (a token is a name if it sits directly in front of =) parser error messages are going to suck. Map<Int,String> is also awkward but alas that's what we're stuck with in Rust because they reasoned that it would be cruel to put folks coming from C++ on angle bracket withdrawal. Also Rust has ML ancestry don't get me started on their type syntax.

There is also the thing where the compiler might mistake your c++ style variable declaration for a function, e.g.
String myfunction():
String myvariable();
How do you do nested parameterized types without it becoming ambiguous though? That's IMO the biggest advantage of the bracket syntax. For example: Map<Tuple<Int, Int, Int> Int>
- Map (Int, Int) Int. Kind of a bad example because tuples have special-case infix syntax, the general case would be Map Int (Either Int Bool). Follows the same exact syntax as function application just that types (by enforced convention) start upper case. Modulo technical wibbles to ensure that type inference is possible you can consider type constructors to be functions from types to types.
  ...function application syntax is a story in itself in Haskell because foo a b c gets desugared to (((foo a) b) c): There's only one-argument functions. If you want to have more arguments, accept an argument and return a function that accepts yet another argument. Then hide all that under syntactic sugar so that it looks innocent. And, of course, optimise it away when compiling. Thus you can write stuff like map (+5) xs in Haskell while other languages need the equivalent of map (\x -> x + 5) xs (imagine the \ is a lambda symbol).
Until now, I looked at let and thought, "maybe they just felt like doing it that way".
Makes a lot more sense now.

Because sometimes that let can be replaced by other things like const. Which can be managed statically by the machine and not by my (imperfect) ability to know if it's mutated or not

I think you can do const thing = ... as constto lock down the mutation?
- So is let in some languages. In Rust, you have to constantly opt out from immutability with let mut, which makes writing more procedural code feel like you're fighting with the compiler, and otherwise I don't really see the rationale behind full functional coding. I only had a bug caused only once by unwanted mutation, the hardest part fixing it was to learn the proper use of my debugger tool.
Ok but, in the second example you typically just put final or const in front of the type to denote immutability. I still don't see the advantage to the first declaration.
- oh for sure, but I think that's the rarer case for language implementions. Having a consistent structure with alternative keywords in static positions is just easier to develop an AST for. Personally my favorite language doesn't even allow for const values (except by convention) so it's really just a matter of preference

String a: new String()

=?
- "" most likely

I've always wondered where all this 'let' business started

It's commonly used in math to declare variables so I assume programming languages borrowed it from there.
- More specifically, they're borrowing the more mathematical meaning of variables, where if you say x equals 5, you can't later say x is 6, and where a statement like "x = x + 1" is nonsense. Using "let" means you're setting the value once and that's what it's going to remain as long as it exists, while "var" variables can be changed later. Functional languages, which are usually made by very math-y people, will often protest the way programmers use operators by saying that = is strictly for equality and variable assignment is := instead of == and = in most C-style languages.
- BASIC uses (used?) it to declare variables. (I don't know if earlier languages did.)
  Not that that's a reason for other languages to copy it.
More than you'd ever want to know: https://en.m.wikipedia.org/wiki/Let_expression
- I doubted you until I got about halfway through this whole page. I concede tho--you are most correct lol Still a decent read and for that I thank you

Not to short-circuit the joke, but in this case, it's because the valid JavaScript version is...

js

    
let a

...and one of TypeScript's main design goals is to be a superset of JavaScript, that only adds syntax, and doesn't re-write it.

Beyond that, it's probably a case of some new language just using what the designer is familiar with.

TypeScript [...] only adds syntax, and doesn't re-write it.
I believe enum, const enum, and decorators would like to have a word with you.
Who says this is JS? Might be Rust.
- Then the second part of my statement applies.

        IT'S SHOWTIME
      I NEED YOUR CLOTHES YOUR BOOTS AND YOUR MOTORCYCLE a
      GET TO THE CHOPPER a
        HERE IS MY INVITATION "ArnoldC is the best."
      ENOUGH TALK
      TALK TO THE HAND a
    YOU HAVE BEEN TERMINATED

let a: &'static str

Rust is verbose, but C++ might still take the cake with its standard library templates. Especially when using fully-qualified type names...
auto a = ::std::make_shared<::std::basic_string<char, ::std::char_traits<char>, MyAllocator<char>>>();
A reference-counted shared pointer to a string of unspecified character encoding and using a non-default memory allocator.
- fully qualified type names make any language awful.
  Here's the same example in rust:
  let a = std::rc::Rc::new(std::vec::Vec<u8, MyAllocator>::new());
  I believe u8 also comes from a module, so it would be something like std::u8::u8, but I'm not sure.
- I don't understand why verbose is bad. Verbose is maintainable.
- Yeah, I mean Rust is only verbose if you want it to be. let foo = "bar"; is valid rust too, no need to declare the type and definitely no need to declare the lifetime.
  For that matter, if you ever declare something as explicitly 'static in code that isn't embedded or super optimized, you're probably doing it wrong.

Can we talk about PHP functions with typehints too?

    
public static function foo(): string {

Practically every other language with similar syntax does this instead:

    
public static string foo() {

Rust and TypeScript use the return-type-at-the-end convention as well.
- Python too.
- TypeScript doesn't need the "function" keyword for a method in an object or on a class though.
  
  const foo = { bar(): string { ... } }
  which I assume is doable because the syntax is unambiguous.
  PHP's object orientation is similar to languages like Java and C#, which is what I was comparing to.
TIL PHP has statics.
Also, does PHP actually enforce the type declarations? I'd assume it would but knowing PHP...
- It enforces scalar types (string, int, etc) at runtime if you enable strict mode. There's also static analysis tools like PHPStan and Psalm that will flag issues at build time.

STRING A WHAT, MOTHERFUCKER

Javascript gonna Javascript

JavaScript 👍
- Blame my phone's autocorrect

First time i used let it was to inline variable declaration with assignment . Can’t remember the language.