Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

Post reply on HN
Print view View original

931–940 of 943 posts

Re: A 10x Faster TypeScript

#931

Post by WorldMaker »

Ray20 wrote: post #841
999900000999 wrote: post #399

Earlier quoted context omitted.

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

A lot of the last few C# compiler versions have been about "boiler-plate" reduction. Namespaces don't need curly braces any more and are just a single line at the top. You can write some top-level code inside a namespace without it needing to be in a class. More of the properties and method bodies that are simple can also be written entirely with arrows without curly braces.

Delegates and Events were a mistake, but that's a low-level .NET mistake that a lot of modern code can easily ignore, with Action and Func now reliably almost everywhere and WinForms easy to write off as "dead". (You can especially eliminate the need for the ugliness of Delegates and Events with System.Reactive.Linq.)

Records and Primary Constructors remove a ton of the boiler-plate of writing basic "DTOs" and/or dependency injection.

C# is pretty elegant, and a nicely evolving language. Microsoft isn't any longer trying to bet on C# as a "systems programming language" because too many people see JIT support and VMs as "not low level enough" (including apparently also Anders Hejlsberg), but that doesn't mean C# isn't "future proof".

Re: A 10x Faster TypeScript

#932

Post by rat9988 »

Cthulhu_ wrote: post #766
9rx wrote: post #416

Earlier quoted context omitted.

More specifically, the guy who created C# doesn't believe in it (for this particular project). But, of course, that is not unusual. There is no language in existence that is best suited to every project out there.

And true wisdom is realising that. I have a lot of respect for this fellow and his decisions.

You can have respect for this and his decisions and still think it is doesn't look good for c#.

Re: A 10x Faster TypeScript

#933

Post by maginx »

I'm curious about the 10x via implementation in Go - couldn't it have been realized otherwise? Finding the hotspots, reimplementing them using better algorithms, if necessary move a few critical paths to native etc. Or even improving the JIT itself which might benefit all programs. Just wondering because I wouldn't think that the JIT-overhead was that much that you could gain 10x just reimplementing in Go (or C, assembly etc)... that is something I would only have expected if going from an interpreted context.

Re: A 10x Faster TypeScript

#934

Post by yencabulator »

zozbot234 wrote: post #752
mappu wrote: post #601

Earlier 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.

You can get a pointer inside a struct ("interior pointers") without pointer arithmetic.

Re: A 10x Faster TypeScript

#935

Post by anileated »

zoogeny wrote: post #880
anileated wrote: post #849

Earlier quoted context omitted.

> 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.

Lets imagine we are assembly programmers. You have a particular style of assembly that you believe gives you some advantage over your competitors. The way you structure your assembly gives you a lower maintenance burden and faster development speed compared to your competitors. I show up and say "I have a C compiler". Does it matter at that point how good your assembly is? All of a sudden I can generate 10x the amoun…

Again, your competitor will get there faster and with fewer bugs. LLMs are trained on human input and humans do not do great at low level languages. They churn out better Python than C and especially when it comes to refactoring it (have observed that personally).

Re: A 10x Faster TypeScript

#936

Post by anileated »

zoogeny wrote: post #898
Vaguely2178 wrote: post #896

Earlier quoted context omitted.

> There are more elements to a compiler than determinism. Yes, but determinism is the factor that allows me to treat compilers as a black box without verifying their output. LLMs do not share this specific property, which is why I have to verify their output, and easily verifiable software is what I call "maintainable".

An interesting question you might want to ask yourself, related to this idea: what would you do if your compiler wasn't deterministic? Would you go back to writing assembly? Would you diligently work to make the compiler "more" deterministic. Would you engineer your systems around potential failures? How do industries like the medical or aviation deal with imperfect humans? Are there lessons we can learn from those d…

> Do people really think a web server written in Go or Rust is unmaintainable?

Things are not black and white. It will be less maintainable relatively speaking, proper tool for the job and all that. That’s why you will be left in the dust.

Re: A 10x Faster TypeScript

#937

Post by tefkah »

maginx wrote: post #933

I'm curious about the 10x via implementation in Go - couldn't it have been realized otherwise? Finding the hotspots, reimplementing them using better algorithms, if necessary move a few critical paths to native etc. Or even improving the JIT itself which might benefit all programs. Just wondering because I wouldn't think that the JIT-overhead was that much that you could gain 10x just reimplementing in Go (or C, asse…

hjalsberg has explained this in some interviews. roughly 3x speed up from going native, another 3-4x speed up from being able to actually do effective multi threading

Re: A 10x Faster TypeScript

#938

Post by Shocka1 »

dustedcodes wrote: post #371

Meanwhile .NET developers are still waiting for Microsoft to use their own "inventions" like Blazor, .NET MAUI, Aspire, etc. for anything meaningful. Bless them.

Doesn't matter. Some could care less what MSFT is doing - a Blazor app I developed in super-speed time has collected 40k transactions in the last 4 months. It did it's job.

Re: A 10x Faster TypeScript

#939

Post by estebarb »

MStrehovsky wrote: post #724
estebarb wrote: post #718

Earlier quoted context omitted.

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.

Sadly yes, we have data. We are migrating our C# SDK to Rust in part because customers want a much smaller dependency. And the AoT compiler didn't trimmed as much as we wanted.

Re: A 10x Faster TypeScript

#940

Post by neonsunset »

estebarb wrote: post #939
MStrehovsky wrote: post #724

Earlier quoted context omitted.

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.

Sadly yes, we have data. We are migrating our C# SDK to Rust in part because customers want a much smaller dependency. And the AoT compiler didn't trimmed as much as we wanted.

(regarding size - there are tools like sizoscope to understand what is taking space, sometimes it’s something silly like rooting a lot of metadata with reflection referencing many assemblies or because of abusing generic virtual members with struct parameters in serialization, obviously if you can use Rust without productivity loss it’s fine, but usually problems like that take an hour or two to solve, or less)

But in either case binary sizes are smaller and more scalable than what Go produces. The assumption that Go is good at compact binaries just does not replicate in reality. Obviously it’s nice to be able not touch it at all and opting into Rust for distributing native SDKs. Go is completely unfit for this as it has even more invasive VM interaction when you use it as dynamically linked library. NativeAOT is “just ok” at this and Go is “way more underwhelming than you think”.

Post reply on HN