anarki8

Not sure how Anubis plays with SourceHut trying to be js-free, but otherwise it's awesome.

SourceHut prohibits anything cryptocurrency- or blockchain-related, so it's less restrictive now, but I didn't like this random opinionated addition to ToS back then and Codeberg felt like a nice alternative.

Migrated to it around 3 years ago. All I needed was a dependable and simpler (preferably EU-based) GitHub alternative for my FOSS code. Now I am migrating away and stopped my donations to the e.V. Not because I have cryptocurrency-related or vibecoded projects (I don't), but because this sets precedent of introducing vague rules that ban random/unpopular projects.

Ironically, I migrated to it from SourceHut because of similar rules introduced there.

Seems previously one of the goals for the Flatpak project was to develop a universal app packaging format for Linux OS family that suits even exotic ones like Alpine and Void (and it did fantastic job at that).

Now the direction changed with the new team/leadership towards integration, security and control instead of "it works everywhere".

Hopefully basic features will still work without systemd-appd, otherwise we would be back to "Linux desktop has no universal packaging format" considering that:

* Most appimages often rely on specific libc of the base system;

* Snap does not fully work outside of Ubuntu ecosystem.

Probably because:

- better data race handling;

- no garbage collection, more predictable performance;

- stricter type system that can enforce constraints better;

- closer to metal and better FFI support.

Which seems to matter more for Tor project than support for some barely used platform.

> My point is against rewrites of critical software for the point of rewriting it insert my favorite language.

In this specific case we are talking about the maintainer adding a new language into the existing codebase.

I think refactoring parts of the software in the new language is what you call "rewrite" here, correct?

So what improvements does it bring? You actually answered it yourself:

> it's not just a matter of pretty types and memory safety

So indeed, stricter/stronger type system and additional automatic compile time and runtime checks are a major improvement.

> platform

As already mentioned in this thread: neither of the platforms lacking Rust were supported officially anyways.

> language stability

Rust is extremely stable and backwards compatible - 1.0 code still compiles without any issues on 1.90 and will continue to do so for the forseeable future.

> skill and expertise of the authors

The same developers continuing to contribute and newcoming developers have more checks in place to prevent bugs.

> development speed

I guess you imply here that developing in C++ is faster. It's in fact not if your aim is to produce correct software. There are so many more things to keep in mind and take care of with C++, you have fewer automatic checks being done by the compiler and the type system.

About Zig: it's a nice language and much more comfortable to use than C/C++ IMO, but compared to Rust it lacks in strictness and safety, so added benefits are smaller and fewer if you put away subjective preferences.

> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.

I am more concerned about correctness and "zero-cost abstraction" of the end result, if sacrificing few seconds of compilation time is necessary for that - fine by me.

> It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc<Mutex<Box<T>>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end?

So, you seem to prefer data races and dangling pointers, or? Have you tried "actors-like" channels+rayon approach if you hate mutex so much?

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

You again prefer UB and/or corrupted state (and call that "reliability") over required explicit checks of Result via matching. This is definition of bad code to me.

> When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar

Few boundary checks sometimes add negligible overhead, but again you need those in any language to enforce correctness, Rust just adds those automatically.

> We actually had a recent Cloudflare outage caused by a crash on unwrap() function

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

Would you prefer silent UB/memory corruption in Cloudflare case? I don't think most developers would agree with this.

There might be potential improvements, like using OsString by default for `env::args()` but I would pick Rust's string handling over Go’s or C's any day.

This sounds a bit overdramatic for a less than a second waiting time per week for each device. Unless you employ an army of crawlers of course.

Article might be a bit shallow, or maybe my understanding of how Anubis works is incorrect?

1. Anubis makes you calculate a challenge.

2. You get a "token" that you can use for a week to access the website.

3. (I don't see this being considered in the article) "token" that is used too much is rate limited. Calculating a new token for each request is expensive.