Generally I think people that use Linux on their home PCs are more likely to have stuff like multiple screens or loads of gadgets attached to their computer. A lot of Linux users think it’s really cool or like to imagine themselves as someone that does things like lots of complicated data analysis or being an “epic hacker” in their spare time at home. Extra shit on your desk can be genuinely useful if you actually do those kinds of things and add to the aesthetic if you like them.
Automatically enforced deterministic formatting is the best, there’s nothing that beats it. The productivity in just being able to format on save knowing that the code will be in the ideally formatted state, along with the anti-bikeshedding properties of this strategy, makes it unbeatable.
gofumpt and gofmt are the best. One of the reasons if I have a choice I’ll code in go. I heard rumblings that rust was working towards having rustfmt be a standard crate.
Go is in a good position, yeah. JavaScript has prettier, which is nice. Java has google-java-format. Python has ruff, which is quite good. Kotlin has ktfmt, which I believe made a mistake with their standards by not following the standard formatting guidelines for the language, but whatever. Uniform and deterministic for the win.
I had no idea it was standard. I had heard they had issues with it not being able to handle certain constructs so they were working on getting it to a place it would perform better. Has this changed? I’m not a rust person, but I intend to be. I’ve barely made it 1/4th way into the book (just started in the past month and I’ve been busy), but I have a good background in programming and so far it’s been super easy. I’m really enjoying how specific the compiler is, and the binary sizes vs Go.
JSON data within a database is perfectly fine and has completely justified use cases. JSON is just a way to structure data. If it’s bespoke data or something that doesn’t need to be structured in a table, a JSON string can keep all that organized.
We use it for intake questionnaire data. It’s something that needs to be on file for record purposes, but it doesn’t need to be queried aside from simply being loaded with the rest of the record.
Edit: and just to add, even MS SQL/Azure SQL has the ability to both query and even index within a JSON object. Of course Postgres’ JSONB data type is far better suited for that.
While I understand your point, there’s a mistake that I see far too often in the industry. Using Relational DBs where the data model is better suited to other sorts of DBs. For example, JSON documents are better stored in document DBs like mongo. I realize that your use case doesn’t involve querying json - in which it can be simply stored as text. Similar mistakes are made for time series data, key-value data and directory type data.
I’m not particularly angry at such (ab)uses of RDB. But you’ll probably get better results with NoSQL DBs. Even in cases that involve multiple data models, you could combine multiple DB software to achieve the best results. Or even better, there are adaptors for RDBMS that make it behave like different types at the same time. For example, ferretdb makes it behave like mongodb, postgis for geographic db, etc.
Using Relational DBs where the data model is better suited to other sorts of DBs.
This is true if most or all of your data is such. But when you have only a few bits of data here and there, it’s still better to use the RDB.
For example, in a surveillance system (think Blue Iris, Zone Minder, or Shinobi) you want to use an RDB, but you’re going to have to store JSON data from alerts as well as other objects within the frame when alerts come in. Something like this:
While it’s possible to store this in a flat format in a table. The question is why would you want to. Postgres’ JSONB datatype will store the data as efficiently as anything else, while also making it queryable. This gives you the advantage of not having to rework the the table structure if you need to expand the type of data points used in the detection software.
It definitely isn’t a solution for most things, but it’s 100% valid to use.
There’s also the consideration that you just want to store JSON data as it’s generated by whatever source without translating it in any way. Just store the actual data in it’s “raw” form. This allows you to do that also.
Edit: just to add to the example JSON, the other advantage is that it allows a variable number of objects within the array without having to accommodate it in the table. I can’t count how many times I’ve seen tables with “extra1, extra2, extra3, extra4, …” because they knew there would be extra data at some point, but no idea what it would be.
Why does it have to always be a hype that is a literal kick in the eye of gamers? Previously it was shitcoins, now it’s hallucination engines… I’m afraid what’s up next.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.