Ja und Nein, denn Rust ist im grunde sicherer aber auch das kommt darauf an wie mensch es umsetzt. Ich vertraue Rust mehr als anderes Coding, ich schau mir die Libs-Daten an.
»Speichersicherheit – Fast 20 Prozent aller Rust-Pakete sind potenziell unsicher:
Nach Angaben der Rust Foundation verwendet etwa jedes fünfte Rust-Paket das Unsafe-Keyword. Meistens werden dadurch Code oder Bibliotheken von Drittanbietern aufgerufen.«
Expand glob imports is an underrated feature of Rust Analyzer. It’s amazing how the black box melts away when you understand what your framework is bringing into scope.
Having beaten Windows .BAT files and FTP into submission on one laptop (thanks #WinSCP) while getting my #TauriV2 app to build for #Android on another, today I will be figuring out how to debug it with #AndroidStudio.
It almost works. I can call #RustLang from the #Svelte GUI, but my custom protocol handlers aren't being called. 🤔 #Tauri
I think there would be still space for systems programming language with a constraint from day zero that it would 1:1 compatible with plain C”s binary layout and memory model:
Roughly just .text, .bss, .rodata and ,data.
No symbol mangling at all.
All the memory safety etc. fancy features would be then designed within exactly those constraints.
#Rust is essentially a derivative of C++ when compiled to binary, which does not really make it a strong competitor for plain #C. It can substitute C in many cases for sure, just like C++ did, but there’s always need for minimal systems programming language, which also looks elegant in binary, not just in source code.
A compiled C program can be quite easily understood with a binary with no debug symbols at all if you understand the CPU architecture well enough. That is, and will be a strong asset for C.
I'm doing a lot of Blender -> Bevy work at the moment, and I needed a way to visually check the resulting texture atlases. Hence this sprite viewer that pulls in the metadata I'm generating via python scripts and Blender.
bevy_inspector_egui on a Resource + the generated information and I can check the animation for any directionality and any animation.
I wrote an overview and sales pitch for #RustLang for my new website: https://www.ncameron.org/rust/ What do you reckon? Does it tell you what you'd need to know if you're curious about Rust, but don't know much about it?
It's often good if secrets are redacted in logs: This avoids accidental publication of a user PIN (or decrypted payload) in bug reports.
On the other hand, it can be useful for a developer to have full and verbatim logs (including secrets) for debugging.
We started work on this, but would like to hear from you. What should we do?
openpgp-card is a Rust client library for using #OpenPGP card hardware security devices.
This version comes with a significantly adjusted API:
The low-level API has been moved to the "ocard" module. At the top level of the crate, more convenient abstractions are now directly available (including PIN handling for cards in KDF mode).
If Cargo gained a [diagnostics] table to mirror the recent #[diagnostic] attribute, what use cases would you have for improving Cargo errors related to your packages?
nother page up on the website, and perhaps the most interesting one: #RustLang training courses! https://www.ncameron.org/training/ There's a bit of detail about the courses I'm planning to offer and I'm really interested to hear what you all think about them (and of course any thoughts on the website design - this is the busiest page yet).
I'm very excited about these courses. I love writing high-performance code and this is really what we all use #RustLang for, right? But coming from managed, high-level languages to Rust means learning a lot about systems and performance engineering. I reckon the performance course will help a lot of folk in that position. https://www.ncameron.org/training/#performance