Meanwhile .NET developers are still waiting for Microsoft to use their own "inventions" like Blazor, .NET MAUI, Aspire, etc. for anything meaningful. Bless them.
Bing is made with ASP .net
A 10x Faster TypeScript
791–800 of 943 posts
Re: A 10x Faster TypeScript
#792Earlier quoted context omitted.
They're not "definitely" an AI. Sounds like a normal Go enthusiast to me.
A Go enthusiast who’s never heard of esbuild? Not impossible, but unlikely.
So, a go enthusiast who does exclusively backend work? Seems likely enough, given that community's overall disdain for Javascript.
Re: A 10x Faster TypeScript
#793I 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…
> And it isn't that hard these days to spin up a web server with simple routing, database connectivity, etc. in pretty much any language including Zig or Go Just two years ago, a friend of mine described it as quite a hassle to get a RESTful backend running in Go. He got it working but it was more work than usual. Was he an outlier or have things been getting better in the framework department?
Not sure when your friend tried Go but for the last 5-10 years or so go has been really easy to make REST services. It's practically baked into the language but if you want it even easier there are several extremely popular libraries for it.
Go tends to have more boiler plate than other languages. So more typing work, less thinking work, less maintenance work once completed.
Re: A 10x Faster TypeScript
#794Earlier quoted context omitted.
Rust memory management is automatic. Object destructors run when the object exits scope without needing explicit management by the programmer
More like compiler assisted management, with compiler errors when the developer doesn't follow the teacher.
The compiler ensures you are writing memory safe code. Otherwise it rejects that code and helps you see the mistake you made. Why people are so upset when the compiler prevents them from building and shipping unusable code will always baffle me.
Re: A 10x Faster TypeScript
#795Sad to see them using Go and not Anders’s own language (Turbo Pascal 7) for this
There should be an award for this comment.
Re: A 10x Faster TypeScript
#796Earlier quoted context omitted.
Also, this is surprising because this was presented and led by Anders Hejlsberg, who is the creator of both C# and Typescript. If anyone should have picked C# it would be him.
At the same time, if anyone can make a language choice, it's him - the fact he didn't pick his own language is high praise for both himself and his neutrality, and the Go language.
Go compiler tooklit works very well on all the OSes. That would be a consideration.
Re: A 10x Faster TypeScript
#797Earlier quoted context omitted.
This is not "the main reason", lol, it was never stated as such. The type system could be way more powerful and, having the same general features they would probably had still picked it up.
What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language. Let's be real: You can absolutely write "Go-style" code in just about any language that might have been considered for this. But you wouldn't want to, as a more advanced type system enables entirely diffe…
> What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language.
I would say structural typing is very "esoteric" for most strongly typed languages actually, but this is not a problem.
And proceeding, the implications of your response is very strange. See, your point is essentially saying that "we should use Go, because it entails writting in only one idiom, and writing in languages that enables you to do more idioms -- more powerful languages -- is bad faith to other developers", but Hejlsberg himself said he chose go because of specific characteristics of the compiler that was already written, not because it is "the ideal one for every single prospect", while your point has implications that are absolutely more general. So I don't think he would agree with you that this was his reasoning for using go (the "don't have other idioms" thing), I also don't think this whole "more idioms" thing even make sense, but this is not needed to respond to this.
Re: A 10x Faster TypeScript
#798Earlier quoted context omitted.
Like others I'm curious about the choice of technology here. I see you went with Go, which is great! I know Go is fast! But its also a more 'primitive' language (for lack of a better way of putting it) with no frills. Why not something like Rust? Most of the JS ecosystem that is moving toward faster tools seem to be going straight to Rust (Rolldown, rspack (the webpack successor) SWC, OXC, Lightning CSS / Parcel etc)…
| 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 missed out by not going with Rust. It seems like the social factors weighed out. Probably hard to quickly assemble a rust team within msft. Again though that makes Go a practical choice. I don't see why people are so confused by it. Go is a pretty widely used and solid choice to get things done reliably and quickly these days.
Re: A 10x Faster TypeScript
#799Earlier 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…
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…
I'm not saying this to start a language war but. Look at the cognitive complexity and tooling complexity involved in a c# project. Seriously, every speed bump you hit in your ide think about how many pieces of knowledge you assemble to solve it. Similarly think about the overhead in designing both the software and tests. Think about cross platform builds and the tooling required to stand up ops infrastructure. Measure the compilation time. Think about the impedance mismatch between ts and c#.
Compare that to go. It's not even close. I see comments bickering about the size of executable files... Almost no major product cares about that within order of magnitude.
Go is a wild choice to write a compiler in. Literally in my top 10 things I never want to do. Everything else about it drove them to do it.
Re: A 10x Faster TypeScript
#800Earlier quoted context omitted.
The c# benchmarks where they didn't use the framework to do any of the actual templating? those hardcoded byte arrays are how everyone does templating everywhere right? or are you talking about after they changed back their "platform" test to not do that and is substantially slower than go https://dusted.codes/how-fast-is-really-aspnet-core
This is sorely outdated. Although for anyone with an axe to grind dustin’s articles are convenient enough.
[dead]