> The language design contract is unsafe by default
False. The language design safe by default, something that you can confirm super easily doing just the Rust tutorials and compare the same with C or C++.
Read the repo well:
cve-rs implements the following bugs in safe Rust:
Use after free
Buffer overflow
Segmentation fault
NOT REFUTE IT.
> There are unsafe blocks all over the stdlib
Unsafe blocks is not the same that unsafe code. Are marked areas that are required to do escape automated checks, and there, you are at the level of a C/C++ programmer (where in that languages ALL THE CODE IS MARKED UNSAFE).
If you complaint against that, is the same as complaint against ALL THE CODE writer on C/C++.
---
One thing important to understand about Rust: Rust is a system language and SHOULD be able to implement everyting including, Buffer overflow, Use after free , Segmentation fault and such. You should be able to implement a terrible OS, malware, faulty drivers, etc, minimally because that is required to test safe programs!
> people wildly underestimate the os page cache and modern nvme drives
And worse, overestimate how safe is their data!
All this fancy thing about not using a RDBMS could had been true only if the APIs and actual implementation across ALL the IO path were robust and RELIABLE.
But is not!
EVERY LAYER LIES
ALL of them
ALL OF TIME
That is why the biggest reason building a real database (whatever the flavor) is that there is no way to avoid pay performance taxes all over the place because you can't believe the IO and having a (single | some files) getting hammered over and over make this painfully obvious.
One of the most sobering experiences is that you write your IO with all the care in the world, let the (your brand new) DB run for hours, on good, great, hardware, and in less than a week you will find that that breaks in funny ways.
I remember this article for when I was researching for https://spacetimedb.com/. The interactivity is very cool, BTW!
One neat realization is that a database is in fact more about indexes than the actual raw tables (all things interesting work under this assumption), to the point that implementing the engine you get the impression that everything start with "CREATE INDEX" than "CREATE TABLE". This includes sequential scans, where as visualized in your article show that lay the data sequentially is in fact a form of index.
Now, I have the dream of make a engine more into this vision...
I do like this: cron to run the backup and then rsync to https://www.rsync.net, then an after script that check it was run and post to my telegram the analysis.
Another good option is Restic, since snapshots let you go back in time. That is useful in case you accidentally delete/break something and you're not quite fast enough to restore from backup before the next cron runs.
Well, Haskell is a big language with lots of different aspects.
To nicely support TVars, it's good if your language can differentiate between pure code and code with side-effects. Haskell's type system is one way to get there; but eg something like Rust could probably also be coerced to do something appropriate.
Apart from that, you probably don't even need static typing to make it work well enough (though it probably helps). You definitely don't need laziness or Haskell's love of making up new operators or significant whitespace.
Check the dBase/FoxPro family. My nostalgia remember it fondly, and there was not disconnected in how everything worked (example: The forms were stored as tables, so you can do alike `SELECT * FROM form_name WHERE widget=`), and there was zero ORM.
I have an invoice/order taker https://www.bestsellerapp.net, it syncs to many ERPs and allow people to operate everywhere, that I'm upgrading to be a more general mini-ERP.
On the side, retaking https://tablam.org, that I have procrastinated because wanna provide a parser that work for editors (that is way harder than normal batch parsers!)
No, jj is super simple in daily use, in contrast with git that is a constant chore (and any sane person use alias). This include stuff that in git is a total mess of complexity like dealing with rebases. So not judge the tool for this odd case.
As someone else said, jj comes into its own when a reviewer insists you split your PR into many commits, because they don't want to review 13k lines in one chunk. In that case it is easier because there is no rebase. To change a PR commit in the middle of the stack you checkout a PR commit, edit it - and done. The rebase happened automagically.
Notice I didn't say "edit it, commit, and done" because that's another thing you don't do in jj - commit. I know, `git commit` is just a few characters on the cli - but it's one of several git commands you will never have to type again because jj does it without having to be asked.
If the rebase created a merge conflict (it could do so in any PR commit above the one you edited) - it's no biggie because jj happily saves merge commits with conflicts. You just check it out, and edit to remove the conflict.
Jj does grow on you over time. For example, when you start with jj you end up in the same messes you did as a git beginner, when you recovered with 'rm -r repository', followed by 'git clone git@host/repository.git'. Then you discover 'jj op restore' which compared to git's reflog is a breath of fresh air. And while you might at first find yourself chafing at the loss of git staging, you gradually get comfortable with the new way of working - then you discover `jj evolog`, and it's "omg that's far better than staging". Ditto with workspaces vs worktrees, and just about everything else. It might be difficult to lose work with a bad git command, but actually impossible to lose work with a jj command.
It is a steep learning curve. We are talking months to use it fluently instead of treating it as git with better porcelain. If all you ever do is work with one commit at a time, it's a lot of effort for not a lot of return. But as soon as you start managing stacks of changes, duplicating them, splicing them, it makes you feel like a god.
That said, if you are starting out - I'd suggest starting with jj instead of git. You've got to go through a learning curve anyway. You may as well do it with the kinder, gentler, more powerful tool.
Git rebases don't work if there are conflicts, jj doesn't have this problem. Also idk if you can rebase onto multiple parents with git but jj can do it.
JJ can save conflict related state with the change so that you don't need to resolve a conflict in the middle of a stack of changes for rebasing to continue for the remaining changes. Concretely, it uses a "conflict algebra" where it can track the impact of a conflict as it propagates through the stack of rebased changes: https://docs.jj-vcs.dev/latest/technical/conflicts/
You have to fix them at some point, but not in the middle of doing other things. Right now. With no possible way to make progress elsewhere while deferring this decision.
Not really very similar at all for the scenario discussed here. Rerere remembers how you have resolved a conflict before. It doesn't let you rebase a stack of commits that result in different conflicts. You will have to stop and resolve each conflict and then `git rebase --continue`.
Avoiding manual conflict resolution isn't really a good thing though - conflicts are an indication that multiple different changes affect some code and you really should think hard about what the combination of them should be. Even what git does automatically already can be dangerous.
I prefer `git commit --patch` and having a full editor for commit messages rather than a command-line -m argument to encourage me to actually write something useful.
False. The language design safe by default, something that you can confirm super easily doing just the Rust tutorials and compare the same with C or C++.
Read the repo well:
NOT REFUTE IT.> There are unsafe blocks all over the stdlib
Unsafe blocks is not the same that unsafe code. Are marked areas that are required to do escape automated checks, and there, you are at the level of a C/C++ programmer (where in that languages ALL THE CODE IS MARKED UNSAFE).
If you complaint against that, is the same as complaint against ALL THE CODE writer on C/C++.
---
One thing important to understand about Rust: Rust is a system language and SHOULD be able to implement everyting including, Buffer overflow, Use after free , Segmentation fault and such. You should be able to implement a terrible OS, malware, faulty drivers, etc, minimally because that is required to test safe programs!
(example: Deterministic Simulation Testing https://turso.tech/blog/introducing-limbo-a-complete-rewrite...).
But what Rust gives is that not assume that you want to do it for most programs.
reply