tcfhgj

Interesting, I have no use of bots in my messenger at all.

What does the Telegram Bot api have, what Matrixes API doesn't have?

Haven't threads been one of the reason some core util got faster?

I bet you don't know the reason for existence

> so it's quite adaptable to whatever needs you have.

as a user you cannot, even if you self host, because you are not the one controlling message storage

> I'm not sure what you mean by not handling encrypted messages fully, it handles encrypted messages fine.

you can load encrypted messages (including keys if they are needed to decrypt them if necessary) using a fresh login such that you can read them again?

call me out if I am wrong, but isn't history dependent on the server of the chatroom creator, and doesn't every server have different history settings and does it not handle encrypted messages fully?

> As for the second point, Matrix's ever-moving target of a protocol makes selecting a client or server that covers all of your needs a massive pain. Currently, Matrix's primary server software, Synapse (which is also at the base of the matrix.org server many people default to when joining the network), is violating the Matrix protocol, making it impossible to invite users to chat if they are on compliant Matrix servers.

could you expand on this in detail?

wait until capitalism collapses

Still some people don't block ads and people pay for it.

Simple as that.

on the other hand it is trivial to project goroutines onto Rust-tokio async/await:

function func() -> async fn func()

go func -> tokio::task::spawn(func)

func() -> func().await

func_blocking() -> tokio::task::spawn_blocking(||func_blocking()).await

(not sure about cancellation behavior in go though)

so? avoid it where you can

how would one be executed when the function is explicitly waiting?

also it's an example to demonstrate the differences of async implementations of languages, not a excerpt of a production code base

nothing is optimized away, it's just not executed - e.g. the program including semantics of the language is just designed such that it is not executed.

e.g. for Rust/tokio printing B is skipped, because the process exits and cancels the future before the task can print B

> for it to bring benefits your whole codebase needs to be doing it (ingesting requests, db calls, web API calls).

not really - the core of apps (usually no outside dependencies), and additions which solely rely onthe core, usually can be implemented without async entirely; async only comes into play once you add dependencies to file system, network and ui, but you don't need to make the core async for that. You might not call some functions in async code at all, because the function is used only for heavy computation which is best handled by dedicated threads to avoid stalling your io handling.

100% sure - Java just has to store and process more than a simple state machine, also if all threads are busy with compute bound work, async work is stalled if you don't put the compute bound work on adedicated thread (pool)

they are still more expensive than compiled async await, also mixing compute and io-bound work can cause issues

> Go sort of asks why tho and just standardizes on go routines as a good abstraction over both concurrency and parallelism.

if it is really that good, why didn't Rust adopt the same thing?

I don't feels sorry for people shoving or paying to shove ads in peoples faces.

I did not claim nobody's medical care was affected.

It could have happened if it was uncommon and it could have happened if it is common.

My claims:

1) most flight's are not necessary

2) it's not common to fly for medical care (yes, very rich people may have a different perception, but that's all it is)

also I think RCS is way to insecure for Graphene OS - they have no way of making sure the communication is actually 100% secure.

In my experience, Graphene OS doesn't make compromises.

Hacker News, without AI needs to be a plugin for Firefox - I don´t really want to use two pages at the same time.

I am not talking about calling C functions, but about providing a stable ABI for your binary.

Rust supports opting into the C ABI

You don't have to use Cargo,you can fall back to just using rustc; also Cargo supports censoring, meaning you can use locally stored crates.

Need is a bit strong, you can absolutely apply and do homework without, e.g. using Typst or Latex or whatever else is out there

Still can switch isp usually

Now that WinUI has a Rust API, I think using Rust is a no-brainer.

The app will be running on probably about a billion of devices, and Rust will reduce the footprint on each of those - assuming not a vibe coded clone app.

The additional effort isn't that big, and it would make the experience of maaaany users a bit better still.

Now extrapolate on all windows included apps and ui elements.

How much would that cost per license?

Still, it's fast enough that Rust frameworks can compete with the fastest JS frameworks on UI benchmarks [1]

Imo bundle size is a bigger issue.

[1] https://youtube.com/watch?v=4KtotxNAwME

Win forms/WPF is essentially legacy, and using C# consumes much more resources than Rust (even for UI, see Windows Reactor C# vs Rust).

Additionally, I don't think C# is that simple anymore. By now it has so many features added and the list is still increasing this day. Rust is more difficult to get productive, but the actual language complexity isnt that big.

LLMS makes onboarding to Rust much easier though if you even still write code yourself. I don't think the productivity difference is that large.

Well that leaves up to almost 50% potentially not written in either language.

And little code can already have a big impact, e.g. react native in start menu coupled with edge running in the background

Which sends your login data straight to microsoft