ladyanita22

This is deeply dystopian

I am happy that Rust defaults to the easier, saner, safer approach by default, but lets you bypass RAII if you want to do so.

I do like it

Looks really nice. Any similar projects in Rust?

Well, I'm happy someone did break the guidelines, as this title gives me far more information.

If the title hadn't been editorialized, I would have simply not clicked here.

I have found him to say some incorrect stuff and being extremely reluctant to even reflect on it.

I dislike him quite a lot to be honest...

Exactly, and that is a thing for every single piece of software ever written. Doesn't make a difference whether it's an OS or not.

There was a test with the 1BRC and it was shown that Rust was faster than Assembly (and likely C as well), meaning, a compiler will probably do a better job than a human optimizing code. How sure can someone be that this is indeed performant?

My takeaway is that an engineering degree doesn't have anything to do with a guy that, from that message, looks to me as an arrogant narcissist (by how smart he tries to be) who likely doesn't have trained too well his acceptance for frustration and who seems to give in his impulses disregarding anything else.

And your takeaway is, for me, infantile, naive and dangerous. This guys is not a victim of a system, this guy is a killer, whether we like that CEO or not.

Tiny Glade is Vulkan, not WebGPU. Not sure which library though

I'm interested in reading more. Where will you continue this?

Then performance of WGPU will always be problematic, below that of the native APIs (DX, vk and Metal), and constrained within the limits of the WebGPU spec.

You're describing the WebGPU spec and its different implementations.

OP claimed WGPU had native support for VK, DX and others. But as far as I know, WGPU just supports WebGPU being translated on the fly to those other backends, with the obvious performance hit. If I'm wrong, I'd be interested to know, as this would make WGPU a more interesting choice for many if, in reality, the code was native instead of translation.

Edit: https://docs.rs/wgpu/latest/wgpu/#backends it seems they indeed support native code in almost every backend?

I thought WGPU only supported WebGPU, and then there were translation libraries (akin to Proton) to run WebGPU over Vulkan.

Does it directly, internally, support Vulkan instead of on-the-fly translation from WebGPU to VK?

Flatpak permite que un único paquete sea compatible con prácticamente todas las distros Linux mainstream.

Translated (for the rest of the world): Flatpak would let a single package be compatible with practically all mainstream Linux distros.

Important to upvote this. If there's room for improvement for Polars (which I'm sure there is), go and support the project. But don't fall for a commercial trap when there are competent open source tools available.

That's exactly what I was wondering. That cannot be.

I see lots of comments about how good VB6 was. I agree it made programming super-easy and practical.

However, it is evident to me how the whole thing fell appart by the late 2000's, and now we have much more powerful, yet complex programming environments:

- Rust, C, C++: Extremely complex but powerful.

- HTML, JS, CSS: You have to learn 3 different technologies and won't be able to leverage the easy, powerful native APIs the OS provides. It's cross-platform though.

- .net: Not as easy as VB6 (and C# becomes actually more and more complex, more powerful as well, though). You have to learn XAML as WinForms is still a thing but considered legacy.

- Python: Easy (maybe more than VB, but not by much?), but no native, easy GUI toolkit for Windows. There are native bindings for GTK, but Linux is not a big desktop platform, and more so in business, and still GTK is much, much more complex than VB6 + Winforms + COM.

So basically, it seems we have traded easy of use and practicality for power/performance and cross-platform compatibility? What do you guys think?

I can only say that, going through the filesystem of the emulator, I saw a .so for SELinux, which makes me extremely suspicious

> Any normal Rust kernel will either have issues scaling on multi-cores or use tax-heavy synchronisation primitives. The kernel RCU and lock-free algorithm took a long time to be discovered and become mature and optimised aggressively to cater for the complex modern computer architectures of out-of-order execution, pipelining, complex memory hierarchies (especially when it comes to caching) and NUMA.

Why would that be the case at all? What has Rust anything to do with that?

Meta's Horizon OS is Android, so they could basically just do the same. Of course, they don't have a proper app store for that, but the compatibility should be there.

The main roadblock would be the OS support, and Meta's already has that. They are of course lacking another big roadblock, which is the store.

Is Rust still unable to do any kind of segmented memory modeling? Does it still assume flat memory?

Not anytime soon, buddy

Wasn't this already possible through RPMfusion?

I was wondering how did you manage to translate WGPU code into Ratatui code, but I guess there was no WGPU in the first place. Actually, it is kinda cool that you can switch renderers in Bevy, meaning you can take advantage of whatever API you may want.

I'd like for Tauri to support native Widgets in iOS and Android.

Why would one use Tauri instead of Electron in that case?

Then you only have Ubuntu, Fedora, Red Hat/CentOS/Alma/Rocky and Suse/OpenSuse.

Same, would like to see the same but implemented in Rust

Update us please!!