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

A 10x Faster TypeScript

devblogs.microsoft.com

Post reply on HN
Print view View original

911–920 of 943 posts

Re: A 10x Faster TypeScript

#911

Post by [deleted] »

jodrellblank wrote: post #875
cxr wrote: post #735

Earlier quoted context omitted.

> "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird It's also not what anyone said. > It's best not to use quotation marks to make it look like you're quoting someone when you're not. https://news.ycombinator.com/item?id=21643562 >

Why is that "best" ? > "An indirect quote lets you capture or summarize what someone said or wrote without using their exact words. It helps to convey the tone or meaning of your source without quoting them directly." - https://www.grammarly.com/blog/punctuation-capitalization/qu... I'm distilling and exaggerating multiple the comments to convey the tone and meaning of the bit I want to focus on. Asking "why not C#?"…

[deleted]

Re: A 10x Faster TypeScript

#912

Post by cxr »

jodrellblank wrote: post #875
cxr wrote: post #735

Earlier quoted context omitted.

> "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird It's also not what anyone said. > It's best not to use quotation marks to make it look like you're quoting someone when you're not. https://news.ycombinator.com/item?id=21643562 >

Why is that "best" ? > "An indirect quote lets you capture or summarize what someone said or wrote without using their exact words. It helps to convey the tone or meaning of your source without quoting them directly." - https://www.grammarly.com/blog/punctuation-capitalization/qu... I'm distilling and exaggerating multiple the comments to convey the tone and meaning of the bit I want to focus on. Asking "why not C#?"…

[flagged]

Re: A 10x Faster TypeScript

#913

Post by ryoukokonpaku »

bitmasher9 wrote: post #505
nailer wrote: post #362

Earlier quoted context omitted.

Can't the CLR tools just output native binaries now?

Can it? That’s awesome. Mostly these days I’m only aware of C# when it inconveniences me.

It even produces smaller binaries than Go and the size scales much better as the codebase grows too. dotnet has come a long way since the olden days of .net framework.

The reasons stated on github doesn't seem to be convincing imo.

- platform support

NativeAOT supports all platforms, the only one missing is Android which is marked experimental, but since they'd be treated as a "1st party" customer since they're both MS projects, this could be easily expedited. Even WASM is supported in NativeAOT using the LLVM toolchain and is often compared to perform better than Go's WASM target which doesn't use LLVM

- Usage of functions and structs

C# supports this, and you even have better control on layout and performance in this regard. Functions can easily be ported as static functions on static classes. They could even use F# which is even closer to Typescript if they wanted a more direct port as both languages compile to IL for NativeAOT.

There must be more reasons as to why it didn't choose C# in this regard, likely non-technical related. A missed opportunity imo.

Re: A 10x Faster TypeScript

#914

Post by za3faran »

whattidywhat wrote: post #798
emseetech wrote: post #680

Earlier quoted context omitted.

| with no frills. People say this like it's a bad thing. It's not, it's Go's primary strength.

I can see the appeal. Not having to write C# style oop probably gave the team a huge productivity boost. I bet it compiles hundreds of times faster making the team, cicd, and dev efforts substantially more productive. Cohesive integrated modern tooling is also a huge plus. Project structure is considerably simpler... I am not really a go fan but I would chose it over c# in a majority of cases as well. I think they mi…

> Not having to write C# style oop probably gave the team a huge productivity boost.

I wrote a lot of Go code as well as Java. When people say things like this, I'm not quite sure what exactly they are referring to. No one is forcing you to write mutli-level deep inheritance hierarchies in Java/C#, and Go itself is OOP. Structural typing has its issues as well. Where does this supposed inherent productivity boost lie?

Re: A 10x Faster TypeScript

#916

Post by pjmlp »

mappu wrote: post #900
nasretdinov wrote: post #853

Earlier quoted context omitted.

The standard library uses unsafe for syscalls, for higher-performance primitives like strings.Builder, etc, so it's support is mandatory to run any non-trivial Go program

For a while the GOOS=nacl port and the Google App Engine ports of Go disallowed unsafe pointer manipulation too, so there is some precedent. Throughout some of the ecosystem you can see pieces of "nounsafe" build tag support (e.g. in easyjson).

Most programming languages that offer unsafe, either as language keyword, or meta package (unsafe/SYSTEM/UNSAFE whatever the name), have similar option, that doesn't make it less of a feature.

Re: A 10x Faster TypeScript

#917

Post by mexicocitinluez »

WuxiFingerHold wrote: post #881
mexicocitinluez wrote: post #801

Earlier quoted context omitted.

I dont think there are other reasons. The side-by-sides that show how Go code is closer to the current TS code (visually) than C# would be are pretty compelling. He made it pretty clear they're "porting" not rewriting.

After reading the long Github thread, I think you're right. It's probably just as simple as "what is the easiest way to copy our TS code 1:1 to a faster language". And this case Go wins due to its simplicity.

What's funny is that while I understood a chunk about why that made that decision, a ton of things they were talking about went over my head. But then we they showed the side-by-side, I was like "Well that makes sense".

Re: A 10x Faster TypeScript

#918

Post by morcus »

smarx007 wrote: post #901
Cthulhu_ wrote: post #761

Earlier quoted context omitted.

Those are runtimes primarily, not compilers/type checkers. Likewise, TSC is not a TS runtime.

Well, of course. But TSC output (transpiled JS source code) is then run by a JS runtime like Node that has a VM like V8 that makes an internal representation for the JS code. Using Bun or Deno allows you to go to a VM IR from the TypeScript directly without a need for TSC transpilation into JS first. But as @keturakis pointed out (thanks!), Deno/Bun still rely on TSC, which I was not aware of.

Bun doesn't even support a way to check types, just remove them.

> Note — Similar to other build tools, Bun does not typecheck the files. Use tsc (the official TypeScript CLI) if you're looking to catch static type errors.

Re: A 10x Faster TypeScript

#919

Post by selfmodruntime »

9rx wrote: post #891
selfmodruntime wrote: post #720

Earlier quoted context omitted.

Yes. For Webservers. Not for compilers. I wrote a bunch of compilers, and Go is not a language I would choose for this.

Unless, of course, you are not working on a greenfield project and instead are porting an existing compiler from Typescript, in which case Go is the language you would choose as it is the language that most closely resembles Typescript, allowing ease of bulk conversion by script. The same reason why it was chosen for Typescript.

I read that response and I agree entirely! Porting Js to Rust isn’t feasible. I love Rust but it’s good to know your constraints.

Re: A 10x Faster TypeScript

#920

Post by whattidywhat »

senorrib wrote: post #906
whattidywhat wrote: post #794

Earlier quoted context omitted.

The compiler ensures you are writing memory safe code. Otherwise it rejects that code and helps you see the mistake you made. Why people are so upset when the compiler prevents them from building and shipping unusable code will always baffle me.

Theres a huge gap between inefficient and unusable. There’s a lot of usable code out there that leaks memory. I’d argue compilers are hardly pressed by memory usage given the transient nature of their execution.

Saying rust is unusable is pretty extreme. Tons of serious applications and infrastructure have been using it in production for years generating lots of money and preventing CVEs.

Leaking memory is sometimes not a huge issue. Missile allocation is real. Undefined behaviour, seg faults, data races, etc from edge cases slow down development.

The promise of rust isn't that it's super fast to learn but once you have you never deal with a swath of issues ever again.

And that's speaking from a deficit. Rust is an excellent language to do language development. It has arguably the best tooling for it in the ecosystem in my opinion and a vibrant community for it. Some of the most recent languages have foundations in rust. That is likely to continue going forward.

Post reply on HN