anarki8

no profile record

comments

2 месяца назадdiscuss

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.

7 месяцев назадdiscuss

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.

7 месяцев назадdiscuss

https://killedbygoogle.com/

8 месяцев назадdiscuss

> 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.

8 месяцев назадdiscuss

> The problem is that rust is being shoved in pointless places with a rewrite-everything-in-rust mentality.

> There's lunatics ...

I think the problem is people calling developers "lunatics" and telling them which languages they must use and which software they must not rewrite.

Battle tested is not bulletproof: https://cybersecuritynews.com/sudo-linux-vulnerability/

Applying strict compile time rules makes software better. And with time it will also become battle tested.

8 месяцев назадdiscuss

> You can't go around screaming "your code SUCKS and you need to rewrite it my way NOW"

It seems you are imagining things and hate people for the things you imagined.

In reality there are situations where during technical discussions some people stand up and with trembling voice start derailing these technical discussions with "arguments" like "you are trying to convince everyone to switch over to the religion". https://youtu.be/WiPp9YEBV0Q?t=1529

8 месяцев назадdiscuss

> 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.

8 месяцев назадdiscuss

> Rust cannot recover

Recoverable error mechanism in Rust: https://doc.rust-lang.org/std/result/enum.Result.html

8 месяцев назадdiscuss

> 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.

9 месяцев назадdiscuss

I wouldn't say it's bad at GUIs either. There are some nice libraries like Iced and Slint. Some even have good accessibility support like egui.

There is a full-fledged DE written in Rust that uses Iced: https://en.wikipedia.org/wiki/COSMIC_(desktop_environment)

11 месяцев назадdiscuss

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.

11 месяцев назадdiscuss

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.

11 месяцев назадdiscuss

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.

в прошлом годуdiscuss

You don't really need any exotic OO GCed language to enjoy concurrency safety without deadlocks.

в прошлом годуdiscuss

I find myself using channels in async Rust more than any other sync primitives. No more deadlock headaches. Easy to combine multiple channels in one state-keeping loop using combinators. And the dead goroutines problem described in the article doesn't exist in Rust.

в прошлом годуdiscuss

I have been annoyed by this before, but now it's mostly obvious troll or sarcastic posts.

Rust haters' cult on the other hand...

в прошлом годуdiscuss

I am not sure what are you trying to represent with this example, but here is the exact same thing without any unsafe:

use rayon::prelude::*;

use std::time::{Instant, Duration};

use std::sync::atomic::{AtomicUsize, Ordering};

fn main() {

    let finish_at = Instant::now() + Duration::from_secs(1);

    let number = AtomicUsize::new(0);

    (0..10).into_par_iter().for_each(|_| {
        while finish_at > Instant::now() {
            number.fetch_add(1, Ordering::Relaxed);
        }
    });

}

You can make it even simpler if you would use Mutex instead of atomics. Atomics are more performant though.

в прошлом годуdiscuss

redb is what are you looking for

https://github.com/cberner/redb