As someone who has written a fair bit of Go code, I also find myself keeping a close eye on Rust. The things that really appeal to me are the possibility of immutable (by default) types, thread-local memory (ie. owned pointers), no null pointers, and generics. These are all basically aspects of the type system that make concurrent programming safer and more predictable.

There's a bug in your Go code. Change the buffer to be 1 byte in length to illustrate the problem.

why hello there -> WHY HELLO THERE

You need to check that the buffer is on a word boundary or not. If not (i.e. we're in the middle of a word, spanning two buffers), then you'd have to scan until you find a new word boundary before title-casing again.

Previously, we'd used a cron job that ran every hour by running a find on files and then separately on folders, and running chgrp across the whole lot, ensuring to set the setgid attribute on folders... it was pretty heavy handed and didn't offer us the flexibility we needed for subfolder configuration.

This daemon has the benefit that it uses inotify to catch file changes and is much lighter on the system.

Also, with regards to Go specifically, I found development to be relatively straightforward with a couple of exceptions.

One being that while the package os provides chwon and chgrp methods, it doesn't provide the ability to read the user or group attributes of files — this has to be done via a syscall which wasn't at all obvious to me. And that while the package os/users provides the ability to translate system users to ids, there's no group parallel — and so I had to resort to calling out the C function equivalents. Would love to find more idiomatic ways to do this.

Also, whilst I know this will probably never happen, it would be wonderful to have the ability to mark certain variables or data structures as immutable, and pass them between goroutines confident that they're set in stone.

Running one or more microservices and calling out to them from Ruby seems a perfectly sensible way to decouple and scale out an application. And I think go is definitely well suited for this (and definitely not rust right now). But compiling and executing a local binary on each request is a terrible idea.

We believe that modern DBMS systems (like Postgres) are very capable and there's no need for applications to reproduce functionalty that's already there. [...] We think that using a database for "object persistence" is a fundamentally flawed concept that ought to be avoided.

I wonder if one of the devs of this could explain what this means, from a practical standpoint? How does interacting with the database work with this model versus and ORM?