TypeScript passa a GO
Mario Alexandro Santini
* language server
La nuova versione sarà più veloce e manterrà tutte le caratteristiche della precedente.
Si prevede che il porting sarà ultimato per il 2025, mentre il compilatore dovrebbe essere disponibile a breve.
Ecco un articolo che ne parla:
https://2ality.com/2025/03/typescript-in-go.html
Mario
Luca Guadagnini
Mario Alexandro Santini
C'è già gente che si straccia le vesti perché non è stato usato Rust, ma i motivi sono stati tutti riassunti in: pragmaticità. Il che ha senso tutto sommato.
Sono abbastanza curioso, non che abbia tutta questa simpatia per Typescript, ma il fatto che possa compilare in nativo con un GC già incluso potrebbe essere interessante.
Saluti!
mick...@posteo.net
On 18.03.2025 08:17, Mario Alexandro Santini wrote:
>
> Il risultato sarà comunque sempre JavaScript e non qualcosa tipo
> WASM.
>
ho pensache che, lavorando in typescript/Angular da un anno
a questa parte, non avevo capito nulla!
>
> Il runtime non dovrebbe avere variazioni.
>
browser, e quindi potenzialmente cambia da utente ad utente.
--
Michele
Mario Alexandro Santini
Stavo appunto per chiedere conferma, perché per un attimo
ho pensache che, lavorando in typescript/Angular da un anno
a questa parte, non avevo capito nulla!
Anche perché il runtime, correggetemi se sbaglio, sta nel
browser, e quindi potenzialmente cambia da utente ad utente.
--
Michele
mick...@posteo.net
> il punto è che si sono moltiplicati i compilatori TypeScript per via
> dei problemi di performance.
> Si tratta di casi dove i progetti sono molto grandi e la compilazione
> richiede un tempo considerevole.
attuale ci mette svariatiminuti. Ordine di grandezza superiore per
eseguire la batteria di test unitari, ma questo credo vada oltre al
compilatore soltanto.
--
Michele
Mario Alexandro Santini
Non so quale possa essere un "tempo considerevole", nel mio progetto
attuale ci mette svariatiminuti. Ordine di grandezza superiore per
eseguire la batteria di test unitari, ma questo credo vada oltre al
compilatore soltanto.
--
Michele
Luca Guadagnini
Ciao Luca,On Mon, Mar 17, 2025 at 11:21 PM Luca Guadagnini <luca.gu...@gmail.com> wrote:C'è già gente che si straccia le vesti perché non è stato usato Rust, ma i motivi sono stati tutti riassunti in: pragmaticità. Il che ha senso tutto sommato.:)In realtà no: https://github.com/swc-project/swc
why not Rust?
Anders: When you have a product that has been in use for more than a decade, with millions of programmers and, God knows how many millions of lines of code out there, you are going to be faced with the longest tail of incompatibilities you could imagine. So, from the get-go, we knew that the only way this was going to be meaningful was if we ported the existing code base. The existing code base makes certain assumptions -- specifically, it assumes that there is automatic garbage collection -- and that pretty much limited our choices. That heavily ruled out Rust. I mean, in Rust you have memory management, but it's not automatic; you can get reference counting or whatever you could, but then, in addition to that, there's the borrow checker and the rather stringent constraints it puts on you around ownership of data structures. In particular, it effectively outlaws cyclic data structures, and all of our data structures are heavily cyclic.
adding it all up: Go makes a lot of sense
Anders: When we go down the list, we want a language that gives us excellent optimized native code on all major platforms. We want a language that has great expressiveness in data structures, allows cyclic data structures, but also allows inline data structures like structs -- so that, you know, in JavaScript everything you do with an object is an allocation, and we would rather avoid that, especially for small objects if we can store them inline. We need automatic garbage collection, and we also needed concurrency -- and shared memory concurrency. We can talk about the distinction there, because technically JavaScript has concurrency with web workers, but it does not have shared memory concurrency. I can explain why we need that for the compiler, but that was also a must. And when you look at all of that -- and then, of course, we want good tooling (we all live in VS Code, we want excellent support in VS Code, and whatever) -- when you add all of that up, Go actually ended up coming very high on the list.
Sono abbastanza curioso, non che abbia tutta questa simpatia per Typescript, ma il fatto che possa compilare in nativo con un GC già incluso potrebbe essere interessante.Credo ci sia un fraintendimento.Quello che è stato riscritto in Go è il compilatore TypeScript/JavaScript.
Il risultato sarà comunque sempre JavaScript e non qualcosa tipo WASM.Le performance di cui parlano sono relative alla fase di build e anche per lo sviluppo.Il runtime non dovrebbe avere variazioni.Saluti!Mario
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Socraten" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a socraten+u...@googlegroups.com.
Per visualizzare questa discussione, visita https://groups.google.com/d/msgid/socraten/CAMUoZedV4Dt8aPgO2nXyxOxwPtKg1aM_yK6oDuhBCQ6hiWfJkQ%40mail.gmail.com.
Mario Alexandro Santini
Sì beh mi stavo riferendo al progetto di Microsoft, non altrui :) in un'intervista rilasciata è stato riportato questo: