OS in Go? Why Not | Hacker News Reader

OS in Go? Why Not

blog.jetbrains.com

13 points_xivi17 comments

> C has no complex data structures like hashes, trees, or linked lists, and should the programmer require them, they are expected to implement their own. This provides more granular control over the code, as the programmer can tweak the details of the implementation as needed for efficiency.

It's absolutely possible to roll your own data structures, even if the language provides its own implementations. Some use their own hash map instead of std::unordered_map/set in C++, and some use hash maps specialised for primitive types in Java (as the generic HashMap boxes).

(On the contrary: do people roll good implementations of data structures usually?)

> As explained in this Reddit thread, mouse lag is likely because the interrupt handler allocates memory that triggers garbage collection.

The Biscuit paper states "the longest single GC-related pause suffered by NGINX was 115 microseconds"; I'm not sure how well that generalises to other workloads, but (infrequent already) pauses would be hard to notice if that does generalise.

> On the contrary: do people roll good implementations of data structures usually?

In high-level languages, my general observation is that hand-rolled data structures can be divided into two kinds: the kind written by somebody who has no clue what they're doing, and the kind written by a data structures wizard that leaves you in awe about the details.

The most notable example of I've seen of the latter kind was in some read-optimised database where they wrote a cache that linearly scales with the number of readers almost infinitely -- some black magic with maintaining two copies of a map, and having each reader go through completely wait-free paths and switching maps on writes so they never interfere, whilst sharing the underlying storage to not make writes completely inefficient. Stuff like this just makes admire the crazy things that are possible.

Then you have the crappy linked list implementation #82432 that segfaults it you look at it funny.

> The Biscuit paper states "the longest single GC-related pause suffered by NGINX was 115 microseconds"; I'm not sure how well that generalises to other workloads, but (infrequent already) pauses would be hard to notice if that does generalise

> The collector suspends ordinary execution on all cores (a “stop-the-world” pause) twice during a collection: at the beginning to enable the write barrier on all cores and at the end to check that all objects have been marked. These stop-the-world pauses typically last dozens of microseconds

Yeah that certainly seems to be the case, for interactive use, I find it hard to believe that anything less than a few ms will cause issues, and that's 3 orders of magnitude more than what biscuit found.

Although I do wonder if there are GC concerns elsewhere -- these are just vague memories, but I believe that the Go GC is pretty conservative and will not reap anything that looks like a pointer, so there might be concerns around leaks especially with all the special pcie registers, dma buffers, etc that might be lying around in memory.

The Go GC is precise nowadays. But there's also a kind of semi-conservative GC which can identify pointers/not-pointers in the heap, but not the stack; apparently Go 1.0 was fully conservative, 1.1-1.2 were semi-conservative, and 1.3 and on are precise.

I wish HN had some minimum standard for information content in articles. This reads like a high school kid’s report from computer class.

I wish I went to your highschool then!

Yeah I agree, I was expecting an in-depth look at OS implementation in Go, not a high-school level report about mashing keywords together into a vaguely-coherent whole. Got nerd-sniped by the title I guess, there's no real substance in the article.

Feels like it's written by somebody who's never even looked at kernel code before tbh.

Feel free to hit the flag link. For individual user comments, flag means they broke some specific rule. But for articles it's fine to flag them just because they're terrible (as this article definitely is), like a super-downvote.

> Determining which language was used to write any particular operating system can be challenging because every OS is written in a combination of multiple languages.

Don’t want to insult the author, but passages like these really trigger my ChatGPT detectors :) Am I alone?

It's less ChatGPT detectors and more "boring high-school essay you've read too many of" detector, a style that ChatGPT certainly emulates very well when required -- a style of writing is so bland, so generic, and so lacking in any sort of voice and personality that I feel my personality draining away with every word I read. LLMs can do better -- if correctly prompted, they will happily write great essays, but the default mode seems to be this kind of soulless writing.

Maybe I exaggerate about the writing quality, but that's certainly the impression I get. The blog post right before this one is another guest post, and while I don't think this is happening on Jetbrains' blog, it really reminds me of the shady "reputation boost" agencies that charge money to put out press releases and articles with the author's name on it so they get to boast about being "in the media" and such.

It also lacks any sort of depth to the points made, which is very much the style of writing that comes out of both ChatGPT and hastily written high-school essays.

There's two major production-ready Go-based operating system(-ish) projects:

- Google's gVisor[1] (a re-implementation of a significant subset of the Linux syscall ABI for isolation, also mentioned in the article).

- USBArmory's Tamago[2] (a single-threaded bare-metal Go runtime for SOCs).

Both of these are security-focused with a clear trade off: sacrifice some performance for memory safety and excellent readability (and auditability). I feel like that's the sweet spot for low-level Go - projects that need memory safety but would rather trade some performance for simplicity.

gVisor is a very fun project - they're really pushing the boundaries of what's possible in Go. Typical overhead is <10% thanks to a number of new features (systrap[3], directfs, in-process overlay...), all while maintaining a well-documented and super clean code base.

[1]: https://github.com/google/gvisor

[2]: https://github.com/usbarmory/tamago

[3]: https://gvisor.dev/blog/2023/04/28/systrap-release

Webpage is flaky, here's a backup: https://web.archive.org/web/20230517105311/https://blog.jetb...

Yes, you can write an OS in Go. Or Python, or Basic, or any other Turing-complete language for that matter. The language is not the problem, the real problem with creating new OSes is the fact that nobody really needs them, it's a solved problem. At least, for the forseable future until the hardware changes too much.

Spoiler: OS means “Operating System” in this title, not “OpenSearch” as I had initially thought.

This would make a good case for a valuable title change.

I think operating system is much more common of a term than OpenSearch?

I think Go would be much more suitable to OpenSearch rather than to an operating system?

And the title says “OS”, not “an OS”, leading me to think that OS was a proper noun. Is that so crazy?

Anyway, the title is a bit vague, writing “an operating system” would just be better for everybody.

Yes. macOS always trips me up.

Reply on news.ycombinator.com