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

881–890 of 943 posts

Re: A 10x Faster TypeScript

#881

Post by WuxiFingerHold »

mexicocitinluez wrote: post #801
WuxiFingerHold wrote: post #683

Earlier quoted context omitted.

Thanks for the link. I'm not fully convinced by Anders answer. C# has records, first class functions, structs, span. Much control and I'd say more than Go. I'd even say C# is much closer to TS than Go is. You can use records for the data structures. The only little annoyance is that you need to write the functions as static methods. So an argument for easy translation would lead to C#. Also, C# has advantages over Go…

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.

Re: A 10x Faster TypeScript

#882

Post by Vaguely2178 »

zoogeny wrote: post #880
anileated wrote: post #849

Earlier quoted context omitted.

> Given LLM assistance, why wouldn't I write my web app layer in Rust or Zig? Same reasons as with no LLM assistance. You would be choosing higher maintenance burden and slower development speed compared to your competitors, though. They will get it out faster, they will have fewer issues, and will be able to find people to support it more easily. Your product may run faster, but theirs will work and be out faster.

Lets imagine we are assembly programmers. You have a particular style of assembly that you believe gives you some advantage over your competitors. The way you structure your assembly gives you a lower maintenance burden and faster development speed compared to your competitors. I show up and say "I have a C compiler". Does it matter at that point how good your assembly is? All of a sudden I can generate 10x the amoun…

> In the same way I don't care about "maintainable assembly" coming out of a C compiler, I don't care about maintainable Python coming out of my LLM.

A well tested compiler is far more deterministic than an LLM, and can be largely treated as a black box because it won't randomly hallucinate output.

Re: A 10x Faster TypeScript

#883

Post by whoknowsidont »

osigurdson wrote: post #852
neonsunset wrote: post #840

Earlier quoted context omitted.

You may want to read the documentation first before responding.

Where in the documentation does it state that everything just works (as it would in go)? I see a list of incompatibilities / limitations etc., that not only apply to your own code but any 3rd party library.

The OP is a troll. He just claims everyone else is out to get him and .NET if they point out some inconvenient non-ideal on display in the ecosystem.

Every tooling has its faults.

Re: A 10x Faster TypeScript

#884

Post by zoogeny »

Vaguely2178 wrote: post #882
zoogeny wrote: post #880

Earlier quoted context omitted.

Lets imagine we are assembly programmers. You have a particular style of assembly that you believe gives you some advantage over your competitors. The way you structure your assembly gives you a lower maintenance burden and faster development speed compared to your competitors. I show up and say "I have a C compiler". Does it matter at that point how good your assembly is? All of a sudden I can generate 10x the amoun…

> In the same way I don't care about "maintainable assembly" coming out of a C compiler, I don't care about maintainable Python coming out of my LLM. A well tested compiler is far more deterministic than an LLM, and can be largely treated as a black box because it won't randomly hallucinate output.

Humans aren't deterministic. I've trusted junior engineers to ship code. I fail to see a significant difference here in the long term.

We have engineering practices that guard against humans making mistakes that break builds or production environments. It isn't like we are going to discard those practices. In fact, we'll double down on them. I would subject an LLM to the level of strict validation that any human engineer would fine suffocating.

The reason we trust compilers as a black box is because we have created systems that allow us to do so. There is no reason I can see currently that we will be unable to do so for LLM output.

I might be wrong, time will tell. We're going to find out because some will try. And if it turns out to be as effective as C was compared to assembly then I want to be on that side of history as early as possible.

Re: A 10x Faster TypeScript

#886

Post by whoknowsidont »

DeathArrow wrote: post #721

The news for me is Microsoft teams relying on Go. Strange choice to use Go for the compiler instead of C# or F#. Now if they will have problems, they will depend on the Go team at Google to fix them.

>Now if they will have problems, they will depend on the Go team at Google to fix them.

MS literally already has a whole team around Go. And if they didn't, Go is completely open source.

C# is open-source in name only.

Re: A 10x Faster TypeScript

#887

Post by sellmesoap »

nindalf wrote: post #722
_bin_ wrote: post #698

Earlier quoted context omitted.

funny you bring up this analogy. tons of auto manufacturers these days will license other mfgs' engines and use them in your cars. e.g. a fair number of Ford's cars have had Mazda engines and a fair number of Mazdas have had Ford engines.

Could you give some examples of both? Also, why did they choose to do this?

The last model of ford ranger and Mazda B series light pickup trucks were mostly the same except for the badges.

The Toyota matrix and Pontiac vibe used a lot of the same parts shared an engine and drivetrains if I'm not mistaken.

Re: A 10x Faster TypeScript

#888

Post by Vaguely2178 »

zoogeny wrote: post #884
Vaguely2178 wrote: post #882

Earlier quoted context omitted.

> In the same way I don't care about "maintainable assembly" coming out of a C compiler, I don't care about maintainable Python coming out of my LLM. A well tested compiler is far more deterministic than an LLM, and can be largely treated as a black box because it won't randomly hallucinate output.

Humans aren't deterministic. I've trusted junior engineers to ship code. I fail to see a significant difference here in the long term. We have engineering practices that guard against humans making mistakes that break builds or production environments. It isn't like we are going to discard those practices. In fact, we'll double down on them. I would subject an LLM to the level of strict validation that any human engi…

> Humans aren't deterministic.

Exactly, which is why I would want humans and LLMs to write maintainable code, so that I can review and maintain it, which brings us back to the original question of which programming languages are the easiest to maintain...

Re: A 10x Faster TypeScript

#889

Post by sellmesoap »

kcrwfrd_ wrote: post #729
nindalf wrote: post #722

Earlier quoted context omitted.

Could you give some examples of both? Also, why did they choose to do this?

Toyota 86 and Subaru BRZ are basically the same car. The car was designed by Toyota while Subaru supplied the engine. Just one example.

I think Toyota also owns a significant amount of Subaru, probably other mfgs. as well, Toyota is the 600lb gorilla of the car industry.

Re: A 10x Faster TypeScript

#890

Post by zoogeny »

Vaguely2178 wrote: post #888
zoogeny wrote: post #884

Earlier quoted context omitted.

Humans aren't deterministic. I've trusted junior engineers to ship code. I fail to see a significant difference here in the long term. We have engineering practices that guard against humans making mistakes that break builds or production environments. It isn't like we are going to discard those practices. In fact, we'll double down on them. I would subject an LLM to the level of strict validation that any human engi…

> Humans aren't deterministic. Exactly, which is why I would want humans and LLMs to write maintainable code, so that I can review and maintain it, which brings us back to the original question of which programming languages are the easiest to maintain...

Well, we're in a loop then because my response was "you don't care about maintainable assembly".

I want maintainable systems you want maintainable code. We can just accept that difference. I believe maintainable systems can be achieved without focusing on code that humans find maintainable. In the future, I believe we will build systems on top of code primarily written by LLMs and the rubric of what constitutes good code will change accordingly.

edit: I would also add that your position is exactly the position of assembly programmers when C came around. They lamented the assembly the C compiler generated. "I want assembly I can read, understand and maintain" they demanded. They didn't get it.

Post reply on HN