Fossil is extremely frustrating to me. There are so many parts that I'm drawn to, but then are there showstoppers that prevent real adoption (by me). I've used it in earnest a number of times. Their immutability stance is at the root of the problems. Lack of rebase is most infamous, but you can't even edit a ticket description! Make a typo or error in the description, and you're expected to append more notes, or delete and recreate the ticket.
I really love the idea of a powerful, shrink-wrapped scm + ticketing etc. system, and I'm a sqlite fan, but fossil hasn't worked out for me.
IMHO the best and most relevant part of fossil these days is the ticket system, which is in every single way almost completely ideal for coding agents. Some features are: single-binary, in-repo, CLI or web UI, and offline / sql / markdown-friendly.
Since the whole tracker is just a thin front on sqlite with the above features there's many options. Use it per-project persistently so as to include co-workers, or only locally for your own agents to "think" inside of so they are less likely to dump CoT all over the code-comments. Use it even at a per task granularity, and throw it away afterwards. Do all three, fossil doesn't care! And the agents will love it.
Though I just vented in another comment about fossil, I'll admit that all of my experience was in the pre-agentic era. Since an agent won't be as easily annoyed (heck, it happily belts out sqlite's tedious schema alternation dance without pause), I'm curious to try pointing it fossil as the scm for a project.
I honestly think the article misinterpreted the Git mailing list email.
The first line of the article says:
"People at Git has started to work on a proposal to make the Rust programming language mandatory."
This sounded to me like all future code would need to be Rust.
But the Git mailing list email says:
"Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure."
Also, the original Git mailing list email says:
"[author is porting to Rust the...] "varint.c" subsystem, mostly because it is trivial and does not have any dependencies."
So, the email on the Git list says they are testing changing a small piece
of C code to Rust, and Rust build tools will be mandatory [to build] (which is not surprising if a non-optional part of the code base is Rust).
This is by far the most perplexing part of this article for me:
> People at Git has started to work on a proposal to make the Rust programming language mandatory. I don't like Rust and, above all, I don't like its community of little extremist characters who are trying to make everyone swallow their crap by rewriting projects that have been working for decades, doing social media brigading, and other nice little gems worthy of any tiny group with totalitarian delusions. That's why when I see that a project aims to "force" the use of or the switch from C to Rust, to the extent of my possibilities, I flee from it as if I were pursued by the Balrog of the Lord of the Rings with his whip.
I've been programming for a longish time, and I've acquired my own set of opinions about programming languages, but I can't think of any that I dislike so strongly that I would need to boycott projects that use them under the hood. Moreover, even if we accept the "community of little extremist characters" claim for the sake of argument, is that at all relevant to the Git situation? I haven't seen any evidence that introducing Rust into the code base is the result of extremism, rather than just a mundane technology choice. Finally, when Rust is made "mandatory," it does not mean you must use Rust now, it just means that Rust is required to build the source code. The vast majority of people wouldn't even know that Rust was used. Even most Git developers wouldn't need to use Rust, since after more than a year from the original proposal, the Git source tree is still almost entirely written in C and shell scripts, and the amount of Rust code is basically a rounding error.
The whole Rust issue seems like a big nothingburger, and this reaction seems completely irrational to me.
rust solves a real problem. It makes it much harder to create a large class of bugs, bugs that are in most C and C++ projects (and many other languages). Sure, maybe rusteans have bad attitudes. Not sure that's true but I do get the annoyance of "I re-wrote cat in rust!".
We see these C/C++ bugs all over. Mozilla just fixed a ton of them, most of which would not have existed if Firefox was written in rust (see servo). That doesn't mean there would be zero bugs. It means there would be less. But by some accounts, a ton less, especially of the security issue kind.
And it's not just about the op, the op being a perfect expert programmer who never writes bugs. It's about someone quits, someone who doesn't know the code as well and takes over, they quit, someone who knows the code even less takes over, and in that world, the person adding a new feature to the app/tool/library is far less likely to add a security bug to a rust repo than an C/C++ repo.
> rewriting projects that have been working for decades
They have been working for decades AND are full of security bugs!
Switching them to rust generally means (1) the existing security bugs are gone (2) most future updates are far less likely to add new ones.
Note: I'm not a rust programmer. I'm a C++ programmer dealing with the fact that there are so many UaF bugs in our code with > 1000 programmers. We know more will be added because C++ does not prevent them and we're not perfect. Rust does, or at least it prevents enough of them to be worth it.
The friction is not an issue of the language or of toxic communities but the culture of how software is crafted and passed on. I use rust for hobby projects and besides the savety and soundness decisions, i love the tooling. Having countless [0] very restrictive guard rails like deny(clippy::float_arithmetic) for your usecases codifies intent about project structure in a way i have seen nowhere else. Not engaging with the benefits of rust but instead blanket-dismiss projects based on unrelated issues is irrational and i suspect its a phenomenon of older generations that grew up with C and never inherited eg. cobol on mainframes.
I believe there have been a number of crusades started around people's behavior and usually get a code of conduct book thrown at them. I remember a notable Python dev who had this happen to him, over sharing some humor from an old SNL skit related to a poorly chosen acronym for some tech, an otherwise extremely helpful and resourceful person got hammered and drumed out of the community. The rust community may have that same tone policing vibe. I enjoy and appreciate the value of using rust, and nix, both have this vibe at times and I make sure I "don't cross the streams" it sure has a stifling effect.
Your arguments make sense but I also understand how the OP may have such allergic reaction. I also have seen my share of young devs claiming this new thing is the best thing since sliced bread and that everyone shoud use it. This may be a new language or a new feature like objects. After many slices of bread you may develop an allergy to such fanatics, and react with an opposing force to their eagerness to conquer the world.
Allergy is a poor analogy here, since it develops by not exposing yourself. I can understand your annoyance, i got bitten by hypes aswell, including rust. I am not regretting it so far.
.. and even then there are other solutions like "GoT" - https://gameoftrees.org/ - which is interoperable with Git but written in that lovely OpenBSD C.
I agree that the rust community tends to be pretty toxic, but I don't think that is a good reason to avoid tools just because they use rust under the hood. You don't have to participate in the git dev community, let alone the rust community, to use git as your VCS.
> If you are among the unfortunate ones who have their master branch named as "main" this option is not for you and you should check Fossil's documentation if you want to rename it.
I love Fossil and I use it for my projects. I understand why it isn't for everyone, but considering I am the sole developer on the stuff I make (and I agree with Dr. Hipp about the drawbacks of rebase), it's perfect for my needs. Lightweight, has its own integrated web server and forge features should I need them, and it's dead easy to use. It isn't the one VCS to rule them all (no such thing exists, really), but I do encourage people to check it out because they might fall in love like I did.
I really love the idea of a powerful, shrink-wrapped scm + ticketing etc. system, and I'm a sqlite fan, but fossil hasn't worked out for me.
Since the whole tracker is just a thin front on sqlite with the above features there's many options. Use it per-project persistently so as to include co-workers, or only locally for your own agents to "think" inside of so they are less likely to dump CoT all over the code-comments. Use it even at a per task granularity, and throw it away afterwards. Do all three, fossil doesn't care! And the agents will love it.
The first line of the article says:
"People at Git has started to work on a proposal to make the Rust programming language mandatory."
This sounded to me like all future code would need to be Rust.
But the Git mailing list email says:
"Announce that Git 3.0 will make Rust a mandatory part of our build infrastructure."
Also, the original Git mailing list email says:
"[author is porting to Rust the...] "varint.c" subsystem, mostly because it is trivial and does not have any dependencies."
So, the email on the Git list says they are testing changing a small piece of C code to Rust, and Rust build tools will be mandatory [to build] (which is not surprising if a non-optional part of the code base is Rust).
This is by far the most perplexing part of this article for me:
> People at Git has started to work on a proposal to make the Rust programming language mandatory. I don't like Rust and, above all, I don't like its community of little extremist characters who are trying to make everyone swallow their crap by rewriting projects that have been working for decades, doing social media brigading, and other nice little gems worthy of any tiny group with totalitarian delusions. That's why when I see that a project aims to "force" the use of or the switch from C to Rust, to the extent of my possibilities, I flee from it as if I were pursued by the Balrog of the Lord of the Rings with his whip.
I've been programming for a longish time, and I've acquired my own set of opinions about programming languages, but I can't think of any that I dislike so strongly that I would need to boycott projects that use them under the hood. Moreover, even if we accept the "community of little extremist characters" claim for the sake of argument, is that at all relevant to the Git situation? I haven't seen any evidence that introducing Rust into the code base is the result of extremism, rather than just a mundane technology choice. Finally, when Rust is made "mandatory," it does not mean you must use Rust now, it just means that Rust is required to build the source code. The vast majority of people wouldn't even know that Rust was used. Even most Git developers wouldn't need to use Rust, since after more than a year from the original proposal, the Git source tree is still almost entirely written in C and shell scripts, and the amount of Rust code is basically a rounding error.
The whole Rust issue seems like a big nothingburger, and this reaction seems completely irrational to me.
rust solves a real problem. It makes it much harder to create a large class of bugs, bugs that are in most C and C++ projects (and many other languages). Sure, maybe rusteans have bad attitudes. Not sure that's true but I do get the annoyance of "I re-wrote cat in rust!".
We see these C/C++ bugs all over. Mozilla just fixed a ton of them, most of which would not have existed if Firefox was written in rust (see servo). That doesn't mean there would be zero bugs. It means there would be less. But by some accounts, a ton less, especially of the security issue kind.
And it's not just about the op, the op being a perfect expert programmer who never writes bugs. It's about someone quits, someone who doesn't know the code as well and takes over, they quit, someone who knows the code even less takes over, and in that world, the person adding a new feature to the app/tool/library is far less likely to add a security bug to a rust repo than an C/C++ repo.
> rewriting projects that have been working for decades
They have been working for decades AND are full of security bugs!
Switching them to rust generally means (1) the existing security bugs are gone (2) most future updates are far less likely to add new ones.
Note: I'm not a rust programmer. I'm a C++ programmer dealing with the fact that there are so many UaF bugs in our code with > 1000 programmers. We know more will be added because C++ does not prevent them and we're not perfect. Rust does, or at least it prevents enough of them to be worth it.
The friction is not an issue of the language or of toxic communities but the culture of how software is crafted and passed on. I use rust for hobby projects and besides the savety and soundness decisions, i love the tooling. Having countless [0] very restrictive guard rails like deny(clippy::float_arithmetic) for your usecases codifies intent about project structure in a way i have seen nowhere else. Not engaging with the benefits of rust but instead blanket-dismiss projects based on unrelated issues is irrational and i suspect its a phenomenon of older generations that grew up with C and never inherited eg. cobol on mainframes.
https://github.com/rust-lang/rust-clippy
oh great, another weirdo