It's immutable in the sense that the system files are generated by Nix and they're read-only. So, if you want to make a change to your system, you change the Nix files and rebuild the entire system. The old version of the system remains /nix/store and you can rollback to it.

You could also call it "declarative infrastructure", because you declare in your configuration.nix how the system should look like: users, packages, file paths, etc.

> This isn't really immutability? It looks like an infrastructure refresh on deploy.

The title says 'erase' rather than 'refresh', and does acknowledge they're 'mutable systems'.

The HN title also says immutability, so I'm referring to that. "Erase" and "immutability" are contradictory. The author clearly can only mean one.

>I love immutability it makes things ten times easier.

Me too. Mutable State is to Software as Moving Parts are to Hardware :-)

https://medium.com/@kristiandupont/mutable-state-is-to-softw...

The next level after making your variables immutable is to get rid of variables all together. Just function pipes from IO in to IO out.

It's called the point free style.

> I'm just waiting for the day they can make the database immutable. It'll probably look something like git.

Netflix had immutable databases back in 2012. I mean, as close as you can get I suppose. We could lose 1/3 of the nodes and keep running normally, and lose 2/3 and keep reading.

It was built with Cassandra and based on the Dynamo model.

There was also an open source, fully in memory database with the same reliability: https://github.com/Netflix/dynomite

you seem to imply that it is no longer like this? If so, why?

Oh no I'm saying it was like that then when I was there, and I can't speak to how it is now.

I assume it is still that way, because it would be odd otherwise. But I just can't say for certain because I'm not there anymore.

agreed. this is reproducibility, not immutability. When dealing with such things, precision in language is important. I don't understand the downvotes for you.

But, more than anything this is an ad for nixOS.

> I'm just waiting for the day they can make the database immutable.

Wouldn't event stores with CQRS effectively do this?

No. You still need a regular database due to read performance. If I want to read the "latest" data, a search on an event store for a piece of data that wasn't changed in the past year would take an inordinate amount of time.

Additionally what if I want to look up a "row" of data that was modified 5 times on 5 different "columns" at various dates across 3 years? That's an aggregation job across 3 years of event data.

For event sourcing you still need to turn the "event" into an actual operation and record that database operation in a classic database.

Event stores just make the "event" the source of truth. It doesn't get rid of regular databases.

Traditionally other services read a single entity database/service and use that as a source a truth. Now a single button click records data across several databases and several services. It's not necessarily a better architecture, just different/buzz-wordy, and definitely more complicated.

Look up database as a value rich hickey talk on datomic which essentially does this.

Bottleknecks writes through an acid layer, makes reads against any single database connection (the value) immutable.

Querying history(values of attributes in time) is very very slow in datomic. It is meant for auditing/troubleshooting, not to be used for your application domain.

> For event sourcing you still need to turn the "event" into an actual operation and record that database operation in a classic database.

That's where the CQRS architecture comes into play. An event is recorded to the event store, the projection database is updated to the latest point in time, then any further reads are done from the projection database.