Moving to git is nice but I don't understand why they don't self-host a gitlab instance.

I am always doubtful when people say that accessing information inside git is hard. I totally agree that defaults in git can be improved (and they are, git restore and git switch are a much better alternative to git checkout that I no longer use). So let’s review the section “A Few Reasons Why SQLite Does Not Use Git”:

“Git does not provide good situational awareness”

git log --graph --oneline --author-date-order --since=1week

Make it an alias if you use it often. Alias is what helps you create your own good default (until everyone uses the same alias and in that case it should be part of the base set of commands).

“Git makes it difficult to find successors (descendants) of a check-in”

git log --graph --oneline --all --ancestry-path ${commit}~..

Likewise you could consider making it an alias if you use it often. Aliases can also be used as a post-it to help you remember what are the command that you find useful but you only use once in a blue moon!

The mental model for Git is needlessly complex

I may agree about that one. For reference, this is what the article says:

A user of Git needs to keep all of the following in mind: The working directory The "index" or staging area The local head The local copy of the remote head The actual remote head

If git fetch was run automatically every so often, as well as git push (of course in a personal branch), then this model could be simplified as

• the working directory
• the “index” or staging area (I actually think that being able to have more than one for drafting multiples commit at once, like a fix and a feature at the same time would be better than only having a single index)
• your working copy of the shared branch
• the shared branch

And integrating your changes (merging/rebasing) should probably be exclusively done using a PR-like mechanism.

Git does not track historical branch names

I’m skeptical about the usefulness of this. But since git was my first real vcs (10 years ago), it may just be that I have not used a workflow that took advantaged of persistant branches. I assume that git annotate could be a solution here.

Git requires more administrative support

most developers use a third-party service such as GitHub or GitLab, and thus introduce additional dependencies.

That’s absolutely true but I’m not sure it’s a real issue. Given how many strategies there are for CI/CD (and none is the definitive winner yet) I do think that being able to select the right option for you/your team/your org is probably a good idea.

Git provides a poor user experience

https://xkcd.com/1597/

I highly disagree about that xkcd comics. Git is compatible will all workflows so you have to use a subset of all the commands. Of course you will have more commands that you never use if a software is usable for all the workflow that you don’t use. But you need about 15 commands to do stuff, 30 to be fluent, and some more to be able to help anyone. Compared to any other complex software that I use I really don’t think that it’s an unreasonably high count. That being said I totally agree that git from 10+ years ago was more complex and we should correctly teach what is needed to junior. HTML/css/js is a nightmare of complexity but it doesn’t stop 15 years old kid with no mentoring to build cool stuff because you don’t need to know everything to be able to do most of the things you may think of, just a good minimal set of tools. And people should definitively take the time to learn git, and stop using outdated guide. Anything that don’t use git switch, git restore and git rebase --interactive and presents you have to inspect the history in length (git log --graph or any graphical interface that show the history in a graph, git show, and more generally than you can filter the history in any way you want, being by author, date, folder, file type, …) is definitively not a good guide.

To sum-up, I think that from this presentation fossil seems more opinionated than git which means that it will be simpler as long as your workflow exactly matches the expected workflow whereas using git requires to curate its list of commands to select only the one useful for yours.

Read your own code that you wrote a month ago. For every wtf moment, try to rewrite it in a clearer way. With time you will internalize what is or is not a good idea. Usually this means naming your constants, moving code inside function to have a friendly name that explain what this code does, or moving code out of a function because the abstraction you choose was not a good one. Since you have 10 years of experience it's highly possible that you already do that, so just continue :)

If you are motivated I would advice to take a look to Rust. The goal is not really to be able to use it (even if it's nice to be able able to write fast code to speed up your python), but the Rust compiler is like a very exigeant teacher that will not forgive any mistakes while explaining why it's not a good idea to do that and what you should do instead. The quality of the errors are crutial, this is what will help you to undertand and improve over time. So consider Rust as an exercice to become a better python programmer. So whatever you try to do in Rust, try to understand how it applies to python. There are many tutorials online. The official book is a good start. And in general learning new languages with a very different paradigm is the best way to improve since it will help you to see stuff from a new angle.

As a rough estimation, if you include everything (apperance, discussion, functionality, interaction with other controls, …) I would say that every single input field or button is about a day of work. And then you start to realise how many buttons there is in any GUI and how much it will cost.

Nice to see continuous progress in Rust for Linux, especialy since it's seems efforts to stabilise Rust features so that RLA doesn't depend anymore on nightly seems to be fructiful.

I'm looking forward for when a big driver (like ashahi or the Nvdia one) are merged in master. It's going to be a big milestone.

Indeed, it's very good. I wish he had send this before 2 Rust maintainers resigned, but I assume that he did not want to undercut Linus decisions.

Syntax has never really be an issue. The closest thing to plain english programming are legal documents and contracts. As you can see they are horrible to understand but that the only way to correctly specify exactly what you want. And code is much better at it. Another datapoint are visual languages like lego mindstorm or LabView. It's quite easy to do basic things, but it doesn't scale at all.

That's well written. I think that requiered 2+ code review could also help because with time more people will gain knowledge of the dark parts of the codebase, just by reviewing the PR of “Martin” when he work on them.

I would have liked a link to the LKLM thread. Usually they are quite informative

It was when I read the git parable.

I never understood why python won agaist ruby. I find ruby an even better executable pseudo code language than python.

It's also what I understood from what I read but I assume it was just a poor choice of word. Debug symbols are way too important for debugging to be stripped by default.

You shouldn't, it's short and interesting

That was a fantastic read. I'm both impressed by the stellar performance of C, and the stellar safety of Rust while keeping nealy best in class performances.

Thank you! I didn’t realized that I was using my lemmy account and not my mastodon account.

As far as I know, adding the support for restrict didn’t trigger any bugs in GCC

That's very impressive for gcc. IIRC adding restrict to LLVM triiggered major bugs and miscompilations at least for the first two attempts. As they said they need to do a crater run to be sure, but even passing the initial smoke test is an achievement for gcc.

However, I'm surprised the code is “only” 3% faster using restric annotation. IIRC the speed-ups were about 5% for LLVM so maybe there is still some performance to gain on the gcc side?

If you try to learn git one command at a time on the fly, git is HARD. If you take the time to understand its internal data structure it's much, much easier to learn. Unfortunalely most people try to do the former because it works well (or better) for most tasks.

I can't recommand enough the git parable.

Good advice, clear, simple and to the point.

Stated otherwise: "whenever you need to add comments to an expression, try to use named intermediate variables, method or free function".

I did not saw Elevate Your Rust Code: The Art of Separating Actions and Calculations in my feed before. It was a good read

And you should not forget that Emacs is way harder when you are 4 because your hands are smaller!