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.
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.
> Not sure if "Python 4.0" is the best comparison.
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.
Hardly, given that it isn't as expressive as Python, that role belongs to Mojo.
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.
Go's structural typing allows for quite a lot of flexibility often otherwise only found in scripting languages (I would suspect that this was the single biggest reason as to why the TypeScript folks started to move to Go for the ported compiler rather than something like dotnet based like C#).
There is an interview with the architect and he explained that Go language maps quite nicely onto the Typescript language (e.g. garbage collector). And of course a lot faster due to concurrency and native binary. 6 times increase iirc.
After hearing the explanation about why he picked Go for the Typescript compiler I can only be more of a fan of Anders Hejlsber.
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.
Mono AOT has existed for quite a while, .NET Native also existed, and it isn't .NET fault if people cannot know about Native AOT.
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.
All I know is that, as a user, whenever I encounter a .net project I have to put in more effort to run it versus a golang project.
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.
I don't know what you're hoping to hear, but I have no idea. All I know is that with loads of Go projects I've used I can go to the releases page, download a binary and run it.
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.
The point is that when you happen to compile yourself Go projects, and CGO is used, you better have the C or C++ compiler toolchain installed that is compatible with Go, with the related dependencies they rely on, otherwise the build will break.
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).
> The point is that when you happen to compile yourself...
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.
I compile and distribute a Go app using CGO targeted at non-programmers. I hand them a single EXE file and they run it. They don't need to install anything else. It's so easy.
> The Doom process manager (PSDoom) is a modification of the game Doom that displays representations of the processes running on a machine. Rather than using standard text-mode UNIX tools to view and manipulate processes, one surveys and shoots at a room full of bloodthirsty mutants, as shown in Figure 1.
> Less than a week after the initial version of the code was written, the project’s website was attracting tens of thousands of visitors per day. Approximately 800 responses were e-mailed to the author or www.slashdot.org within the first two months. Of these responses 27% praised the project, 23% offered suggestions for improving PSDoom, 10% found the project funny, 10% reported technical problems, 8% related PSDoom to science fiction or to the future of interfaces, 1% disliked the project, and 0.6% were frightened by its implications.
I remember when this was announced. It had another humorous side effect - in Doom monsters can kill other monsters, which meant the PSDoom could result in processes randomly killing one another.
Services could have "location" data attached in their metadata and orchestrator could actually place them on the map. They could have some "personality" traits as well and e.g. to kill a service you could walk up to it and do the deed.
I'm amazed at how prolific he is. I've interacted with him a couple of times, and he's always super polite and helpful. In spite of the fact that he is also churning through issues/code on a number of projects.
Nah, I suspect it's just because it's a machine translated port of the original C to Go
> The original C code was converted to Go using (modernc.org/ccgo/v4), by cznic (https://gitlab.com/cznic/doomgeneric.git). This was then manually cleaned up to remove a lot of manual pointer manipulation, and make things more Go-ish, whilst still maintaining compatibility with the original Doom, and its overall structure.
Yes, that's exactly correct. I had intended to break it apart back to the original Doom source layout, but I haven't completed that yet. I'm not 100% sure if that's a good idea anyway.
Ah yes, I did repost it. The previous time didn't get much traction, and I thought enough time had passed that a repost wouldn't be problematic. Apologies if I was mistaken.
Tragically, it will not. Most 'modern' Doom wads use features that weren't present in the original release (ie: they need GZDoom, Boom, or one of the other modern engines). This is a port of the original release, so it's missing those kinds of features.
The idea for this wasn't really to make a new fully featured engine for modern wads, it was more for sneaking the Doom engine in to unrelated projects, easter-egg style. I've run this on various embedded systems that I use Go with. One of the demos is a webserver that uses mjpeg streaming for example.
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.
I feel that it's hard to be mad at Go if you look at it as "python 4.0."
Not sure if "Python 4.0" is the best comparison.
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.
> Not sure if "Python 4.0" is the best comparison.
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.
Hardly, given that it isn't as expressive as Python, that role belongs to Mojo.
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.
Go's structural typing allows for quite a lot of flexibility often otherwise only found in scripting languages (I would suspect that this was the single biggest reason as to why the TypeScript folks started to move to Go for the ported compiler rather than something like dotnet based like C#).
There is an interview with the architect and he explained that Go language maps quite nicely onto the Typescript language (e.g. garbage collector). And of course a lot faster due to concurrency and native binary. 6 times increase iirc.
Indeed, and then at BUILD he ended up describing how they needed anyway to redo all data structures due to differences on the type system.
Go's strucutural typing already existed in languages of the ML linage, nothing new.
F# can do that just fine, if the team actually cared about using .NET.
After hearing the explanation about why he picked Go for the Typescript compiler I can only be more of a fan of Anders Hejlsber.
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:
https://www.youtube.com/watch?v=pNlq-EVld70
I know, you are telling the fisher how to fish.
See the BUILD 2025 talk, where he explains the data structures redesign to fit into Go's lesser type system.
.net is also a pain to distribute since it typically isn't packaged as a single static binary and requires a separately installed runtime
Mono AOT has existed for quite a while, .NET Native also existed, and it isn't .NET fault if people cannot know about Native AOT.
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.
All I know is that, as a user, whenever I encounter a .net project I have to put in more effort to run it versus a golang project.
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.
I bet those Go projects did not used CGO, and if they did would you blame the users or Go?
I don't know what you're hoping to hear, but I have no idea. All I know is that with loads of Go projects I've used I can go to the releases page, download a binary and run it.
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.
The point is that when you happen to compile yourself Go projects, and CGO is used, you better have the C or C++ compiler toolchain installed that is compatible with Go, with the related dependencies they rely on, otherwise the build will break.
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).
> The point is that when you happen to compile yourself...
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.
I compile and distribute a Go app using CGO targeted at non-programmers. I hand them a single EXE file and they run it. They don't need to install anything else. It's so easy.
Great news, .NET Native AOT is exactly the same.
> Hardly, given that it isn't as expressive as Python, that role belongs to Mojo.
Such a strange thing to write. Mojo doesn't even have classes yet.
Mojo also supports Python of its tooling.
It is like praising Go, while ignoring CGO and and the Assembler that come with the toolchain.
I'd love to `kubectl run doom` and kill monsters when I'm supposed to be working
What about Minecraft as a k8s admin tool?
https://github.com/erjadi/kubecraftadmin
Why not both? https://github.com/storax/kubedoom
There is also prior art, PSDoom:
> The Doom process manager (PSDoom) is a modification of the game Doom that displays representations of the processes running on a machine. Rather than using standard text-mode UNIX tools to view and manipulate processes, one surveys and shoots at a room full of bloodthirsty mutants, as shown in Figure 1.
> Less than a week after the initial version of the code was written, the project’s website was attracting tens of thousands of visitors per day. Approximately 800 responses were e-mailed to the author or www.slashdot.org within the first two months. Of these responses 27% praised the project, 23% offered suggestions for improving PSDoom, 10% found the project funny, 10% reported technical problems, 8% related PSDoom to science fiction or to the future of interfaces, 1% disliked the project, and 0.6% were frightened by its implications.
"Doom as an Interface for Process Management" (2002), https://www.researchgate.net/publication/2522409_Doom_as_an_...
I remember when this was announced. It had another humorous side effect - in Doom monsters can kill other monsters, which meant the PSDoom could result in processes randomly killing one another.
Services could have "location" data attached in their metadata and orchestrator could actually place them on the map. They could have some "personality" traits as well and e.g. to kill a service you could walk up to it and do the deed.
What an inspired name :)
I love how ebitengine's author jumped in and helped out with optimizations: https://github.com/AndreRenaud/gore/pull/48
I'm amazed at how prolific he is. I've interacted with him a couple of times, and he's always super polite and helpful. In spite of the fact that he is also churning through issues/code on a number of projects.
Just curios, why everything is in a single large file (doom.go ~46K LOC)? Is it because of how Go handle modules?
Nah, I suspect it's just because it's a machine translated port of the original C to Go
> The original C code was converted to Go using (modernc.org/ccgo/v4), by cznic (https://gitlab.com/cznic/doomgeneric.git). This was then manually cleaned up to remove a lot of manual pointer manipulation, and make things more Go-ish, whilst still maintaining compatibility with the original Doom, and its overall structure.
Yes, that's exactly correct. I had intended to break it apart back to the original Doom source layout, but I haven't completed that yet. I'm not 100% sure if that's a good idea anyway.
Ah, I see, thanks!
I must say I'm really surprised it's so small too, for a reasonably complicated game
Say, what gui/graphics/game-ish libraries are available for Go?
The ebitengine that this project mentions?
Yes.
Ok, if that answer is too short: there are some others (https://github.com/avelino/awesome-go?tab=readme-ov-file#gam...), but ebitengine is by far the most popular...
If I recall the exact same topic has been posted a month back; checked - the exact same text - word by word.
Ah yes, I did repost it. The previous time didn't get much traction, and I thought enough time had passed that a repost wouldn't be problematic. Apologies if I was mistaken.
Will it run myhouse.wad?
Tragically, it will not. Most 'modern' Doom wads use features that weren't present in the original release (ie: they need GZDoom, Boom, or one of the other modern engines). This is a port of the original release, so it's missing those kinds of features.
The idea for this wasn't really to make a new fully featured engine for modern wads, it was more for sneaking the Doom engine in to unrelated projects, easter-egg style. I've run this on various embedded systems that I use Go with. One of the demos is a webserver that uses mjpeg streaming for example.