I don’t have experience with how it affects JavaScript specifically, but independent of programming language, it usually removes the guesswork where the error might be.

The thing is that compilers use fairly static rules for their grammar. So, even if you just typo a comma where there should’ve been a dot, then its grammar rules don’t match anymore and it doesn’t really know what to do with your code.
To some degree, it’s possible to say certain symbols just cannot appear in a specific place, but especially with a comma, it could be the start of the next element in a list, for example.

Without semicolons, it’s likely going to tell you that something’s wrong between somewhere before your typo and the next closing brace (}). With semicolons, it can generally pinpoint the specific statement where the comma is wrong.
This should also make analysis quicker while you’re editing the code, as it only has to check one statement (or two, if you’re inserting a new line and haven’t typed the semicolon yet).

Somewhat of a cheap answer, but I feel what illustrates the difference quite well is that Linux follows the design from UNIX, which was a research project with stupid amounts of money to at least try to get things right. On the other hand, Windows originated from an OS, which was referred to by its developers as “Quick and Dirty Operating System”.

And I do feel like these foundations have informed the design of all the layers built on top.

That’s terrifying, especially in JS where no type system will fuck you up for returning nothing when you should’ve returned a boolean.

Hmm, a webdev colleague said he’d normally prefer without semicolons, but used them anyways for better compile errors.

If the part you dislike is having to manually download updates, then this might be a solution: https://f-droid.org/packages/de.marmaro.krt.ffupdater

I split my notes/todos into multiple files, but I wrote a small program which basically just creates a file with a randomized name in a flat directory and then opens it in my default editor.
I just want to be able to start typing right away without worrying where to put the note or what to title it or whatever. Like, I will put a title on it and include some keywords to help me find things again, but I can do that later when I don’t need to noting things down…

I guess, that’s an opinion to have then. I interpreted your point about toxicity to mean something different.

I will say that it certainly isn’t the case that no one in the community cares about namesquatting. You can likely find lively discussions around that right now.

But I have to admit that I don’t concern myself with it too much.
The thing for me is that one of the solutions that people suggest (for some of the problems that namesquatting has) is namespacing. And Rust kind of already has that, because it’s already pretty customary to create basically meta-packages with feature-flags to pull in other packages transitively, meaning your users will only need to get one package name right.

Well, and the other thing is that the official package registry isn’t nearly as important in Rust as it is in many other languages, because you can also specify dependencies by providing the URL to the Git repository, with no registry involved. It’s mostly just for visibility that you’d stick something onto the official registry.

I feel like the LLMs really encourage that, too. They’ll deliver some garbage and then you tell them to make it less garbage and they’ll be like “You clever son of a removed, why didn’t I think of that?”.

Sure, but I’m saying in general. I don’t know why you’re so convinced of your position from the one experience you had.

Yeah, in particular, you can write libraries in Rust, which can be used in virtually any other programming language, similar to how you can do in C and C++. And given that not a ton of young kids learn C/C++, there’s a chance that the majority of important cross-language libraries (like OpenSSL, SQLite etc.) are written in Rust in a decade or two.

In my experience, the Rust community is pretty welcoming. Like, it’s actually a meme that trans women code in Rust for that reason.

I do think, it’s fair to use Python code which uses C under the hood in benchmarks, because it does often match reality. But then it also has to be realistic code. If it’s just a single line of Python code, which calls into C and then everything happens there, then there is really no point for you to use Python.

Python only makes sense to use, if you do write some amount of glue code with it. And then it does require significantly more skill to write performant code than it does with many other languages, as lots of costly abstractions are hidden from you. And it often also requires more effort, since you might not find performant libraries, since so much of the ecosystem only has performance as an afterthought. Reality is messy, which is why realistic Python code still tends to do terribly in benchmarks, whether it calls into C or not.

Yep, apparently this works, for example, to set the scaling to 150% on monitor 1:

kscreen-doctor output.1.scale.1.5

Yeah, feels a little bit early when I know some devs in my company that still have x86 Macbooks, but I guess, it’s not like bugs will show up immediately, so we’ll see how that goes…

Yeah, I can see your point. It’s certainly not something you should overuse, just because it’s convenient.

I feel like the redeeming points are that it will only be available, if it’s the same error type. And if you use a catch-all error type, like anyhow::Error, which makes it likely for nested results to use the same error type, then it’s likely that you can use ?? already.
So, personally, I feel like it isn’t something that juniors will readily/wrongfully incorporate into their error handling routine and rather it is a tool that’s available for when you know what you’re doing.

Result::flatten() is probably my favorite addition, but those lifetime linter changes might be really good, too.

Yeah, I’ve been using scripts to set only the parts I actually want to modify, which is already a pretty good step for reducing the amount of information and knowing what you publish without having to review the dotfiles when you back up your latest configuration changes.

But even with that, there’s some info I do not particularly want public.
Like, it starts with the name of my user account showing up in places. On my personal device, I just call it “main” to sidestep this whole problem, but if I want to use those scripts on my work laptop, well, the user name there is a shorthand of my real name, which I do not want to publish.

But there’s also lots of things in between.
Like, I make music as a hobby, which isn’t really something I care to announce to the world, but decided I don’t mind the world knowing either.
On the other hand, I decided against sticking my RSS feeds into there for now, because I want to be able to add any RSS feed without having to think about whether I want that particular interest public.

Pepe was sort of chosen by the staunchest Trump supporters as their symbol in the wake of his first term. That certainly sparked a controversy, because some folks were only exposed to assholes using Pepe, so they associated you with assholes, if you used Pepe. But other folks liked Pepe as a meme and decided to use it even more, because they did not want it to be appropriated by assholes. So yeah, that’s why this question exists.

There’s more details here: https://en.wikipedia.org/wiki/Pepe_the_Frog#Use_by_the_alt-right

lib.rs has always been more opinionated, because it isn’t an official project. I imagine, those who look for opinionated will have no problem with this. It certainly made me like the site more.

So far, I’ve also always added a splash of olive oil, but I cannot imagine it ruining the tomatoes when you don’t, since they mostly just cook in a pan. They have too much moisture to really grill (unless you leave them for far too long).