Out of the big 4 involved in typescript, only one was involved with the tc39

What you are describing is structural types. It is indeed a mystery that these are so under used, especially as they are a cornerstone of type theory. Structural types are so useful that they creep into most languages in some way. Even in Java, the Kingdom of the Nouns, where the rulers refused to merge a pair class, functions essentially take tuple arguments and these tuples don't have to be named and defined. You can't return a tuple though, so there is an unfortunate asymmetry. In Haskell and OCaml, we like to describe functions in a structural way, so com.google.android.Predicate would be just "a -> Bool". You wouldn't have to convert your com.google.guava.Predicate. But even these languages lack structural records and variants and suffer for it.

Inferred types are really great, but I feel they do not scale. Inside a method/function? Generally fine, but the signature, including the return type, had better be explicit.

Also, I think there was some performance issue with too much inference? Could be wrong, could also be fixed.

Even though that works reasonably well, you may still want to explicitly define your types/interfaces. In this example, if I do need to hardcode the data instead of fetching it somewhere, I would define the interface with "state" being a union of values, because there is nothing that stops you from using `state: 'ABC'` which would be hard to discover.

Lots of languages can infer types. And your last example with the colors is just a dictionary.

On the .Net VM you’re describing F#, mostly by virtue of being based on OCaml.

Contrasted with TypeScript and C#, F# is smaller, more expressive, stricter, with mature pattern matching and type resolution baked in from the ground up. F# was years ahead of the major languages on what are increasingly looking like ‘the basics’ around ADTs and immutability in modern distributed computing. OCaml and F# capture the linguistic high points of VB, Delphi, and C# with a broad spectrum of OOP(-lite) approaches, and have led those languages by decades on functional constructs that result in meaningfully tighter code. With the benefit of hindsight some approaches clearly map better to cloud computing and system verification.

F# also sits parallel to lots of living C#, objectively we see ‘less is more’. Less code per line, fewer lines per solution, terser and more LLM-efficient language. Error rates and refactoring costs are also meaningfully better IME, but harder to quantify in general terms.

I want something that will bring productivity of Delphi to Web. May be I am old now, but I could have built applications in a weekend in Access or Visual Basic that will take weeks now in latest web stack.

>We need Anders to make one final language.

I do feel like there is a gap for a modern compiled, functional and garbage collected language.

Go isn't it because it lacks the functional constructs.

C# and Java aren't it because they depend on a VM.

Rust isn't it because of its difficult memory management.

Swift isn't it because it is so tied to Apple and their platforms.

C# is way to go then

> Rust without the crazy town complexity.

To be clear, the language has a GC then?

The minimal memory-safe language is Go. Turns out it's too minimal for most.

What about Lua? The language is very minimal, memory safe, and has Pascal-like syntax just like Delphi.

Oberon 07?

What would you take out of C# etc?

Sounds like golang to me

Not at all. Before the use of TypeScript exploded, they had two features brought into it from C# which were namespaces and enums (both of which are amazingly good features. For the first one, no one knew what was the right choice back then. We had almost a dozen different module systems and TypeScript had gone their way to support all of them and namespaces were their own solution to the mess (remember they were trying to solve their own problems at first, it wasn't to dominate anything). I personally used namespaces and I could have only the TypeScript compiler running and producing a single JS file for rapid development without the burden of --- then very slow --- webpack.

And for enums, using strings as enums was not a very efficient idea. I think JavaScript introduced Symbols for locked/hidden properties but also meant to use them as enums. It never worked either and then the sum type, union type feature of TypeScript made the whole community to keep using strings as enums. This is still a very bad idea, it is not ergonomic, it is prone to many problems, and very inefficient to compare strings instead of integers. But hey TypeScript tried to fix the problem and almost everyone rejected it. And so enum is now discontinued.

Rest of the changes to TypeScript came from almost any other language but C#, probably the biggest changes ever to happen to JavaScript came directly from CoffeeScript. And then I personally saw how each of these new changes --- one by one --- arrived at C#. For what I have seen firsthand by reading the TC39 proposals, each feature came from a different community and different programming languages, (think about null operators !/?, the nullish coalescing ??, the incoming pipes, fat arrows and lambdas, mixings) as JavaScript is the only language everyone has to use, and it has benefited everyone to have a language that has all the great things from all other languages.

As a long term observer: definitely not a goal. But you have to be clear here: JavaScript and C# both are OO languages, both are having origins stories in Java/C++, both are facing the same niche (system development), same challenges (processor counts, ...) and so on. And then, you put teams on it which look left and right when they face a problem and then you wonder that they reuse what they like?

C# language team is also really good. They did not do a lot of mistakes in the 25+ years. They are a very valid source of OO and OO-hybrid concepts. It is not only TS/JS but also Java and C++ who often look to C#.

The story was not to transform C# code to JS but to use C# to write the code in the first place and transpile it. Not for the sake of having .NET usage but for the sake of having a good IDE.

Well, for one, benefiting Microsoft's ecosystem does not imply being detrimental to other ecosystems per se.

Furthermore, couldn't the convergence of TypeScript towards C# be simply a result of shared goals and values of the two languages, especially considering they have the same principal designer?

C# is inherently OOP oriented and it's type system works completely differently.

It sounds like conspiracy theory that they design TS/JS to convert from C# easier, huh.

The truth is that C# is probably the best designed mainstream language out there.

C# was known as a language with lowest amount of WTF per LoC

that's the "evil MS" perspective

The sequence of turbo pascal / delphi / c# / typescript which brought us LSP as a sidekick (!) IMHO has benefitted the whole industry at least as much as "transpile c# to ecma script via typescript" . no. much much much more.

I do not see a problem with MS also having an internal use case .

you know I wouldn't stop using python "because" Guido now works at MS ...