4 ms·

I love immutability it makes things ten times easier. This isn't really immutability? It looks like an infrastructure refresh on deploy. If you are refreshing s

I love immutability it makes things ten times easier. This isn't really immutability? It looks like an infrastructure refresh on deploy. If you are refreshing something by definition it's probably not immutable. I guess the author means getting rid of the mutation of state. I'm just waiting for the day they can make the database immutable. It'll probably look something like git.

Nuzzerino 7y ago
> I'm just waiting for the day they can make the database immutable. Wouldn't event stores with CQRS effectively do this?
- crimsonalucard 7y ago
  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.
  - waheoo 7y ago
    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.
    - Scarbutt 7y ago
      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.
  - Nuzzerino 7y ago
    > 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.
- deleted 7y ago
  [deleted]
OJFord 7y ago
> 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'.
- crimsonalucard 7y ago
  The HN title also says immutability, so I'm referring to that. "Erase" and "immutability" are contradictory. The author clearly can only mean one.
elbear 7y ago
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.
jiveturkey 7y ago
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.
jedberg 7y ago
> 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 https://github.com/Netflix/dynomite
- seb314 7y ago
  you seem to imply that it is no longer like this? If so, why?
  - jedberg 7y ago
    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.
kristiandupont 7y ago
>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-software-as-moving-parts-are-to-hardware-dd53303a97cd https://medium.com/@kristiandupont/mutable-state-is-to-softw...
- crimsonalucard 7y ago
  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.

Nuzzerino 7y ago

> I'm just waiting for the day they can make the database immutable. Wouldn't event stores with CQRS effectively do this?

crimsonalucard 7y ago
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.
- waheoo 7y ago
  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.
  - Scarbutt 7y ago
    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.
- Nuzzerino 7y ago
  > 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.
deleted 7y ago
[deleted]

OJFord 7y ago

> 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'.

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

elbear 7y ago

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.

jiveturkey 7y ago

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.

jedberg 7y ago

> 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 https://github.com/Netflix/dynomite

seb314 7y ago
you seem to imply that it is no longer like this? If so, why?
- jedberg 7y ago
  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.

kristiandupont 7y ago

>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-software-as-moving-parts-are-to-hardware-dd53303a97cd https://medium.com/@kristiandupont/mutable-state-is-to-softw...

crimsonalucard 7y ago
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.