OvermindDL1

I think what they were referencing with that is that the kernel hardware interface is unstable, it changes literally every version, which is why you went to upstream it so you don't have to keep it up yourself after that.

To be frank, Google Sheets came installed on my phone, don't think it's ever been opened though... Easy way to inflate numbers there.

As someone with extremely similar experience to thomashabets2 over my life, but less go and more rust, please allow me to compare go's Interfaces to rusts dyn Traits, both of which are implemented pretty much identically under the hood. Rust just doesn't let you construct the data nor vtable part of the interface/trait as nil/null, in any form. Either the interface/traits instances entirely whole or it can't be instanced at all. This is the way to do it, not partially filled in one part (the vtable) and not the other (the data pointer).

My extended family are also the traditional "white trash", and yes they do indeed think this same way.

A general bevy scripting crate has already been in the works, they were waiting on various things like be y reflect and other such features to be able to work properly and so forth. In other words it's already planned and there's a lot of work being done on it with a whole lot of dependent functionality coming out in every single release.

Indeed, I personally find Rust to be very nice for rapid prototyping, incremental recompilation is usually a second or two even in my giant projects (mold helps on the linking step but that's less of a rust thing anyway), and I'm very curious how cranelift will change things in the future, it would be nice to hot swap function implementations on the fly at least.

CMEs in Java are a constant thorn to many Java programmers as a lifetime violation bug. Hell even NPEs are too for that matter, lol.

You can do it without HKTs with an effects system, which you can think of as another kind of generics that causes the function to be sliced in different ways depending on how it's called. There is movement in Rust to try to do this, but I wish it was done before async was implemented considering async could be implemented within it...

LibGDX is not so much a Java game engine as it is just a set of helper utilities and little libraries for building a game or engine out of. It is actually surprisingly efficient on the JVM, any inefficiencies will be built on higher levels above it.

I don't think this is accurate as Windows 10 and Windows 11 have edge built in, as WebView2, which is used for some internal Microsoft programs now as well, and older windows systems are not supported in any way by Microsoft themselves anymore, so it seems safe to ignore them now. I've had no issues with Tauri on Windows however, and I even compile it from Linux.

Specifically Tauri uses web views that are based on Chrome or Safari on systems, and only if they don't exist by default will it package it, which somehow still ends up smaller than electron. But on Mac and Windows it is tiny, and on Linux it is still surprisingly much smaller than electron, but it is a consistent environment.

When initializing a GPU context you can specify whether you want the most efficient device, the fastest device, etc, for a GUI app then you would want to pick the most efficient, which is a single flag to pass in, or supply options and let the user pick which one they want.

Which is what Tauri uses.

This sounds awesome! I hope you post it here!

Rust actually has a library with very good flutter integration, it does require using dart for the actual flutter part though, but it works well together.

Rust may give a subset of file system functionality that all general file systems should in theory support in the front interface, but you can access platform specific functionality by asking for the extended interface, which you put inside a platform check block. You have the full functionality there.

Is the Rust FFI story much better?

So very much so. All the usual C types are available, you even have as much control as even saying that you want to struct laid out as it is in C, doing something as simple as binding a function is just declaring the function like you would in C. As it uses llvm it can even inline across C code, optimize and all just like they were written in the same language if you wish to do that.

Honestly curious, but of all the things I've heard people say about QT it could never be about poor performance, it's generally consistently regarded as the fastest complete GUI toolkit out. Even more so because the Linux desktop environment KDE is built in it and is consistently shown to be both the fastest and lowest memory of near all Linux desktop environments (and certainly among all the big ones), including ones designed to be fast and low memory. Where did this poor performance thing come from and am I missing something lately?

More likely, I would wager that they were just overwriting the instructions to draw with new instructions that just inline everything so it didn't need to fetch out to anything.

Or rather RAII, borrow checker is a different feature that is not related to garbage collection

Things like the borrower checker helps manage all resources, a GC only manages memory.

I always go back to this: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

What are you referencing on that page that is memory and safe, the program panicking when attempting to access invalid memory is one of the safety features, it means you have a programming error that you need to correct and it is bailing right now to prevent anything bad from happening.

Wait, is this why my tap to pay mysteriously stopped working in the past few months on my Pixel 4?!

Just as a bit of counterpoint, I'm still running the same hardware right now as I was 12 to 15 years ago with KDE3, nowadays KDE5 is so much faster than KDE3 ever was. Yes I need to upgrade badly, yes I was planning to just a few months ago, but prices seem a bit crazy now, so I'm still continuing with my ancient but somehow still operational hardware.

Playing a bit of devil's advocate, erlang is more reliable with more nodes by its design because it is expecting hardware to fail, and when that hardware does fail it migrates the functionality that was running on it to another node. With only a single node then you have a single point of failure, which is the antithesis of erlangs design.

Didn't try the other links but the jsfiddle link just says Preparing worker in Firefox here and neither button ever does anything.

As a developer however, nvidia's closed source drivers are buggy as hell. The amount of issues and times they break the spec is astounding and a constant annoyance. AMD and Intel via the open Mesa drivers are blissful in comparison, plus the amazing debuggability.

Loving it, but it's very slow on refresh on Linux over ssh as well. Looks like it's doing full screen refreshes on every change instead of just using delta's that tui apps should be doing.

Honestly when I look to rewriting a python thing to be 'faster' either try using PyPy first, or rewrite it in OCaml instead. OCaml is extremely simple, similar to python in a lot of ways (GIL and all), but runs at native code speeds, near C the majority of the work, and super easy to bind to C libraries if you need.

Or try Rust. ^.^