Yeah, I always hesitate to recommend distros. 😅
There’s tons out there and they all exist, because some smart person decided to put in lots of work, as the existing ones didn’t match what they wanted.

If we exclude Ubuntu/Debian-based, that narrows it down somewhat. The other major distros are:

• Fedora: Rather much tied to the corporate side (Red Hat / IBM), tends to be rather up-to-date. Kind of has a focus on GNOME, but other “Spins” are available.
• Arch: Community-driven, pretty much a DIY distro, so the initial setup is somewhat challenging. It’s really up-to-date, so much that it’s referred to as “bleeding edge” (rather than cutting edge), meaning you might get faulty updates from time to time. It’s also often loved by minimalists, because they can decide for each component, if they want to install it.
• Well, and perhaps the most niche of these – which is what I’m on – openSUSE: Has the best integration of KDE (not by a huge margin, but still). I like it in particular, because of its snapshotting system. It automatically starts snapshotting your OS (not the user files) once per hour or whenever you make changes to the installed packages. If something breaks, you can boot into a previous snapshot from the bootloader and roll things back.
  It’s the most “maximalist” mainstream distro, in that it preinstalls relatively much software. Personally, I think the other distros are a bit silly with their minimalist tendencies, but yeah, I’m biased. And well, downsides of openSUSE are that it is somewhat niche. You’ll find a helpful, tight-knit community, but it’s less likely that guides mention how to do things on openSUSE. Similarly, you’re less likely to find pre-packaged software for openSUSE. May have to compile from source more often, although SoS has a good amount of software, too.

As for whether a different distro is too much experimenting, if you do jump into it, you’ll understand why I talked about the desktop environment instead. 🙃
The DE makes a much bigger difference. Some people conflate distro and DE, because certain distros will have certain default DEs.
But if you used the same DE on two distros, honestly the main difference you’d notice is a different package manager. Where Ubuntu Studio and Mint use apt, openSUSE uses zypper, Fedora uses dnf and Arch uses pacman. They handle somewhat differently, but largely do the same things (i.e. install/update/remove packages).
Obviously, there are more differences to the distros, like how quickly they update and some of the default configuration, like the snapshotting I raved about, but ultimately it’s still a Linux system with much of the same software running on both…

Well, that was kind of a general statement. Mint is boring. That’s what it’s good at. That’s why it’s loved and why it’s recommended for new users. Specifically, it’s similar to Windows in many ways. It’s somewhat more customizable, but that’s about it.

With you having used Linux twice before, you could consider something less Windows-like, less boring. I’ll be talking about the desktop environment (DE) rather than distro, because it has much more influence on this. You can use these DEs on various distros.

• My personal favorite DE is KDE Plasma. The default-layout is also Windows-like, but it’s got all of the bells and whistles and options you could imagine. It’s kind of power-user heaven and almost like a toolbox to build whatever workflow you want.
• The other big, popular DE is GNOME. It’s more macOS- and Android-like and focuses on a specific workflow. People who can get used to that workflow, then often really like it. The workflow itself is sometimes frustratingly uncustomizable, but it’s also fairly customizable when it comes to the details, typically by virtue of also having lots of features, which can then be customized.
• Well, and I guess, I’ll throw in Xfce, too, since that’s likely what you used, back when you used Ubuntu Studio. (Ubuntu Studio uses KDE since the October 2020 release, but used Xfce before then.)
  Xfce isn’t necessarily what modern beauty standards would get flustered by, but many folks like it for its simplicity and because it is perhaps even more boring than Mint (without being Windows-like). There’s a good chance that it still works a lot like back when you used it.

Perhaps also worth mentioning that Mint’s DE is called “Cinnamon”, although it’s developed by the Mint devs, so if you like that a lot, it’s typically worth sticking to Mint.

> C:\
> on linux

Absolutely illegal.

Well, Mint is still one of the top recommendations for new users. It gets support for the newest hardware at a bit of a delay, so if you wanted to follow suit with your new gaming PC, it might not be as great of a choice for that for now, but for your laptop, that’s what I’d recommend, if you’re not looking to experiment.

What distro did you use before?

This is a very mild violation, but I like to play these puzzles: https://www.chiark.greenend.org.uk/~sgtatham/puzzles/
…except that I create a custom difficulty level which is quite a step below the easiest difficulty and then I almost rather speedrun the puzzles.

The Rectangles puzzle at 5x5 size has been my crack for the past months and I’m at about 13 seconds now (using my phone as input).

I mean, it’s very casual speedrunning. No one cares about my time, so I actually never timed myself before just now. But yeah, I just like the different challenge of thinking fast rather than complex.

Personal pet theory that may also play into it: Trans people are also often in information security roles. Potentially, because when you have to hide your real identity, you start to get good at it.
And Rust also has various security benefits, especially when compared to C, but also when compared to garbage-collected languages (race conditions are largely prevented).

No…

There’s always been a tendency of folks reading programmer humor to be beginners rather than seasoned devs. I think, there’s just more of those in general, as there’s lots of fields where entry-level coding skills are good enough…

Ah yes, intentionally misunderstanding someone’s comment. We’ve all seen them.

I mean, what the heck is this passive-aggressive comment? If you disagree with me, then come at me.

It’s a programming language, which is particularly relevant for Linux, because it doesn’t require a runtime (separate program that runs the code). This allows it to be used in the kernel.

But it also means that it’s very good for building libraries. With a small bit of extra work, virtually any other programming language can call libraries implemented in Rust (like you can with libraries implemented in C).
Add to that, that Rust allows for performance similar to C and makes lots of typical C bugs impossible, and suddenly you’ve got folks rewriting all kinds of C libraries and applications in Rust, which is something you might have also heard about.

Yeah, as I understand, in the terms of language design theory, it is technically still “manual memory management”. But since you don’t end up writing malloc() and free(), many refer to it as “semi-automatic” instead, which certainly feels more accurate.

Really not sure an estimate for algorithmic complexity is the right way to specify this. 😅
But if your supposed input unit is days, then I guess, yeah, that kind of works out.

Yeah, if middle management micromanages you, that’s likely because their boss makes them answer some uncomfortable questions, if anything goes wrong.

Wildly depends on the complexity of the feature. If it only takes 4 hours to implement, you might have good enough of an idea what needs to be done that you can estimate it with 1-hour-precision. That is, if you’re only doing things that you’ve done in a similar form before.

If the feature takes two weeks to implement, there’s so many steps involved in accomplishing that, that there’s a high chance for one of the steps to explode in complexity. Then you might be working on it for six weeks.

But yeah, I also double any estimate that I’m feeling, because reality shows that that ends up being more accurate, since I likely won’t have all complexity in mind, so in some sense my baseline assumed error is already 100%.

Well, I think your idea would be simpler, if we weren’t talking about Java.
Pretty much everything is an object in Java. It’s only logical that a type would also be an object and have associated fields.

Similarly, what you’re thinking of as “reference types directly” doesn’t make sense in Java, because it lacks many of the systems to make that actually usable like a type. What you get from .class is a Class object, which you can’t stick into a generic type parameter, for example.
It basically uses reflection to give you e.g. the name of that type and you can also instantiate an object of that type, if no parameters need to be passed to the constructor function.

And then, yeah, I think for explaining that you merely get an object which roughly describes the type, the separate .class field is a good idea.

I figured, I’d ruffle some feathers by saying that. 😅
But yeah, I stand by my point. Just because your target users are capable of dealing with complexity, doesn’t mean you should be making use of that rather than simplifying usability, since your users have plenty other things they could be learning instead.

I will caveat that I can see it becoming worth it to learn an intricate logic for a power user, when things fall into place and make sense at a higher level as you learn more about it.
But in my experience, that’s just not the case with package managers. You need a few specific commands to be obvious and then the special cases can be obscure flags.

Arch’s package manager is pretty terrible.

Here’s two commands. See if you can guess what they might do:

pacman -S package_name
pacman -Syu

I believe, there’s some sort of logic to the letters, but man, most users seriously do not care. They just want to install, update and remove packages 99% of the time, so they shouldn’t need to learn that intricate logic for three commands.
I guess, you could use pkcon to do that instead, but that doesn’t really help new users…

Well, it also avoids running instantiation code, which could be doing all kinds of things. In theory, it could have a side-effect which modifies some of your application state or issues a log statement or whatever.

Even if it doesn’t do anything wild right now, someone could change that in the future, so avoiding running such code when it’s not needed is generally a good idea.

I don’t believe there is much deeper of an explanation than “because the Java designers didn’t implement support for that”.

That feature is called “types as a first-class value” and you need to implement some special casing or an entire system in the language to make it work. Telling devs there’s a special static variable .class is conceptually simpler to implement and understand.