Great effort.
Although I tend to be a critic of Go's design, I love projects like these, as they make the point not everything needs to be C or C++ for game development.
Kudos for the project.
Although I tend to be a critic of Go's design, I love projects like these, as they make the point not everything needs to be C or C++ for game development.
Kudos for the project.
Go is compiled, Python - interpreted. Go focuses on concurrency, Python on making it easy to do things with code.
Many things that are a one-liner in Python (but itself or with a library), in Go take quite a lot of lines or boilerplate. For example, there is no built-in string templates in Go.
Or is it Python that is not best compared to "Python 4.0"? Python doesn't live up to the guiding principles of Python, such as preferring only one obvious way to do something. Go is, in many ways, more Python than Python.
> Many things that are a one-liner in Python
Case in point. Many of those one-liners are just as obviously expressed as multi-liners (e.g. list comprehension vs. traditional 'for' loop).
> no built-in string templates in Go.
Another good example. There is no special syntax, but the standard library provides. Special syntax would give two obvious ways to do it.
The only reason so many folks leave Python for Go, is the usual problem of writing C libraries instead of finally having a proper JIT in CPython, and having PyPy being largely ignored by the community.
F# can do that just fine, if the team actually cared about using .NET.
I don't buy any of reasoning why Typescript team adopted Go, first of all the authors are more than knowledgeable about .NET AOT capabilities.
Second as Anders Hejlsberg went through his BUILD 2025 talk, turns out they had to redesign the data structures around Go's weaker type system anyway, as they couldn't easily map what they were doing with TypeScript types.
Third, Azure teams are using AI to convert C++ projects into Rust, as described by Mark Russinovich at RustConf UK 2025, which shows it is up to the challenge at hand.
This matters for these tools because they're usually distributed via npm packages and then invoked by a javascript wrapper. So you want something with a small binary that runs on pretty much every windows/mac/linux system no matter the configuration.
And that for every .net project I can remember, which are far more rare, there's been some complicated installer that does a bunch of stuff. Or it fails to launch telling me I need to install some runtime separately.
But you won't be blaming Go for that, rather the devs that decided to use CGO.
Likewise, when downloading some .NET project, it isn't .NET to blame, if the devs have decided they wouldn't be making use of Mono AOT, Native AOT, or single-file deployment package (with ReadyToRun).
He made it pretty clear that he doesn't compile himself, he downloads pre-built binaries. In one case he finds that once the binary is downloaded, it just runs. In the other he finds it requires additional steps, like needing to go through an arduous installation process, before it runs.
Sure, better devs can figure out how to avoid things like the aforementioned installation process. Great devs aren't limited by their tools. But pointing out that the devs attracted to that ecosystem are not very good doesn't change much. That it requires one to be good echos the "pain" assertion. If it weren't painful, even the poor devs would do it.
He said that Go was chosen due to its suitability for the workload, offering low-level control, optimized native code, automatic memory management, and concurrency.
And this coming from the same guy that created C#, Typescript, Delphi & Turbo Pascal shows how a real engineer takes a decision of this magnitude.
Is Go the best decision for every SW project? No, but in this case the arguments (and the tests they did during their evaluation) check out.
And no, picking F# simply because you love the language is not a mature decision.
You can check his arguments here:
See the BUILD 2025 talk, where he explains the data structures redesign to fit into Go's lesser type system.
Such a strange thing to write. Mojo doesn't even have classes yet.
It is like praising Go, while ignoring CGO and and the Assembler that come with the toolchain.