I'm guessing lemmy.cafe has .ml blocked but not the other way around, OP likely can't see your comment

In the grand scheme of things the difference between C, C++, and Python isn't meaningful when operating over a network (edit: for a single-user system). It's very likely that the difference for thread OP is just caused by weaker connections to specific repos.

We're talking about a package manager, not a game, network server, etc. On a basic level the package manager only needs to download files from a network and install them (OS syscalls for reading/writing files, these are exposed C functions or assembly routines), or delegate to a specific package's build setup (which will also likely be written in a compiled language)

Sorry for being unclear, I wasn't trying to say language doesn't make a difference (e.g. static vs. dynamic typing would make a big difference). I also personally like the error handling of rust a lot more, even if it does take a bit getting used to when my education has mostly been in languages with Java-style exception handling.

I mostly meant that the language-level performance and features aren't necessarily holding the codebase back in a debate between Java and Rust for a lemmy-like REST API. As long as the developers are aware of the pitfalls of Java (null, mutation, error-handling, etc.), it's possible to have good code.

I just think that from a maintainability standpoint, a Java-style codebase is much easier for most people to read, understand, and maintain because that's what most people are familiar with. Especially when many of the developers are volunteer contributors, that type of thing could make a big difference.

The main problem with Rust is that it's only starting to get adoption now, it isn't taught in most education curriculums, and it's industry use is pretty small at the moment. It's kind of a catch-22, because rust adoption won't increase unless large projects like lemmy exist. But that's also why I think having more options is also fine. Sublinks might get more developers short term because of its language, but that also doesn't mean it'll completely replace Lemmy. Both projects can exist at the same time, and hopefully benefit from each other's development.

A lot of people here seem to think that Java code is awful and disgusting and no projects should ever use it. The thing about popular languages is that more code existing in a language inevitably means a lot of it ends up being bad. The same thing will likely happen to rust as it gets popular, but that isn't exactly a problem. It's possible to have a well-maintained Java codebase.

Debate between functionality of the actual programming languages at this point is pretty meaningless, if they have good development standards then a Java program could end up just as well maintained as rust. Any time saved by compiler enforcement of specific standards (like no using null) would be lost by the fact that the devs don't know rust tooling. You could just have a requirement in PRs that null isn't used. Both Java and Rust have usable frameworks for REST API development, so using one or the other comes down to familiarity.

The idea that programming languages make code suddenly good or bad is pretty silly. Different languages have different language-level guarantees which can help produce good or working code. That being said, it's not like it's impossible to write good Java code, just like it's not impossible to write bad rust code. Most people seem to be conflating guaranteed functionality and safety with maintainability, stability, and readability. Rust is still a new language, so although it's great, Java will probably be the better choice for the latter 3 qualities.

That being said, something like Kotlin would probably have been a better starting point since it can interact with Java (and works like Java in most cases) but also has some nice improvements like stricter null checking (Kotlin nulls are treated similarly to rust's Option<T>, it's just described as T? instead and the syntax is generally a lot more concise). There's also the benefit of being able to write some code in Kotlin and some in Java since they are mostly cross-compatible.

Java is reasonably fast though, as the JRE is pretty well optimized at this point. Languages closer to being fully interpreted like JS and Python (technically both python and JS still get compiled to a lower target and then interpreted) are still noticeably slower.

Edit: there's also the fact that JS/TS runs on a single thread, so it's inherently limited for applications intended to be scaled up.

Which costs an additional $100/yr for something that's free on any other platform.

Note that a few of these are misleading...

AngularJS no longer exists because the library switched to TypeScript (which can be used with JavaScript code) and is now just called Angular. For the non-developers, TypeScript and JavaScript are mostly cross-compatible, and having a typing system makes way more sense for what Angular tries to accomplish. They didn't actually kill the project.

The Google Duo app also got more or less facelifted into Google Meet, so it's not like it's actually dead.

Those things being said, the amount of things on that list is pretty crazy. Especially the ones that were straight up canceled and not rebranded/replaced.

"socialist"

Coal mining kills more people per year than nuclear does. Pollution kills more people by several magnitudes than nuclear ever could. When proper safety measures are put in place it's by far the safest form of energy. And regardless of whether people make nuclear power plants, the technology exists, so it will be used to make bombs regardless

How so? I usually find their content pretty interesting

As a current computer science college student who was a TA for 2 semesters, can confirm... It's wild out here

Honestly It's been way worse for me lol, the discussions here are actually meaningful so I can sink way too much time reading threads instead of getting bored after looking at 5 consecutive reposted memes on reddit

Edit: I'm not complaining though, this is definitely better