Hacker News new | ask | show | jobs
by osigurdson 537 days ago
>> stored at global variables

This is an interesting (and correct) perspective. Global variables scare us in software but we are ok with it when it comes to application state stored in a db.

3 comments

There have been proposals to have global state in programming languages which function like databases with the advantages of monitoring/persistence/naming etc, but also retain the modularity of local state.

https://www.scattered-thoughts.net/writing/local-state-is-ha...

https://awelonblue.wordpress.com/2012/10/21/local-state-is-p...

Global variables can definitely be overused, but in the right situations, they’re generally fine. After all, the filesystem is a big global variable too. So is any database. But people don’t complain too much about that.

The strongest argument against global variables is that they don’t show up in the parameter lists of functions. In that way, they’re sort of “spooky action at a distance”. And they encourage functions to be impure. But if this bothers you, you can always pass your database connection as an explicit parameter to any function which interacts with it.

They aren’t scary. They are useful and you probably use them in many forms (lambdas capturing locals, logging, singletons).

This is yet another reason why single threaded should be the default assumption and multi-threaded require special consideration.