Nun ja, auch wenn Passkey was gutes ist und von grossen Firmen bereits angeboten im Einsatz ist, fast keine kleinere Firma investiert in die Tools daführ. Dies auch mMn weil sie es als "zu teuer & unnötig" ansehen.
»Chance verpasst – Webauthn-rs-Entwickler hält Passkeys für geplatzten Traum: #Passkey's sollen Anmeldevorgänge sicherer und benutzerfreundlicher machen. Der Entwickler einer #Webauthn-Bibliothek für #Rust sieht das Vorhaben inzwischen als gescheitert an.«
@kubikpixel Ich hab nie wirklich verstanden wieso Passkeys sicherer als Passwörter sein sollen. Hat jemand Zugriff auf mein Gerät dann auch auf den Passkey. Bei Passwörtern nicht. Verliere ich mein Gerät hab ich ein Problem. Irgendetwas hab ich nicht verstanden.
#rust: You cannot create a struct whose default value is larger than the size of your stack. Box::new only moves the object in; Box::default calls new with the result of default (which is stack).
And based on comments in https://github.com/rust-lang/rust/issues/53827, even if I did manage to create such an object, cloning it would also blow away the stack due to stack allocation.
Yuck. This is going to make creating a giant EnumMap very difficult.
@ekuber@bswolf 💯 If unsafe is on the table then core::mem::transmute()/MaybeUninit gives you lots of options, and for any specific context then there's probably a preferred way to get a pointer to treat as a &mut T.
Note that T still has to have certain properties for this sort of stuff to be permissible even in unsafe code. If you can do it with bytemuck, it's OK; if you can't, it's probably UB.
people say "C++ isn't any closer to the metal than #rust is" but what is the memory footprint of returning a Result? in C++ i can pass an out parameter by reference to avoid allocating anything on the stack - how do i do that in rust? is it with a &mut ptr? is it done automatically by the compiler when returning?
@pragprog beta books get you most of the e-book now (sadly, we can’t ship out a new print for every beta!), and each subsequent release as the book advances towards final release. You can also file bug reports and help make the book better.
The first version of this was great! (I was using a tunnel digging algorithm from it for some UI work just the other day) Looking forward to this “Advanced” follow-up. #Rust
@carlton Thank you! The new version is a bit more systems-oriented (trying to cover advanced language topics), but includes quadtrees and there's procgen in the 3rd part - which will be in the 2nd beta.
@herberticus happy to follow where the adventure takes you! Your books have been amongst the best resources I’ve found for opening up Rust. So Thank You! 🎩
That’s often what #rustlang feels like. I started learning C in the late 80s and BASIC before that. Since then I’ve become an expert in several languages and proficient in several others. I’m an experienced #polyglot and though the rust compiler is by far the most helpful - and pushing other compilers to improve - there’s a lot of sharp edges in the grammar itself. Some other polyglots I’m getting into the language agree.
@heaths Nick is part of the project. Of course there's no need not to need to know that. The project takes a stance of allowing the community to take over as much as possible and rely on "social proof" for what the best resource is. This hurts discoverability, but allows for faster iteration on the resources. If Rust was a product from a company, that perf book would definitely be part of the standard site.
@ekuber@heaths Currently my main reason to avoid Box<dyn Trait> stuff is that it does not work with async traits (unless wrapped with ::async_trait::async_trait or equivalent), and most cases I'd need it is dependency injection.
I wonder how to best describe how #RustLang influences design, for better or worse. Here is some rambling...
It makes you avoid cyclical data structures, and you are far more aware of ownership. This makes surprising action at a distance harder. It also makes it more difficult to misuse globals or struct fields as globals just to pass data along to where it is needed no matter how.
Enums turn out to replace dynamic dispatch very often. Inheritance is just gone.
Since dynamic dispatch is uncommon, you might think traits are less common, but they are not, especially default ones. Because they are used to define how generics fit together statically. Generics are interesting as they are highly abstract yet what happens in runtime is very concrete - no action at a distance.
@faassen One thing about traits is that it makes thinking about Rust code closer to how I think about relational databases.
I am reminded of
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
which significantly shaped how I think about problems. Traits + ADTs put you in the same frame of mind.
My expectation: #Rust will replace most other low level languages for relatively low level use cases. For example platform libraries, kernels, OS components, like services etc.
But I also think that a lot of these projects (especially platform libraries) care about that they won't just be able to be used by other Rust code.
Also my expectation: For a lot of these projects, #Meson will replace #cargo, because it just supports more features, and makes integration into an existing system easier.
@lw64 Rust users don't feel the pain of integrating with Cargo — Cargo integrates with Cargo perfectly :)
Cargo vs Meson is like C vs C++. Cargo is used because it's minimal and takes zero effort for most projects. Meson's need for build scripts and support for snowflake projects looks like adding unnecessary complexity, not a feature.
@hrefna The fact that the developers thought "Hey, maybe we should put useful information into error messages" is the best thing about the language. They've done a stellar job with every step of documentation.
This is pretty big news for #rustlang developers. You can use RustRover for FREE for non-commercial scenarios, including hobby projects and open-source.
@blake JetBrains is a professional tools vendor, so our market primarily comprises professionals. This is an excellent option for folks still learning, contributing to OSS, hobbyists, or looking to make a stack shift.
Our goal has been to include as many features in the box, so while we don’t have as many extensions, the features that extensions add are often already in the core products.
We respect people’s choices, so we only ask folks to try it and decide for themselves.
@blake I also think the OSS extensions’ current trajectory is unsustainable, which is why Microsoft has quietly taken over many of the top extensions in the VS Code ecosystem.