The news for me is Microsoft teams relying on Go.
Strange choice to use Go for the compiler instead of C# or F#.
Now if they will have problems, they will depend on the Go team at Google to fix them.
A 10x Faster TypeScript
721–730 of 943 posts
Re: A 10x Faster TypeScript
#722Earlier quoted context omitted.
Yes, but C# is the Microsoft language, and I would say TypeScript is 2nd place Microsoft language (sorry F# folks - in terms of popularity not objective greatness of course). So it's not just that the lead architect of C# is involved in the TypeScript changes. It's also that this is under the same roof and the same sign hangs on the building outside for both languages. If Ford made a car and powered it with a Chevy e…
funny you bring up this analogy. tons of auto manufacturers these days will license other mfgs' engines and use them in your cars. e.g. a fair number of Ford's cars have had Mazda engines and a fair number of Mazdas have had Ford engines.
Could you give some examples of both? Also, why did they choose to do this?
Re: A 10x Faster TypeScript
#723Earlier 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…
[flagged]
Microsoft's implementation has been cross platform for almost a decade now. You're way too late to the Mono FUD party.
Re: A 10x Faster TypeScript
#724Earlier quoted context omitted.
.NET has been able to build a self contained single file executable for both the JIT and AOT target for a quite some time. Java also does not require the user to install a runtime. JLink and JPackage have both been around for a long time.
C# AOT filesizes are huge compared to Go.
Do you have data backing that up? Per https://github.com/MichalStrehovsky/sizegame:
C#: 945 kB Go: 2174 kB
Both are EXEs you just copy to the machine, no separate runtime needed, talks directly to the OS.
Re: A 10x Faster TypeScript
#725I 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…
> the lowest level representation that allows me some ergonomics
The ergonomics of compiling your code for every combination of architecture and platform you plan to deploy to? It's not fun. I promise.
> my default assumption to use JS runtimes on the server
AWS Lambda has a minimum billing interval of 1ms. To do anything interesting you have to call other APIs which usually have a minimum latency of 5 to 30ms. You aren't buying much of anything in any scalable environment.
> there is decreasing utility in familiarity with a language to be productive.
I hope you aren't planning on making money from this code. Either way, have fun debugging that!
> the advantages of scripting languages are being eroded away.
As long as scripting languages have interfaces which let them access C libraries either directly or through compiled modules they will have strong advantages. Just having a CLI where you can test out ideas and check performance is massively powerful and I hate not having it in any compiled project. Go has particularly bad ergonomics here as writing test cases are easy but exploring ideas is not due to it's strictness down to even the code styling level.
Re: A 10x Faster TypeScript
#726Even 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.
> that seems to be the norm now.
According to whom?
Re: A 10x Faster TypeScript
#727Earlier quoted context omitted.
> That is not my intention. Perhaps you are reading absolutes and chasing after black and white statements. The first comment I wrote in this thread was a response to the following quote: "Yet projects inevitably get to the stage where a more native representation wins out." Inevitable means impossible to evade. That's about as close to a black and white statement as possible. You're also completely ignoring the subs…
Ah, now we're at the dictionary definition level. So let's check Google: Inevitable: as is certain to happen; unavoidably. informal as one would expect; predictably. "inevitably, the phone started to ring just as we sat down" Which interpretation of the word is "good faith" considering the rest of my post? If I said "If you drink and drive you will inevitably get into an accident" - would you argue against that state…
I wrote 362 words on why language rewrites are a faulty indicator of language quality with multiple examples and anecdotes, and you hyper-fixated on the very first sentence of my comment, instead of addressing the substance of my claim. In what alternate universe is that a good faith argument? If you were truly arguing in good faith you'd restate your position in whichever way you'd like your argument represented, and then proceed to respond to something besides the first sentence. Regardless of how strongly or weakly you believe that "native representations win out", my argument about misusing language rewrite anecdata still stands, and it would have been far more productive to respond to that point.
> If I said "If you drink and drive you will inevitably get into an accident" - would you argue against that statement?
If we were having a discussion about automobile safety and you wrote several hundred words about why a specific type of accident isn't indicative of a larger trend, I wouldn't respond by cherry picking the first sentence of your comment, and quoting Google definitions about a phone ringing.
Re: A 10x Faster TypeScript
#728I 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…
"A sufficient smart compiler..."
Re: A 10x Faster TypeScript
#729Earlier quoted context omitted.
funny you bring up this analogy. tons of auto manufacturers these days will license other mfgs' engines and use them in your cars. e.g. a fair number of Ford's cars have had Mazda engines and a fair number of Mazdas have had Ford engines.
Could you give some examples of both? Also, why did they choose to do this?
Toyota 86 and Subaru BRZ are basically the same car. The car was designed by Toyota while Subaru supplied the engine. Just one example.