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

641–650 of 943 posts

Re: A 10x Faster TypeScript

#641

Post by pebal »

breadwinner wrote: post #632
DanRosenwasser wrote: post #59

Earlier quoted context omitted.

We did anticipate this question, and we have actually written up an FAQ entry on our GitHub Discussions. I'll post the response below. https://github.com/microsoft/typescript-go/discussions/411 . ____ Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a nativ…

So when can we expect Go support in Visual Studio? I am sold by Anders' explanation that Go is the lowest language you can use that has garbage collection!

You can also have GC in C++ and generate even faster code.

Re: A 10x Faster TypeScript

#642

Post by Hello71 »

jodrellblank wrote: post #352
electroly wrote: post #143

Earlier quoted context omitted.

This is a great response but this is "why is Go better than JavaScript?" whereas my question is "why is Go better than C# , given that C# was famously created by the guy writing the blog post and Go is a language from a competitor?" C# and TypeScript are Hejlsberg's children; C# is such an obvious pick that there must have been a monster problem with it that they didn't think could ever be fixed. C# has all that stuf…

> "given that C# was famously created by the guy writing the blog post" What is this logic? "You worked on C# years ago so you must use C# for everything"? "You must dictate C# to every team you lead forever, no matter what skills they have"? "You must uphold a dogma that C# is the best language for everything, because you touched it last"? Why aren't you using this logic to argue that they should use Delphi or Turbo…

> Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those?

as you know full well, Delphi and Turbo Pascal don't have strong library ecosystems, don't have good support for non-Windows platforms, and don't have a large developer base to hire from, among other reasons. if Hejlsberg was asked why Delphi or Turbo Pascal weren't used, he might give one or more of those reasons. the question is why he didn't use C#, for which those reasons don't apply.

Re: A 10x Faster TypeScript

#643

Post by zestyping »

That's a pretty misleading clickbait title. TypeScript isn't getting 10x faster; the TypeScript compiler is getting 10x faster.

I would argue it needs editing, as it violates the HN guideline:

> use the original title, unless it is misleading or linkbait; don't editorialize.

Re: A 10x Faster TypeScript

#644

Post by ninkendo »

pjmlp wrote: post #12

Even though I have my considerations regarding Go, I love that they picked Go instead of the fashion to go Rust that seems to be the norm now. A compiled managed language is much better approach for userspace applications. Pity that they didn't go with AOT compiled .NET, though.

> I love that they picked Go instead of the fashion to go Rust

This seems super petty to me. Like, if at the end of the day you get a binary that works on your OS and doesn’t require a runtime, why should you “love” that they picked one language over another? It’s exactly the same outcome for you as a user.

I mean, if you wanted to contribute to the project and you knew go better than rust, that would make sense. But sounds like you just don’t like rust because of… reasons, and you’re just glad to see rust “fail” for their use case.

Re: A 10x Faster TypeScript

#645

Post by ironmagma »

zoogeny wrote: post #230

I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…

Inevitably? Well, the promise of using something less efficient in terms of performance is that it will be more efficient in terms of development. Many times projects fail because they optimize too early and never built the features they needed to or couldn’t iterate fast enough to prove value and die. So if the native version is better but failed, it’s not so inevitable that it will get to that stage.

Re: A 10x Faster TypeScript

#647

Post by 9rx »

nipah wrote: post #624
9rx wrote: post #571

Earlier quoted context omitted.

> I don't think this is fair [at all], you use the types precisely to not need to be so overreliable on tests At the extreme end of the spectrum that starts to become true. But the languages that fill that space are also unusable beyond very narrow tasks. This truth is not particularly relevant to what is seen in practice. In the realm of languages people actually use on a normal basis, with their half-assed type sys…

Hmmm, I think this is an interesting discussion. There's many sides I need to respond here, maybe I will not be able to cover everything but here I go. See, I fundamentally disagree that those languages are "unusable beyond very narrow tasks", because I never stated that only a complete and absolutely proven type system can provide those proofs. In fact, even a relatively mid-tier (a little bit above average) type-sy…

> I fundamentally disagree that those languages are "unusable beyond very narrow tasks"

Then why do you think nobody uses them (outside of certain narrow tasks)? It is hard to deny the results.

The reality is that they are intractable. For the vast majority of programming problems, testing is good enough and far, far more practical. There is a very good reason why the languages people normally use (yes, including C# and Rust) prefer testing over types.

> See, when you test for something like raw JavaScript, you end up testing things that are even about the shape of your objects

Incidentally, but not explicitly. You also end up incidentally testing things like the shape even in languages that provide strict guarantees in the type system. That's the nature of testing.

I do agree that testing is not well understood by a lot of developers. There are for sure developers who think that explicitly testing for, say, the shape of data is a test that needs to be written. A lot of developers straight up don't know what makes for a useful test. We'd do well to help them better understand testing, but I'm not sure "don't even think about it, you've got a half-assed type system to lean on!" get us there. Quite the opposite.

> it matters more that the right people are using them

Well, they're not. And they are not going to without some fundamental breakthrough that changes the tractability of using languages with an advanced (on the full spectrum, not relative to Go) type system. The tradeoffs just aren't worth it in nearly every case. So we're stuck with half-assed type systems and relying on testing, for better or worse. Yes, that includes C# and Rust.

> I don't think glorifying mediocre type systems is the way to go (like many people usually do, for some terrifying reason).

Does it matter? Engineers don't make decisions based on some random emotional plea on HN. A keyboard cowboy might be swayed in the wrong direction by such, but then this boils down to being effectively equivalent to "If we don't talk about sex maybe teenage pregnancy will cease." Is that really the angle you want to go with?

Re: A 10x Faster TypeScript

#648

Post by dontlaugh »

jjice wrote: post #72
pjmlp wrote: post #44

Earlier quoted context omitted.

Personally, Rust only makes sense in scenarios that automatic memory management of any kind is either unwanted, or it is a quixotic battle making the target group think otherwise. OS kernels, firmware, GPGPU,.... If it is the ML inspired type system, there are plenty of options among compiled managed languages, true Go isn't really on that camp, but whatever.

I'd love a language that is a GC'd like go, but with the ML inspired type system, and still an imperative language. OCaml seems to be the closest thing to Rust in that regard, but it's not imperative.

That language is Swift.

Re: A 10x Faster TypeScript

#649

Post by zoogeny »

ironmagma wrote: post #645
zoogeny wrote: post #230

I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…

Inevitably? Well, the promise of using something less efficient in terms of performance is that it will be more efficient in terms of development. Many times projects fail because they optimize too early and never built the features they needed to or couldn’t iterate fast enough to prove value and die. So if the native version is better but failed, it’s not so inevitable that it will get to that stage.

Right, which is my point about LLM code assistants. If you did have two cases in the past: native but slow to add features so the project eventually dies vs. scripted but performance is bad enough it eventually needs to be rewritten. (Of course, this is a false dichotomy but I'm playing into your scenario).

Now we may have a new case: native but fast to add features using a code assist LLM.

If that new case is a true reflection of the near future (only time will tell) then it makes the case against the scripted solution. If (and only if) you could use a code assist LLM to match the feature efficiency of a scripting language while using a native language, it would seem reasonable to choose that as the starting point.

Re: A 10x Faster TypeScript

#650

Post by atonse »

nailer wrote: post #118
pjmlp wrote: post #55

Earlier quoted context omitted.

Bootstraping compilers is a common activity and TypeScript is a nice language.

Yep. I remember years ago when they celebrating getting the C# compiler working in C#.

That was the Roslyn project! Yes they were also excited that it would allow more devs to hook into the computer and also enhance it.
Post reply on HN