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

Like, one of the issues that Linus yelled at Kent about was that bcachefs would fail on big endian machines. You could spend your limited time and energy setting up an emulator of the powerPC architecture, or you could buy it at pretty absurd prices — I checked ebay, and it was $2000 for 8 GB of ram…

It’s not that BCacheFS would fail on big endian machines, it’s that it would fail to even compile, and therefore impacted everyone who had it enabled in their build. And you don’t need actual big endian hardware to compile something for that arch: Just now it took me a few minutes to figure what tools to install for cross-compilation, download the latest kernel, and compile it for a big endian arch with BCacheFS enabled. Surely a more talented developer than I could easily do the same, and save everyone else the trouble of broken builds.

ETA: And as pointed out in the email thread, Overstreet had bypassed the linux-next mailing list, which would have allowed other people to test his code before it got pulled into the mainline tree. So he had multiple options that did not necessitate the purchase of expensive hardware

One option is to drop standards. The Asahi developers were allowed to just merge code without being subjected to the scrutiny that Overstreet has been subjected to. This was in part due to having stuff in rust, and under the rust subsystem — they had a lot more control over the parts of Linux they could merge too. The other was being specific to macbooks. No point testing the mac book-specific patches on non-mac CPU’s.

It does not sound to me like standards were dropped for Asahi, nor that their use of Rust had any influence on the standards that were applied to them. It is simply as you said: What’s the point of testing code on architectures that it explicitly does not and cannot support? As long as changes that touches generic code are tested, then there is no problem, but that is probably the minority of changes introduced by the Asahi developers

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

In what way does OOP feel shoehorned in with Python? I ask since that is not my own impression of the language.

Would you also be willing to share what language(s) you feel do(es) OOP without it being shoehorned in?

While there are legitimate grievances in this lawsuit, they do also complain that Valve doesn’t let developers generate as many Steam keys as they want, and then sell them on other stores at lower prices than on Steam (see p. 35, “Valve Distorts Competition Through The Steam Key Price Parity Provision”).

Keeping in mind that Valve lets developers generate keys for their games for free, this amounts to Wolfire complaining that they cannot offload the costs of hosting/services to Valve, while at the same time minimizing how much Valve earns. And that just sounds ridiculously entitled to me.

If Wolfire somehow were to win the right to undercut Valve in this manner, then I would not be surprised if Valve responded by charging developers for keys, or otherwise limited the ability of developers to generate keys. Which would have wide reaching consequences for PC gaming

Unix shell scripts are one of the few holdouts.

I don’t know if this applies to other shells, but bash will not only execute your script line-by-line, it will also read it line-by-line. Which means that you can modify the behavior of a running script by editing lines that have not yet been executed*. It’s absolutely bonkers, and I’m sure that it has caused more than one system failure, during upgrades.

* For example, if you run the following script

echo "hello"
sleep 5
echo "goodbye"

and then edit the third line before the 5 second sleep has elapsed, then the modified line will be executed.

It is normal usage. Though personally I’d probably make another “main” function, to avoid declaring a bunch of global variables

But if those beginners want to stop being beginners, then they must learn the basics of the language. It makes no more sense to demand that everyone who programs in Python caters to beginners, than it makes to demand that everyone writing in English write at a 3rd grade reading level for the sake of English language learners

Containers being “truthy” is quite basic Python and you will find this idiom used in nearly every Python code base in my experience