This comment by Anders Hejlsberg on the choice of languages for TypeScript is worth reading. Spead that type of thinking! (And recognize the massive shift that Microsoft made)
Comments
Log in with your Bluesky account to leave a comment
GitHub has so many problems like this. My favorite is "Reference in a new issue" which doesn't do anything when clicked. Beyond that, the PR review flow is a complete mess. Would be really nice for someone to displace GitHub rather than replicate it.
One of the things he mentioned was Go could easily traverse the graph ASTs.. I'm not a Rust dev but was it just a skill issue or does Rust truly not have a way to mark an entire graph of nodes as having the same lifetime? Would it have to be an arena or a vec that uses indexes back into itself?
Yes and no; Rust's perspective is that all memory has a single owner and only that owner mutate that memory without synchronization. If your graph is made of pointers and contains cycles, and you try to use normal Rust references for these pointers then you'll have a bad time.
You'll want to represent the graph as a single data structure owned by a single owner, and the intra-graph references are 'static from that point of view. Once you traverse the graph, you use a separate lifetime to show when the graph invalidates: You can now mut nodes without invalidating. Easy-ish
"Existing codebase of 100-man years of investment"
I love the idea of sizing software projects complexity in experimentation time. It's not much the effort, but the time put in ideation, testing and validation to assess the amount of requirements that it satisfies. Nice eng talk, thx for sharing
It's hyper business/PR-speak.
And when LLMs are trained on endless emails and linkedin posts (both of which Microsoft has massive access to) ... Then LLMs tend to produce the same thing
"Idiomatic Go looked just like our existing codebase so the port was greatly simplified."
Engineers so dramatically underestimate the value of ergonomics upsides like this. We want to believe that technical upsides outweigh it, but given a comparable field of outcomes, they absolutely don't.
I saw an interview with him where he gave a slightly more informal but still completely pragmatic answer. He had a super grounded perspective that reminded me of the most reliable software engineers I've worked with.
Microsoft's willingness to use the right tool for the job (even when it's not their own technology) shows a technical maturity that might actually lead to better products in the long run.
For what potential benefit? Is it something you're porting from an existing (slow) implementation and you want to maximize the perf wins? Are there paradigms of the "legacy" version that map better to another language/platform than to C#? Or are you just hoping to keep it "hip" and "modern"?
it's a language and a transpiler and a floor topping and a dessert wax, but I notice that no one cried about Microsoft not having built it in C# when it was built in JavaScript
I know developers are very ready to see Microsoft as throwing them under the bus, ever since the 'but we need Silverlight, you can't take it away from us' days, but this is about choosing a language that fits the existing patterns in the existing codebase so that you can port it not rewrite it
to make C# the right choice, you have to go back in time and have the typescript team write their code in ways that will be easy to port to C# if they ever need to do that; or you have to privilege choosing C# to 'send a message' over all the needs of the project itself
They have every right to choose the language that best suits them. But make no mistake people will use this as a data point on why they should also use go over c# regardless of their circumstances.
When used as a language server it is run out of process and communicated with using jsonrpc over stdio so no difference. Unless things have changed since I wrote the ls support for Atom.
Comments
Still, data per character wise, Jake's comment feels like it captures the situation incredibly well, concisely.
https://bsky.app/profile/jakebailey.dev/post/3lk4du4fpec2l
But there are ways.
I love the idea of sizing software projects complexity in experimentation time. It's not much the effort, but the time put in ideation, testing and validation to assess the amount of requirements that it satisfies. Nice eng talk, thx for sharing
https://github.com/microsoft/typescript-go/discussions/410
There are like 3 layers of separation
(Also yay faster typescript)
And when LLMs are trained on endless emails and linkedin posts (both of which Microsoft has massive access to) ... Then LLMs tend to produce the same thing
Engineers so dramatically underestimate the value of ergonomics upsides like this. We want to believe that technical upsides outweigh it, but given a comparable field of outcomes, they absolutely don't.
https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12476218
He replied again making the comment linkable
Microsoft have already demonstrated multiple times it doesn't think C# is the right tool for the job for Windows or cross-plat desktop apps.
What's left?
And yet here I am thinking I should consider a different language for a cmd line tool I'm working on.
If most people are using go to write command line tools these days then I should probably do as well.
Still didn't read a vote of no confidence for .NET command line tools.