Go-based TypeScript 7.0 Finally Reaches Release Candidate Stage (infoworld.com)
- Reference: 0184323780
- News link: https://developers.slashdot.org/story/26/07/05/2335217/go-based-typescript-70-finally-reaches-release-candidate-stage
- Source link: https://www.infoworld.com/article/4191918/typescript-7-0-reaches-release-candidate-stage.html
> TypeScript 7.0 is often about 10 times faster than [5]TypeScript 6.0 , Microsoft said, thanks to native code speed and shared memory parallelism... Unlike TypeScript 6.0, TypeScript 7.0 performs many steps in parallel, including parsing, type checking, and emitting, Microsoft said. Some of these steps, such as parsing and emitting, can mostly be done independently across files. For that reason, parallelization automatically scales well with larger codebases with relatively little overhead. However, not every step in a TypeScript build is easily parallelizable, Microsoft said.
Microsoft plans to release TypeScript 7.0 within the next month, the article points out, but developers can try the new compiler by installing it from the typescript package on npm: npm install -D typescript@rc
[1] https://developers.slashdot.org/story/25/03/15/0233243/why-microsofts-developers-are-porting-typescript-to-go
[2] https://www.youtube.com/watch?v=pNlq-EVld70
[3] https://github.com/microsoft/typescript-go/discussions/411
[4] https://www.infoworld.com/article/4191918/typescript-7-0-reaches-release-candidate-stage.html
[5] https://www.infoworld.com/article/4149659/typescript-6-0-arrives.html
Re: Huh? (Score:2)
A set on constraints that make it easier to detect errors on build rather than at runtime.
Re: (Score:2)
> What does that even mean? What is a "type"?
Data types: like, this variable holds a number, and this other variable holds a string. JavaScript is dynamically-typed, which provides flexibility but also means it's easy to make mistakes because it's not always clear at development time what the type of a value will be at run time. TypeScript adds a statically-typed layer on top, where you declare the intended types up-front and the "compiler" (technically transpiler) uses them to check for type-related error
Emitting? (Score:3)
Is that anything like squirting? I ask because Microsoft used to be really big on that...
Previously written in JavaScript (Score:2)
After reading opening paragraph, that was my first question.
The [1]other slashdot article [slashdot.org] has a bit more info, specifically that they tried various other languages including C#.
Seems to me that pretty much any language will be faster than JavaScript, even php!
[1] https://developers.slashdot.org/story/25/03/15/0233243/why-microsofts-developers-are-porting-typescript-to-go
But why? (Score:2)
Why are people so hung up on using typescript instead of using a compiled language? If you want speed then using a compiled language is the only way to go.
Re: (Score:2)
Because TypeScript is just JavaScript once the types are stripped out... and JavaScript has the superpower of running on the largest platform in the world: the web browser.
WebAssembly cannot directly access the browser DOM, cannot directly handle network requests, and requires JavaScript to act as a bridge for almost all web interactions
I wish (Score:1)
Typescript evolved into a standalone programming language that can be compiled into a static distribution the way that golang does. I wish it had a true multicore parallelism.
Yes, it wasn't rewritten into rust. (Score:1)
While I love Rust, I understand why Go was selected over Rust. If you compare the two languages, they are relatively similar and allow the same approaches to problems.
Rust though... it would have required rethinking everything while needing to keep an amount of backward compatibility.
Go
> func greet(name string) string {
> return "Hello, " + name
> }
Typescript
> function greet(name: string): string {
> return "Hello, " + name;
> }