Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

841–850 of 943 posts

Re: A 10x Faster TypeScript

#841

Earlier quoted context omitted.

> Even a bit of support for Godot's C#( help them get it working on web), would be great. They did that. https://godotengine.org/article/introducing-csharp-godot/ At least some initial grant to get it started. Getting C# working on web would be an amazing. It is already on the roadmap but some sponsorship would help tremendously for sure.

Ok. Credit where credit is due, but considering the sheer value of having the next general of programmers comfortable with .net, Microsoft *should* chip in more.

It seems Microsoft is not betting on C# and I think the main reason for this is that C# isn't futureproof because of it's ugliness.

It is a powerful and robust language with great standard library, but you just cant be comfortable with it. All those boilerplate, all those sealed override virtual public protected or whatnot before each statement, those curly braces everywhere. You are always inside classes that are inside namespace, and even then you need to go deeper and have curly braces with properties and arrows in random places. Delegates and Events are ugly and unintuitive, two set of syntax for linq (and honestly for almost any somewhat new feature of the language), ref in out, you name it. It is hard to push something so inelegant.

Re: A 10x Faster TypeScript

#842

I 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…

AI tooling is the new wave of Assembly => Compilers transition.

It won't happen tomorrow, but I am quite certain eventually it will be in a position where executables are generated directly, and we will enter into a new computation model.

Like you can nowadays still inspect the generated Assembly, and eventually fine tune it, our AI tools of the future might provide a similar approach.

Re: A 10x Faster TypeScript

#843

Earlier quoted context omitted.

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.

Saying that Microsoft is "Rewriting Windows in rust" suggests you might not be as informed as you think... Very specific components with history of performance or security issues are getting ported in a very uncoordinated effort. Windows will be primarily C, C++, and C# for a very long time to come

Re: A 10x Faster TypeScript

#844
post #247

Earlier quoted context omitted.

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.

There is nothing automatic in that.

Re: A 10x Faster TypeScript

#846
post #803
post #647

Earlier quoted context omitted.

> I fundamentally disagree that those languages are "unusable beyond very narrow tasks" Then why do you think nobody uses them (outside of certain narrow tasks)? It is hard to deny the results. The reality is that they are intractable. For the vast majority of programming problems, testing is good enough and far, far more practical. There is a very good reason why the languages people normally use (yes, including C#…

> Then why do you think nobody uses them (outside of certain narrow tasks)? It is hard to deny the results. > The reality is that they are intractable. For the vast majority of programming problems, testing is good enough and far, far more practical. There is a very good reason why the languages people normally use (yes, including C# and Rust) prefer testing over types. Deny what results? Do you have some kind of for…

> Deny what results?

The results of software written in languages with robust type systems. Having mathematical guarantees that your program is correct is a good place to be, but climbing the mountain to get there is, well...

> Do you have some kind of formal demonstration that they are impossible to use outside of those "certain narrow tasks" (unknown)? Or do you have proof that NOBODY use them for more than those "certain narrow tasks"?

See, now you're starting to understand exactly why these languages are intractable. But perhaps we can dumb things down to my mere mortal level: Why don't you use those languages for regular programming tasks?

> To "I know better than a lot of developers how to test"

How, exactly, did you reach that conclusion? You don't have to be good at something to recognize when people are bad at something.

> but it eliminates the need for a whole suit of smaller tests that would be necessary in less powerful languages

What kind of small tests are you envisioning?

Furthermore, even if we grant that statement as being true for the sake of discussion, there is still the problem that the primary intent of tests is to offer documentation. That the documentation is self-validating is the reason you're not writing it in Microsoft Word instead, but that is really a secondary benefit.

If you defer to the type system then you're moving some, but not all, of the documentation into the type system, fragmenting the information. Is that fair to other developers? In reality, you're going to want to write the tests anyway for the sake of consistency and completeness. A programmer needs to deliver something that works, of course, but also something that does a good job of communicating to other developers what is going on. Programming is decidedly not a solo activity.

Sure, in an ideal world you could document the entire program in the type system, but the languages people normally use simply don't have what it takes to enable that. They lean on testing instead. Worse is better, I suppose.

> Make an example test that "incidentally tests things like the shape" in C#, please.

We should probably talk about my fee structure first. I don't want you coming back crying that it was too much when I send you the bill for the work performed.

That said, under my professional duty to act your interest, I expect you would far better served thinking about how you might go about avoiding testing the shape given a random useful test. You don't really need my services here.

> I would not call Rust's type system 'half-assed' tho

It doesn't even have proper support for something basic like value constraints, let alone more advanced concepts. It has more features than Go, but I fail to see how that offers transcendence beyond half-assery. I'll grant you that it is less half-assed, just as I did earlier.

Re: A 10x Faster TypeScript

#847

I 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…

I think it's smart to start with a high level language which should reduce development time, prove the worth of the application, then switch to a lower level language later. What was that saying again? Premature optimisation is the root of all evil

I think that early in development you should be able to spam a lot of hypothesis and quickly test them and check how people interact with your software. Whether your software makes sense is more important than whether it's fast.

People are also highly unpredictable, so it is usually a matter of trial and error, very often their feedback may completely erase wide sets of assumptions you were building your product around.

It's borderline impossible to do it on mature product, but rewriting mature product to something faster is not borderline impossible - it's just very hard.

Note that it doesn't apply if you just program something in accordance from an rfc where everything is predefined.

Re: A 10x Faster TypeScript

#848

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.

Actually, they have their own Go compiler.

https://devblogs.microsoft.com/go/

Just like they have their own Java distribution, after everything that caused C# to exist in first place,

https://devblogs.microsoft.com/java/

Yes, the new DevDiv is not like the Microsoft of old.

But then the .NET team shouldn't be asking every now and then on social media, why other languages get chosen, outside the Windows ecosytem.

Re: A 10x Faster TypeScript

#849

Earlier quoted context omitted.

The fact that many software products are moving to lower-level languages is not a general point in favour of lower-level languages being somehow better—rather, it simply aligns with general directions of software evolution. 1. As products mature, they may find useful scenarios involving runtime environments that don’t necessarily match the ones that were in mind back when the foundation was laid. If relevant parts ar…

I'm not here to predict the future, rather to reconsider old assumptions based on new evidence. Of course, LLMs may stay as "autocomplete" forever. Or for decades. But my intuition is telling me that in the next 2-3 years they are going to increase in capability, especially for coding, at a pace greater than the last 2 years. The evidence that I have (by actually using them) seems to point in that direction. I'm perf…

> Given LLM assistance, why wouldn't I write my web app layer in Rust or Zig?

Same reasons as with no LLM assistance. You would be choosing higher maintenance burden and slower development speed compared to your competitors, though. They will get it out faster, they will have fewer issues, and will be able to find people to support it more easily. Your product may run faster, but theirs will work and be out faster.

Re: A 10x Faster TypeScript

#850

Hi folks, Daniel Rosenwasser from the TypeScript team here. We're obviously very excited to announce this! RyanCavanaugh (our dev lead) and I are around to answer any quick questions you might have. You can also tune in to the Discord AMA mentioned in the blog this upcoming Thursday.

Does the mean the future toolset will be less reliant on NPM (etc)?

Maybe I'm unique, but I prefer to not have the compiler tied up with a paryicular dependency-management/library system.

Post reply on HN