Live data from Hacker News

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

youtube.com

41–50 of 162 posts

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

#41
post #18

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…

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.

This. As soon as you need to use the type in another function (e.g. function parameter), you'll discover that it's better to just write it out.

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

#42

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.

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

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

#43
post #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 i…

> They did not do a lot of mistakes in the 25+ years

If my memory serves, .NET and WinFS were the two major forces that sunk Longhorn, and both have been given their walking papers after the reset [1].

.NET and C# have grown to be mature and well-engineered projects, but the road there was certainly not without bumps. It's just that a lot of the bad parts haven't spilled outside of Microsoft, thankfully.

[1] https://www.theregister.com/2005/05/26/dotnet_longhorn/

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

#44
post #18

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…

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.

They do scale, but explicit types have two bonuses in my eyes:

1. can be read without a compiler, useful when reading PRs

2. They make the compiler work less, it's easier to check than infer

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

#45
post #19
post #15

Earlier quoted context omitted.

dictionaries generally aren't guaranteed to contain an entry for every possible value of the key type. while you could implement the colors example with a dictionary, ideally you'd want the type system to assure that given a Color, there will be a string associated with it

Sounds like enums with extra steps.

Enums aren't type safe in typescript

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

#46
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…

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

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

#48

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.

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

verything is an off by one error in Lua.

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

#49
post #42

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.

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

It’s not memory safe.

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

#50

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.

There are plenty of languages in that niche you could be using. OCaml, Haskell, F#...
Post reply on HN