How much can we customize the Librem5

Hardware Librem 5
61

I’m not exactly sure what you mean… Or rather, I understand what you mean with Rust, and agree there. It’s borrow checker isn’t actually as neat as people think. I mean, sure, it makes you think about ownership and lifetimes, but you still have to think about ownership and lifetimes.

As for python, I’m curious what py3k prevented you from doing. I do think they badly handled the move, politically, and they never delivered on a working 2to3, but I never felt artificially constrained by py3k, even before 3.4 (which was the first version with something close to feature parity with 2.x).

Actually, come to think of it, there was one thing that still bothers me… When python was new (1.3 time frame), there was a lot of pushback about it being a whitespace sensitive language, since that can lead to off-by-one errors (\n \t instead of \n\t). Its defenders argued that it used an intelligent whitespace parsing algorithm, the same one used by text editors, so that if your code looks right, it’ll run right. In practice, that required setting a #tab-width comment at the top of the file to match your editor (or use 8-character tabs), but all in all it worked great: as promised, no off by one errors. They dropped it with py3k, for no good reason. Instead, it Exceptions if it goes to parse a source code file with mixed tabs and spaces (within the same indented block, mixing them within a file is still fine, for some reason…). This is all well and good if you have a decent editor, but if you are stuck using a bad editor, relying on proper tab-stop behaviour, and invariably in a hurry, it still freaking sucks.

62

Mainly I was annoyed by print("...".format()) in Python 3. You can read my rant about the changes in Python 3:

Coming from C and PHP, I just got annoyed by the Pythonic way of doing things, so I gave up on the language and went back to the “bad” way of doing loops with incrementors, and other things that Python discourages. :slight_smile:

Rust’s borrow checker is a real pain in the rear and I hate the fact that it doesn’t want me to use camelCase. After 20 years of writing myCoolVariable, it wants me to write my_cool_variable, which is a waste of space. I have the habit of using sVariable to indicate that something is a string and aVariable to indicate that something is an array, but I find it harder to read svariable and avariable in Rust.

These really are minor issues and I know that I can allow camelCase in the configuration, but I still have to use snake_case for all the crates that I import, so I end up following the Rusty way of doing things. Mostly, I play around with Rust because I find it fascinating. I’ll probably never write a complex program that has data race issues, inheritance problems or null pointer problems, that Rust is designed to solve, but I find it interesting how Mozilla gets around those problems. It is kind of interesting to think about whether a variable should go to the heap or the stack, even though I never had to worry about it before.

Having looked at Go, Swift and Rust, Swift seems to be the best, easiest and most flexible of the new languages. Mostly I’m playing around with Rust, because it is so interesting to try something new, whereas Go feels like an improved C, so it is boring. If I was doing serious work, I would choose Swift, but I’m doing this for entertainment. Besides, I trust Mozilla as an organization, whereas I know too much about the evil stuff that Google and Apple do. Maybe it is unfair to associate a language with the company that created it, since the programmers who created Go and Swift were firm believers in open source and probably not involved in creating surveillance capitalism at Google and creating the walled garden at Apple, but my lizard brain likes being prejudiced. :slight_smile:

1 Like
63

Ah but what about the Sapir–Whorf hypothesis? A Google-designed language is specified in such a way as to force you to think in the Google way. :smile:

64

So it’s as I figured. You tried py3k, or maybe 3.1 or similar. It’s no surprise that you didn’t like it. Most people didn’t like it. There was a tremendous amount of push-back, which took a while to be heard. think it was a couple years after the fork before the core devs were concerned about the low adoption and actually took the time to listen to what people had to say (by which time, it was too late to fix the whole unicode/str/bytes thing). That said, format strings are back (using the % operator), bytes got the % back in 3.5, which was the first version I thought worth using. It took 6 years to fix the stupid changes, and funny thing, it took 6 years to see widespread adoption.

One minor point is that they didn’t change the syntax of the print statement: They removed it. This is an important distinction. If they changed the format of the statement to require (), that would be silly. It would be similar to requiring () around if, for, or while. Instead, the whole statement was replaced with a new builtin function by the same name. While it’s a bit of a hassle to convert, it’s also pretty easy to convert it programmatically, even the more complicated print >> f, stuff. Meanwhile, it allows all sorts of cool tricks, like passing print to callbacks, replacing print with a logging print for debugging, and so on. You could argue for adding the new function as printf or similar, and leaving the keyword around for a few versions, but if you’re only going to have one, the function is more useful than the statement.

Ah yeah, I forgot about that. It was one of the first things I hated when messing with rust. The second was actually the crate system. Crates are a serious security nightmare. Yeah, I could learn where they get installed, but the fact that the build system is automagically pulling in and running code from who knows where is a terrible design choice. I like my git submodule update --init, the submodules don’t then get changed unless and until I want them to.

As for the borrow checker, it’s actually kinda a neat idea, and using it for a bit will make you a better programmer in general. There are 2 languages borrowing it, which I think have a chance at being neat. V (vlang.io) and carp (https://github.com/carp-lang/Carp). Both are very new, and have incomplete borrowchecking, or other serious use-case limitations, but in a year or so I’ll probably revisit them. In the meantime, I’ve found C++20 to be the best general-purpose language, as it gets you essentially the same benefits of the borrow checker (explicit object ownership and lifetimes) without the hassle.

1 Like