balsoft

Rust does not have exceptions. You never have to try/catch. Functions usually encode the possible failures in their types, so you'd have something like this C++ snippet:

struct HttpError {
  std::string message;
  int responseCode;
}

struct FsError {
  std::string message;
}

typedef std::variant<HttpError, IoError> FileDownloadError;

std::variant<std::filesystem::path, FileDownloadError> downloadFile(std::string url) { /* ... */ }

And then the caller of downloadFile has to decide what to do if it returns an error:

auto res = std::visit(overloaded {
	[](FileDownloadError e) { /* ignore error, or handle it somehow, and return a new path */ },
	[](std::filesystem::path p) { return p; }
}, downloadFile(url));

/* res is guaranteed to be a valid std::filesystem::path, you don't have to care about errors from downloadFile anymore */

However, Rust makes this whole thing a lot easier, by providing syntax sugar, and there are helper libraries that reduce the boilerplate. You usually end up with something like

#[derive(Error, Debug)]
enum FileDownloadError {
  #[error("HTTP request failed")]
  HttpError(http::status::StatusCode),
  #[error("Filesystem error: {0}")
  FSError(#[from] std::io::Error),
}

fn download_file(String url) -> Result<Path, FileDownloadError> {/* ... */}

(notice the #[from], which forwards the error message etc from the std::io::Error type)

The Result type is kind of like a std::variant with two template arguments, and, mostly by convention, the first one denotes the successful execution, while the second one is the error type. Result has a bunch of methods defined on it that help you with error handling.

Consumer code is something like this:

let res : Path = download_file(url).unwrap_or_else(|e| {
  /* Ignore the error or handle it. You have to return a new path here */
});

/* res is guaranteed to be a valid Path, you don't have to care about errors from download_file anymore */

Or

let res : Path = download_file(url)?;

/* res is guaranteed to be a valid Path, you don't have to care about errors from download_file anymore */

Which will just forward the error to your caller (but your function has to return Result as well), or proceed with the execution if the function succeeded.

Finally, download_file(url).unwrap() is if you can neither ignore, nor handle, nor pass the error to the caller. It will abort if the function fails in any way, and there's no (practical) way to catch that abort.

It's worse than just exceptions in C++. There's (almost) no way for the caller of your function to catch it. It's a bit like this snippet:

std::optional<int> foo = <...>;
try {
  return foo.value();
} catch(const std::bad_optional_access& e) {
  std::cout << e.what() << std::endl;
  abort();
}

It's the abort that is the crux of the issue here. Usually you would pass the std::optional up/down the call stack. If you don't control the types (e.g. using a library or a framework) you'd come up with some "default" value instead, like this:

std::optional<int> foo = <...>;
return foo.value_or(123);

Or in Rust:

let foo : Option<i32> = <...>;
return foo.unwrap_or(123);

But sometimes there's no good "default" value, and then you have to resort to just unwrap-ing the value, and accepting that the entire program will abort when that function call fails. Usually this is a sign of poor engineering somewhere, likely in a library you're using, and should be fixed; but sometimes you don't have the time to fix it, and then it ends up in production.

To me it's more surprising to have parking at a grocery store. In places I lived, it's usually just on a ground floor of a residential building, and if there's any parking nearby it's either for residents only, or a municipal parking spot (which is almost always taken up by residents anyways). Almost nobody specifically drives to buy groceries, you just get what you need on your way home from work/gym/after hanging out with friends. Or, if you need to buy a lot of shit, you use a shopping trolley or something.

And I'd still consider cities like that carcentric hellholes, the american suburbia seems just unfathomably bad for me.

no it cannot because it’s referring to whether or not the workers control them and on a societal scale this is a binary flip, at some point the workers are more in control than the bourgoeis and at that point it is socialism and at any point before it is not.

Aha, so you do agree that different societies have different levels of control the working class and the bourgeois have over production, but you seem to be convinced that if that "relative level of proletarian control" is below 50% the state is fully capitalist, and otherwise the state is fully socialist. Why do you think this definition is more useful than the obvious one, where we retain the scale instead of quantizing it into a binary form?

This question is especially relevant because you also seem to believe that there currently aren't any "socialist" countries by your definition. By retaining the spectrum, we can then make analytical statements like "China is more socialist than the US".

if it can only breed with other cats it is a cat and not a dog.

By this overly simplistic definition you would count infertile cats as non-cats. You also completely lose the ability to differentiate the species of non-sexually reproducing organisms. And then there's the insanity that is hybridization. Is a mule a horse or a donkey? They can occasionally reproduce with either of them.

In reality, differentiating species is a complicated science/art that involves not only the reproductive isolation, but also morphology and genetics, all with the goals of coming up with the most useful definitions for species.

In just the same way with economic systems. Workers in different societies and periods exercise different levels of control (which is the underlying meaning of ownership) on the means of production, it's not black and white. It can be very roughly defined as (workers control over the state) * (relative assets of state-controlled enterprises) + (relative assets of co-ops or other directly worker-owned enterprises). There is of course a lot more nuances to be discussed, such as the exact distribution of control between different subclasses of workers, or the social hierarchies arising from the structures of control. Once again, the goal is to come up with a useful scale to gauge how much a certain country or region has progressed on its way to socialism, to learn from their mistakes and to build better governance systems in the future.

a society is either 100% capitalist or 100% socialist.

This is never true in the real world, everything is a spectrum. Do you think there are any countries that are 100% socialist in today's world? If yes, then I highly doubt it's actually true, if not, I suppose you count them as "100% capitalist", which is a classic "no true Scotsman" fallacy.

And then the spectrum not linear either, on the "capitalist" side of the spectrum you have capitalism and fascism, each controlling the working class through different means; and on the "socialist" side you have various ways in which the working class controls (or is told that they control) the means of production; everything from anarchism to councilism to syndicalism to leninism to maoism to stalinism, and a million varieties in between.

I do agree with your other point, though, universal healthcare is almost entirely unrelated to actual socialism/communism, it just turns out to be a (very beneficial) consequence of redistributing power to the working class.

I strongly recommend going on hikes in the mountains, ain't no car can get there! (this quickly turn into a problem if you break your leg or something, so be careful)

The actual resolution to this conundrum is of course: build more public transit and bicycle infrastructure, ban private cars in cities, replace parking lots with multi-story mixed-use buildings.

I hope they keep the offline translation. It's actually an OK use of LLMs with two caveats: I'm not sure how ethically they have been trained, and I don't trust the output for anything vaguely important.

Telegram can serve you your old "Cloud" messages, in a decrypted form, on a new device, without any communication with the old device.

This means that they possess the keys to decrypt the messages, since they can send them to you in a decrypted form.

Those messages can't even be encrypted with your cloud password (which would be a pretty weak encryption anyways), because you can reset the cloud password via your recovery email, and still retain access to your messages.

Contrast this with encrypted chats on Matrix, where you have to go through the device verification procedure, which prompts the old device to send decryption keys to the new device (it's actually more complicated but this gets the point across). If you lose access to all your devices (and your recovery key), your encrypted messages are gone, the server admin can't restore them because they simply don't have the key.

No one can’t prove that Telegram use MTProto to encrypt content sent using Cloud Chat, stores them encrypted, and them decrypt them upon opening because the source code for MTProto is closed. So how can you prove that what you’re saying is the way they use?

This is a distinction without a difference.

My claim is:

They possess the keys to decrypt your messages

Whether this is implemented via MTProto encryption or disk encryption or whatever, it doesn't matter, they can read your messages if they want to.

Telegram is actually pretty transparent that Cloud chats are not e2e encrypted in their FAQ. They also go on to babble about "MTProto client-server encryption" but if you spend 2 minutes looking at it, you can see it's just 256-bit AES with a shared key generated via Diffie-Hellman, not too dissimilar from plain HTTPS. In that sense it's about as secure as e-mail over encrypted IMAP/SMTP, or IRC over TLS, or DMs here on lemmy.

They also claim that their at-rest encryption keys are separate from the data they encrypt, and claim that somehow this "requires court orders from multiple jurisdictions" to force them to give over your data, which is just ridiculous from a legal standpoint and won't stand up in court. And actually, it's way more likely that they will just cave in and give up your message history without a lawsuit at all, just look at what happened to Durov in France.

I did none of this, it's the devs of transitous/bimba who are the amazing ones :)

But I'm glad I could help you find it!