Live data from Hacker News

The history of C# and TypeScript with Anders Hejlsberg [video]

youtube.com

31–40 of 162 posts

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#31

We need Anders to make one final language. A MINIMAL memory safe language. The less it has the better. Rust without the crazy town complexity. The distilled wisdom from C# and Delphi and TypeScript. A programming language that has less instead of more.

>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# doesn't depend on a VM these days when it is AOT compiled. Same for Java, though C# is rather more user friendly in how it goes about it.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#32

We need Anders to make one final language. A MINIMAL memory safe language. The less it has the better. Rust without the crazy town complexity. The distilled wisdom from C# and Delphi and TypeScript. A programming language that has less instead of more.

>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.

What you are looking for is called F#. You get native interop with C# and access to all .NET/C# libraries as a bonus. We use it as a daily driver for a complex B2B2C cloud platform.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#33

We need Anders to make one final language. A MINIMAL memory safe language. The less it has the better. Rust without the crazy town complexity. The distilled wisdom from C# and Delphi and TypeScript. A programming language that has less instead of more.

>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.

Kotlin has a LLVM backend, among others.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#34
Surprising to me that (in the context of TypeScript) ECMAScript 4, ActionScript, and Google Closure were not mentioned! Especially the first two; Macromedia/Adobe and Netscape/Mozilla have been working on baking TypeScript into JavaScript proper for a whole decade before HTML5, the mobile boom, and the associated problems have emerged. ES4/AS3 even had a nearly identical syntax.

What's even more interesting is that Microsoft and Google were part of TC-39 at the time, and were the main opponents of ES4. While they had some rightful reasons to take this position, there's no way ES4 hasn't shaped TS in the end. Perhaps the lack of mention of any of this is due to that TypeScript might have been handed to Anders' team after the project vision and original design have developed (in the video, it is introduced as a continuation of "SharpScript"), but the interview still left me rather insatiated.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#35
post #17

If you feel that TypeScript, or hell even JavaScript, is becoming more alike C#, it's actually deliberately done by Microsoft in benefiting their ecosystem. In this interview they mentioned they had internal demands to convert/transpile C# into JavaScript or TypeScript. So by making these target languages more like C#, it directly benefits their need. But I don't think this should be the driving force in designing EC…

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.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#36
post #24
post #17

If you feel that TypeScript, or hell even JavaScript, is becoming more alike C#, it's actually deliberately done by Microsoft in benefiting their ecosystem. In this interview they mentioned they had internal demands to convert/transpile C# into JavaScript or TypeScript. So by making these target languages more like C#, it directly benefits their need. But I don't think this should be the driving force in designing EC…

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 ...

Spot on.

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#37
post #32

Earlier quoted context omitted.

>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.

What you are looking for is called F#. You get native interop with C# and access to all .NET/C# libraries as a bonus. We use it as a daily driver for a complex B2B2C cloud platform.

[deleted]

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#38

Earlier quoted context omitted.

>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# doesn't depend on a VM these days when it is AOT compiled. Same for Java, though C# is rather more user friendly in how it goes about it.

[deleted]

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#39
post #34

Surprising to me that (in the context of TypeScript) ECMAScript 4, ActionScript, and Google Closure were not mentioned! Especially the first two; Macromedia/Adobe and Netscape/Mozilla have been working on baking TypeScript into JavaScript proper for a whole decade before HTML5, the mobile boom, and the associated problems have emerged. ES4/AS3 even had a nearly identical syntax. What's even more interesting is that M…

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

Re: The history of C# and TypeScript with Anders Hejlsberg [video]

#40

I don't know that many languages but, having been writing lots of typescript in the last 3 years there are so many things I love about it. It infers types. If I do const data = [ { name: 'bob', age: 35, state: 'CA' }, { name: 'jill', age: 37, state: 'MA' }, { name: 'sam', age: 23, state: 'NY' }, ]; Typescript knows data is an array of { name: string, age: number, state: string }. I don't have to tell it. Further, if…

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.
Post reply on HN