No, it's not TypeScript that is 10 times as fast, only the TypeScript compiler. Bad title. Also, "10x faster" would be a factor of 11.
A 10x Faster TypeScript
831–840 of 943 posts
Re: A 10x Faster TypeScript
#832Earlier quoted context omitted.
Go exposes raw pointers to the programmer, so from your description i think those semantics are too rudimentary to implement Go's semantics, there would need to be a WasmGC 2.0 to make this work. It sounds like it would be a great fit for e.g. Lua though.
I don't think Go supports any pointer arithmetic out-of-the-box? What it has in the base language is effectively references.
It does, via unsafe package, yes it does look ugly, that is on purpose.
item := *(*int)(unsafe.Pointer(uintptr(start) + size*uintptr(i)))
Re: A 10x Faster TypeScript
#833Earlier quoted context omitted.
That, and then deal with all the gotchas.
There are none in new projects. There are few in existing ones. I guess it is difficult to have a conversation with someone who is committed to looking for the aforementioned "gotchas".
I generally agree that C# == Java == Go in most aspects and have far more and generally think C# is nicer to use and probably faster for many use cases. But, it is not the same as Go at all in terms of AOT. In golang that is just the default and always works - basically on all platforms, in C#, that is not the case. Do you really want to find out that a popular library uses some reflection and therefore doesn't work half way through the project?
In my opinion, using C# for this use case isn't a practical choice on a greenfield project.
Re: A 10x Faster TypeScript
#834Earlier quoted context omitted.
I have no idea about the details of their test cases. If they had used an even faster language like Cobol or Fortran maybe they could have gotten it 1,000,000x faster. What I do know is that some people complain about long compile times in their code that can last up to 10 minutes. I had a personal application that was greater than 60k lines of code and the tsc compiler would compile it in about 13 seconds on my supe…
> maybe they could have gotten it 1,000,000x faster. WTF.
Yeah this is an overly exaggerated claim
Re: A 10x Faster TypeScript
#835Earlier 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/…
They do, Unreal and Unity tooling for Visual Studio, it is even part of the installer.
Also some of the low level improvements on C# have been done with collaboration with Unity team's requirements, regarding their Burst use cases.
Re: A 10x Faster TypeScript
#836Earlier 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…
Personally, I want to know why Go was chosen instead of Zig. I think Zig is really more WASM-friendly than Go, and it's much more similar to JavaScript than Rust is. Memory management? Or a stricter type system?
Zig still isn't production ready and isn't memory safe as Go, most likely.
Re: A 10x Faster TypeScript
#837Earlier 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!
It is already there, kind of, the original Visual Studio Code plugin was actually done by Microsoft, and at a later point given to Google for further development.
"VS Code Go Language Extension Goes from Microsoft to Google"
https://visualstudiomagazine.com/articles/2020/06/10/go-goes...
Re: A 10x Faster TypeScript
#838Earlier quoted context omitted.
| with no frills. People say this like it's a bad thing. It's not, it's Go's primary strength.
I can see the appeal. Not having to write C# style oop probably gave the team a huge productivity boost. I bet it compiles hundreds of times faster making the team, cicd, and dev efforts substantially more productive. Cohesive integrated modern tooling is also a huge plus. Project structure is considerably simpler... I am not really a go fan but I would chose it over c# in a majority of cases as well. I think they mi…
> I think they missed out by not going with Rust. It seems like the social factors weighed out.
They absolutely address this in the linked article, so why are we even speculating here?
> Probably hard to quickly assemble a rust team within msft.
The same MSFT that is rewriting their Windows OS in rust as we speak? I think you should stop commenting when you don't know anything about the subject.
Re: A 10x Faster TypeScript
#839Earlier quoted context omitted.
The reason they didn't do Rust is because it was faster and more reliable to port the compiler and Go was a strong match particularly because of struct layout, types, concurrency, etc. but most importantly because it was native code with automatic garbage collection which Rust simply doesn't have. There's a video of Anders talking specifically about this.
The automatic gc doesn't seem like an actual deal breaker though. They probably just didn't want to redesign a bunch of data types that assumed one existed. I'm not arguing saying they made a bad call. I think what they did was smart with the options in front of them and whatever budget they have. The world isn't good for idealism, but it ideally could have been written in rust in my opinion.
> They probably just didn't want to redesign a bunch of data types that assumed one existed.
Dude, just read the article being discussed, this is addressed so you can just stop making shit up.
The audacity of people like you to just keep adding speculations upon speculations on a subject without even bothering to learn what is being discussed.
Re: A 10x Faster TypeScript
#840Earlier quoted context omitted.
There are none in new projects. There are few in existing ones. I guess it is difficult to have a conversation with someone who is committed to looking for the aforementioned "gotchas".
I generally agree that C# == Java == Go in most aspects and have far more and generally think C# is nicer to use and probably faster for many use cases. But, it is not the same as Go at all in terms of AOT. In golang that is just the default and always works - basically on all platforms, in C#, that is not the case. Do you really want to find out that a popular library uses some reflection and therefore doesn't work…
You may want to read the documentation first before responding.