Astral clearly are using semantic versioning, as should be obvious if you read the spec you linked.

In fact, one of the examples listed in that spec is 1.0.0-alpha.1.

ETA: It should also be noted that ty is a Rust project, and follows the standards for versioning in that language: https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field

It’s unfortunate that it has come to this, since BCacheFS seems like a promising filesystem, but it is also wholly unsurprising: Kent Overstreet seemingly has an knack for driving away people who try to work with him

Besides this change not breaking user space, the "don't break user space" rule has never meant that the kernel cannot drop support for file systems, devices, or even entire architectures

The issues are listed in Supplementary Table S141 (p. 75 in the SI; 10 issues) and in https://github.com/kobihackenburg/scaling-conversational-AI/blob/main/issue_stances.csv (697 issues)

Thanks! And yeah, with Markdown you need an empty line for it to actually add a paragraph break.

Though I just learned that you can also end a line with two spaces or an \ to get a line-break

Please consider adding paragraph breaks to your posts; a wall of text like this is not pleasant to read

I did enjoy this comment:

C code with a test suite that is run through valgrind is more trustworthy than any Rust app written by some confused n00b who thinks that writing it in Rust was actually a competitive advantage. The C tooling for profiling and checking for memory errors is the best in the business, nothing else like it.

In other words, a small subset of C code is more trustworthy than Rust code written by "some confused n00b". Which I would argue is quite the feather in Rust's cap

IMO, variables being const/immutable by default is just good practice codified in the language and says nothing about Rust being "functional-first":

Most variables are only written once, and then read one or more times, especially so when you remove the need for manually updated loop counters. Because of that, it results in less noisy/more readable code when you only need to mark the subset of variables are going to be updated later, rather than the inverse. Moreover, when variables are immutable by default, you cannot forget to mark them appropriately, unlike when they are mutable by default

A single underscore is just a naming convention, but double underscores triggers automatic name-mangling of the variable in question:

$ cat test.py
class foo:
        def __init__(self, x):
                self.__x = x

f = foo(1)
f.__x
$ python3 test.py
Traceback (most recent call last):
  File "/mnt/d/test.py", line 6, in <module>
    f.__x
AttributeError: 'foo' object has no attribute '__x'

However, much like private/protected variables in java, this is pretty trivial to circumvent if you want.

But I don't believe that you can argue that access modifiers are required for OO not to be shoehorned into a language, not when influential OO languages like Smalltalk didn't have this feature either. Java just happens to be closer to C++, where public/private/protected is much more rigidly enforced than either Java or Python

Linux supports BitLocker encrypted partitions. You just have to specify the BitLocker recovery-key in your fstab file or on the command-line. I've been dual-booting with disk encryption enabled on both Linux and Windows for several years, using that functionality