Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

381–390 of 943 posts

Re: A 10x Faster TypeScript

#381
post #324

Earlier quoted context omitted.

Anders answers that question here - https://www.youtube.com/watch?v=10qowKUW82U&t=1154s Transcript: "But I will say that I think Go definitely is much more low-level. I'd say it's the lowest level language we can get to and still have automatic garbage collection. It's the most native-first language we can get to and still have automatic GC. In contrast, C# is sort of bytecode-first, if you will. There are some ahead…

An unpopular pick that is probably more low level than Go but also still has a GC: D. Understandable why you wouldn't pick D though. Its ecosystem is extremely small.

I think you D fans need to dogfood a startup based around it.

It's a fascinating language, but it lacks a flagship product.

I feel the same way about Haxe. Someone created an amazing language, but it lacks a big enough community.

Realistically languages need 2 things for adoption. Momentum and ease of use. Rust has more momentum than ease, but arguably can solve problems higher level languages can't.

I'm half imagining a hackathon like format where teams are challenged to use niche languages. The foundations behind these languages can fund prizes.

Re: A 10x Faster TypeScript

#382

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…

I personally find Go miles easier than Rust. Is this the ultimate reason,Go is fast enough without being overally difficult. I'm humbly open to being wrong. While I'm here, any reason Microsoft isn't sponsoring a solid open source game engine. Even a bit of support for Godot's C#( help them get it working on web), would be great. Even better would be a full C# engine with support for web assembly. https://github.com/…

> Even a bit of support for Godot's C#( help them get it working on web), would be great.

They did that. https://godotengine.org/article/introducing-csharp-godot/

At least some initial grant to get it started.

Getting C# working on web would be an amazing. It is already on the roadmap but some sponsorship would help tremendously for sure.

Re: A 10x Faster TypeScript

#383
post #223

Earlier quoted context omitted.

C# is fine. But last I checked, the AOT compilation generates a bunch of .dll files, which are not suitable for a CLI program like Go's zero dependencies binary.

C# can create single-binary executables, even without native AOT.

They are still going to significant bigger than the equivalent golang binary because of the huge .NET runtime, no?

Re: A 10x Faster TypeScript

#384

This is frustrating: > The JS-based codebase will continue development into the 6.x series, and TypeScript 6.0 will introduce some deprecations and breaking changes to align with the upcoming native codebase. > While some projects may be able to switch to TypeScript 7 upon release, others may depend on certain API features, legacy configurations, or other constraints that necessitate using TypeScript 6. Recognizing T…

Better a language that deprecates and breaks things at regular intervals of time compared to a language that has Forever Backward Compatibility like C++ and evolves into a mutated, tentacled monster that strangles developers who are trying to maintain a project.

Re: A 10x Faster TypeScript

#385

People seem very hurt that the creator of C# didn't pick C# for this very public project from a multi-trillion-dollar corp. I find it very refreshing, they defined logical requirements for what they wanted to do and chose Golang because it ticked more boxes than C#. This doesn't mean that C# sucks or that every C# project should switch to Golang, but there seems to be a very vocal minority affected by this logical de…

I love their choice of Go because of how simple it is to generate a static executable with no dependencies (ie no dotnet runtime).

With C# you can either bundle dotnet runtime with the executable, or use native AOT, which compiles to a binary without the runtime.

However, in both native AOT and Go you actually have some parts of the runtime bundled in (e.g. garbage collector).

Re: A 10x Faster TypeScript

#386

Earlier quoted context omitted.

I wish there was a language like rust without the borrow checking and lifetimes that was also popular and lives in the same area as go. Because I think go is actually the best language in this category but it’s only the best because there is nothing else. All in all golang is not an elegant language.

O'Caml is similar, now that it has multicore. Scala is also similar, though the native code side ( https://scala-native.org/en/stable/ ) is not nearly as well developed as the JVM side.

The problem with O'Caml is it won't get popular because people are afraid of FP. But I would be totally down to use it.

Re: A 10x Faster TypeScript

#387

Earlier quoted context omitted.

C# can create single-binary executables, even without native AOT.

They are still going to significant bigger than the equivalent golang binary because of the huge .NET runtime, no?

Depends on how well trimming works. It's probably still larger than Go even with trimming, but Go also has a runtime and won't produce tiny binaries.

Re: A 10x Faster TypeScript

#388
post #380
post #125

Earlier quoted context omitted.

Maybe they'll also be distributed in WASM too, which is easier to be integrated with JavaScript codebases.

Would running WASM be any faster than running JS in V8?

Interop with a WASM-compiled Go binary from JS will be slower but the WASM binary itself might be a lot faster than a JS implementation, if that makes sense. So it depends on how chatty your interop is. The main place you get bogged down is typically exchanging strings across the boundary between WASM and JS. Exchanging buffers (file data, etc) can also be a source of slowdown.

Re: A 10x Faster TypeScript

#389
post #284

Earlier quoted context omitted.

This is what I would have liked too: Figure out a sufficient subset of TypeScript that can be compiled to native/WASM and then write TSC in that subset. While I like faster TSC, I don't like that the TypeScript compiler needs to be written in another language to achieve speed; it kind of reminds everyone that TS isn't a good language for complicated CPU/IO tasks. Given that the TypeScript team has resigned to the fac…

This already exists, Static TypeScript https://makecode.com/language https://www.microsoft.com/en-us/research/publication/static-...

If it is not supported by the same team that supports typescript it is not really usable in real world applications.

Re: A 10x Faster TypeScript

#390
post #324

Earlier quoted context omitted.

An unpopular pick that is probably more low level than Go but also still has a GC: D. Understandable why you wouldn't pick D though. Its ecosystem is extremely small.

I think you D fans need to dogfood a startup based around it. It's a fascinating language, but it lacks a flagship product. I feel the same way about Haxe. Someone created an amazing language, but it lacks a big enough community. Realistically languages need 2 things for adoption. Momentum and ease of use. Rust has more momentum than ease, but arguably can solve problems higher level languages can't. I'm half imagini…

Did my post come off as a fan? I directly criticized its ecosystem. It wouldn't be my first pick either. I was just making conversation that there are other options.

And AFAIK Symmetry Investments is that dogfood startup.

Post reply on HN