hocus VS gitfs

I didn't want to go into all the technical details, but we have another write-up that goes into details about RAM management: https://github.com/hocus-dev/hocus/blob/main/rfd/0003-worksp...

Other than making sure we release unused memory to the host, we didn't customize QEMU that much. Although we do have a cool layered storage solution - basically a faster alternative to QCOW2 that's also VMM independent. It's called overlaybd, and was created and implemented in Alibaba. That will probably be another blog post. https://github.com/containerd/overlaybd

If you’d rather use a self-hosted alternative, we are building Hocus [0]. It’s still in alpha, but already supports prebuilds, VSCode, shared environment variables, and more.

[0] https://github.com/hocus-dev/hocus

[https://github.com/hocus-dev/hocus

Check out our product launch post on Reddit here and the 0.2 release on GitHub here.

(Opinions are my own)

At my employer we use a subset of C++ and we use Go. We have a process by which when you write code others have to review it and you need to have a review by someone who is an "expert" [0] in the language [1]. You become an "expert" by being ordained by a shadowy committee who reviews code you submit to the code repository. They look for knowledge of the core language, how this language is used within the company, the external and internal libraries, performance, testing, etc. There are many factors and if you demonstrate all of them you get marked as being this type of "expert."

Before I joined this company I had written code which was launched into production in the following languages: Java, PHP, C, C++, assembly (arm + x86), Python, JavaScript (browser + node), and a few more. I would consider myself about average in all of these. I did not write any golang.

After I joined my current job I obtained this "expert" bit for both C++ and Go. It took ~1.5 years to get the C++. It took ~3-5 months for Go.

You can actually see the first golang code I wrote (this was at home when I was experimenting with the language before convincing some team members we should rewrite some of our infra in go): https://github.com/gravypod/gitfs

It has all sorts of mistakes but I didn't read any guides. I just used https://cs.opensource.google to search for examples of things that I thought I would need to do (ex: "how do I do a switch statement").

For C++ I had worked on ~2 projects that used it. My first few PRs were very rough and I had a lot of performance issues that crept into my code. If I didn't already have a lot of C experience I would have also had a bunch of pointer/lifetime stuff the reviewers would have found (I know this from reviewing new team members first lines of C or C++).

I know that to some C++ represents a literal worst case but most people coming from C++ to Go will think it's amazing because it removes all of the common footguns.

> Things like awkward error handling

Yes, it is very clunky and annoying but it's very simple. It's just a normal if statement and doesn't use any special language rules. I think this would still be better if there was dedicated syntax for it (something like throw/try/catch which works the same way but gives it a different syntax) but honestly I don't think it's as bad as it's made out to be. It's basically a "less bad" errno and that worked go-... dece-... ehm fine for many years.

> dealing with null

I've never really had to think about this too much. There are some times it is important but I rarely return nullable things without errors and it hasn't bitten me yet. My code is not provably correct but for the things I'm working on I don't need that guarantee. If I did I'd probably switch to Rust or something with better type safety.

> capitalization for public/private

Yea, this sucks but it doesn't really get in my way much. I don't like it but it isn't actively hurting my usage.

> magic functions

Like `String()`? I don't know if that's the worst think in the world. Python, C++, and Java have things like this.

> and imports

It's not been too bad for me. What I think is unfortunate is that the package of something is unconnected to where it is in most go usages which is annoying but it makes things more terse. This does actually hamper my productivity.

> I don't think it's good or easy to use at all, but people rave about it.

It's pretty easy to use because all of the libraries I've seen share common interfaces for behavior. This makes things feel a lot more cohesive. fuse-go and billy was very easy to use in gitfs because of this.

[0] - This is not an expert as in "knows everything" but more like "has been seen to consistently write efficient, simple to understand, idiomatic code." It basically means that when someone else from this subset of SWEs reviews your code they often do not have many comments. Again, I want to stress, this is not expert as in "knows everything" just as in "good enough".

[1] - https://abseil.io/resources/swe-book/html/ch03.html#what_is_...

Did you open source yours? I started something like this here: https://github.com/gravypod/gitfs

Are you planning on using any fancy tricks to optimize large repos? I have open sourced some code I was playing with for fun here which allows you to mount a git repo as a read only FUSE file system: https://github.com/gravypod/gitfs

You can really lower IOPS/memory/disk usage with an approach like this.