Was the Java Service in Spring (boot)?
What other technologies were considerd?
I'd assume Go was among them. Was it just the fact that Go's type system is to simplistic or what were the other factors?
Writing a long winded report/article for fair technical evaluation of competing technologies would utter waste of time and no one would believe if answer were still Swift.
> I'd assume Go was among them. ...
I don't see any reason to evaluate Go at all.
https://devblogs.microsoft.com/typescript/typescript-native-...
X years from now, another language will come along and then they can switch to that for whatever benefit it has. It is just the nature of these things in technology.
Rewriting it in assembly is the way to go, but that has other tradeoffs.
Of course it’s a trade off and their reasons are fine, but rewrites are expensive and disruptive. I would have picked something that can avoid a second rewrite later on.
> unavoidable costly abstractions in Go
Rust is an excellent language for embedding in other languages And underpinning developer tools.
That said, someday the new typescript binary will compile to WebAssembly, and it won’t matter much anyway.
I suspect they wanted the compiler speed more than they wanted a WASM target, though.
I think they already use Go in places, but they’ve clearly stated their intention to use Swift as much as possible where it’s reasonable.
I suspect they didn’t evaluate C++, Rust, Go, Erlang, Node, and 12 other things.
They have the experience from other Swift services to know it will perform well. Their people already know and use it.
If Swift (and the libraries used) weren’t good enough they’d get their people to improve it and then wait to switch off Java.
If you go to a Java shop and say you want to use C# for something Java can do, they’ll probably say to use Java.
I don’t read this post as “Swift is the best thing out there” but simply “hey Swift works great here too where you might not expect, it’s an option you might not have known about”.
I’m not in the .NET ecosystem so I don’t know if native AOT compilation to machine code is an option.
But anyway, in this case Apple is making an internal service for themselves. I think a better comparison for MS would be if they chose to rewrite some Windows service’s server back end. Would they choose Go for that?
I don’t know.
They’d have never touched Go with a 10 foot poll.
The article is just a marketing for a team looking for promo, there’s no deep meaning or larger Apple scheme here.
Azure team has no issues using AI to convert from C++ to Rust, see RustNation UK 2025 talks.
Also they mention the reason being a port not a rewrite, yet they had anyway to rewrite the whole AST datastructures due to the weaker typesystem in Go.
Finally, the WebAssembly tooling to support Blazor is much more mature than what Go has.
First of all, it is a missed opportunity for Microsoft to have another vector for people to learn C#.
Secondly at BUILD session, Anders ended up explaning that they needed to rewrite the AST data structures anyway, given that Go type system is much inferior to Typescript.
And Go's story on WebAssembly is quite poor, when compared with Blazor toolchain, they are hopping Google will make the necessary improvements, required for the TypeScript playground and when running VSCode on the browser.
Finally, some of the key develpers involved on this effort have been layed off during the latest round.
[0] https://devblogs.microsoft.com/typescript/typescript-native-...