Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

youtube.com

Post reply on HN
Print view View original

151–160 of 162 posts

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

#151

Post by wbobeirne »

CharlieDigital wrote: post #122
wbobeirne wrote: post #95

Earlier quoted context omitted.

I assume the startup wasn't also leveraging typescript heavily on the frontend, that tends to shift the weight in its favor. Having one set of tools to use across everything, being able to share logic and types without needing to go through lossy translation layers, and giving (especially small) teams better flexibility to move people around is a huge benefit.

We are using TS on the FE with React. But the reality is that at some point, your FE and BE teams will diverge anyways and we use an OpenAPI spec as the contract (Nest.js, not Next.js). So there was no benefit to using TS on both ends; only pain on the BE. If a team is going to ship an OpenAPI spec and run it through a transformer, then it changes the selection criteria for a BE language: - Easy for a TS team to adop…

I can't speak to your use case, but for past projects I've not only wanted to share types but actual logic. For instance, if you want instantaneous validation on the frontend, while applying the same logic on the backend with submitted data. In many instances that would be simple and maybe even serializable, but in my case I was working with architectural data that had extremely detailed logic for what was and was not valid.

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

#152

Post by [deleted] »

HumblyTossed wrote: post #101
tonyedgecombe wrote: post #27

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.

That's the problem though. People want one language to be The One (tm) and that's just not possible. Your The One (tm) isn't mine.

[deleted]

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

#153

Post by Sammi »

wbobeirne wrote: post #151
CharlieDigital wrote: post #122

Earlier quoted context omitted.

We are using TS on the FE with React. But the reality is that at some point, your FE and BE teams will diverge anyways and we use an OpenAPI spec as the contract (Nest.js, not Next.js). So there was no benefit to using TS on both ends; only pain on the BE. If a team is going to ship an OpenAPI spec and run it through a transformer, then it changes the selection criteria for a BE language: - Easy for a TS team to adop…

I can't speak to your use case, but for past projects I've not only wanted to share types but actual logic. For instance, if you want instantaneous validation on the frontend, while applying the same logic on the backend with submitted data. In many instances that would be simple and maybe even serializable, but in my case I was working with architectural data that had extremely detailed logic for what was and was no…

Using a TS validation library like Zod gives you both the shared validation code for both the frontend and backend, the TS types, as well as the json schema for openapi. It's a triple whammy too good to ignore. Especially as a small team it is huge leverage enabling you to go further faster.

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

#154

Post by CharlieDigital »

wbobeirne wrote: post #151
CharlieDigital wrote: post #122

Earlier quoted context omitted.

We are using TS on the FE with React. But the reality is that at some point, your FE and BE teams will diverge anyways and we use an OpenAPI spec as the contract (Nest.js, not Next.js). So there was no benefit to using TS on both ends; only pain on the BE. If a team is going to ship an OpenAPI spec and run it through a transformer, then it changes the selection criteria for a BE language: - Easy for a TS team to adop…

I can't speak to your use case, but for past projects I've not only wanted to share types but actual logic. For instance, if you want instantaneous validation on the frontend, while applying the same logic on the backend with submitted data. In many instances that would be simple and maybe even serializable, but in my case I was working with architectural data that had extremely detailed logic for what was and was no…

That's simple; check out https://Orval.dev or https://Kubb.dev. Both of which can generate validation code (among other things) from OpenAPI.

Example with .NET: https://github.com/CharlieDigital/dn-kubb

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

#156

Post by WorldMaker »

trympet wrote: post #133
kryptiskt wrote: post #31

Earlier quoted context omitted.

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.

> C# doesn't depend on a VM these days when it is AOT compiled Maybe I’m being pedantic, but this is an oxymoron. Also the premise is incorrect. It’s not like the VM is gone. Merely baked into the code at compile time. It compiles IL to native code. Same for IL2CPP. The VM is still there. The term “virtual machine” is confusing. I think you meant to say JIT compiler :-)

The trouble with that level of pedantry is that you then can point to LLVM as a VM and say that Clang and other C/C++/Rust tools that AOT through LLVM are "too tied to a virtual machine". Then you can go back through the history of cross-platform optimizing C/C++ compilers and find VMs in the design in almost all of those, too. LLVM is not hiding it in its very clear name, but low-level VMs were a thing for decades before someone named LLVM.

VMs have a long history in cross-compilation, even for "low-level" languages like C/C++. The AOT versus JIT distinction is blurry, and the "VM language" versus "non-VM language" boundary is blurrier still, especially when you take into account "standard runtimes" such as glibc and vcrt and whether or not those are statically linked.

Is a C program with a compiled with Clang through the LLVM dynamically linking a glibc and statically linking a Boehm GC library "running in a VM"? There's no wrong answer, it's a lot shades of gray. I believe almost every pedantic way to answer that has an equally pedantic counter-argument.

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

#157

Post by WorldMaker »

tonyedgecombe wrote: post #27
andrewstuart wrote: post #2

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.

I don't see why a VM is a problem, personally, and I like a lot of what C# has been exploring with `Span` and `Memory` for safe low-level memory management in a garbage-collected language. Some of it seems like a simpler Rust. Rust can still do plenty of memory lifetime things that C# can't, but the gap is smaller than ever and C# is still slowly growing its capabilities in that space. All that in a language where you don't have to start with the low level tools, you can prototype entirely in higher-level garbage collected space and use real world performance to guide optimizations towards the low-level memory management tools only when they become truly necessary.

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

#158

Post by WorldMaker »

ptx wrote: post #52
froh wrote: post #24

Earlier quoted context omitted.

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

Python has an elected steering council and core team. The governance process explicitly tries to avoid conflict of interest by disallowing more than two steering council members working for the same employer. See PEP 13 [1]. By contrast, .NET is controlled by Microsoft (with veto over board decisions [2] and code changes [3]), integrates Microsoft's telemetry to send your data to Microsoft by default [4] and delibera…

The complaint above was that JS was becoming too much like C#, so the steering committee of .NET isn't the one of the original concern. (Also, as pointed out, that "deliberate hobbling" case was litigated in the public square on HN at the time and then revised and "unhobbled" after the outcry.)

As far as the other direction, JS has a somewhat similar (but rather more complex) situation to Python with its steering committee being Ecma International's TC39 (Technical Committee 39).

Ecma International has similar By-Laws and Rules designed to manage conflict of interest and too much power consolidate in a single employer of committee members. Ecma is maybe even a little "stricter" than Python because its rules consider the companies themselves to be the members, and companies only get one vote no matter how many employees interact with the process.

https://ecma-international.org/policies/by-laws/

https://ecma-international.org/policies/rules/

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

#160

Post by owlstuffing »

matt_kantor wrote: post #89
jeroenhd wrote: post #84

Earlier quoted context omitted.

Type inference is part of every modern language. Structural typing not so much, though. Java has it through a compiler extension ( https://github.com/manifold-systems/manifold/tree/master/man... ) but I don't know many other languages that support this feature. As much as I dislike the entire Javascript runtime environment, I find TypeScript to be the best typing system out there for any imperative language.

> I don't know many other languages that support this feature The other widely-used one is Go with its structurally-typed interfaces.

Right... But Go is exclusively structurally typed, whereas Java with the manifold compiler plugin complements the type system's nominal foundation -- a class can still implement a structural interface nominally. Doing so enforces intention and helps both people and tooling comprehend code faster and more efficiently. But the general idea is to use an interface structurally where it otherwise can't be used nominally or doing so is more complicated.
Post reply on HN