I did the first #chess board render with my #RustLang chess engine :o I'm really happy with how it turned out. And it also shows that the white kingside castling worked xD (Assets from itch.io)
Finally, some progress on my card game! I was able to finally reach a point when it is more feature complete than previous iteration written a few years ago with different framework (quicksilver, it's dead now) 😅 #gamedev#indiedev#rustlang#bevy#bevyengine
Proc macros in #Rust are objectively bad in a number of ways (limited to only dealing with tokens/no type system access, hard for newcomers to grasp and write, force a lot of attributes to be written to annotate specific items, etc.) but they exemplify "worse is better" perfectly. They are incredibly powerful and allow people to build amazing abstractions that are in some cases best in class. We want to have something better, but there isn't a pressing need now to rush a replacement. #RustLang
I'm glad that #Rust is now at a stage where there aren't any major missing pieces, almost anything you want to do can be represented, just in round about ways and sharp corners that we can chip away in time. Better than the situation years ago where most people used nightly exclusively because there was missing functionality in stable. We still need a way to have "stable early access" for features close to completion, though. #RustLang
@ekuber They are far better than C macros that have no restrictions on input or output. That’s not to say things can’t be better, but how could this even work? So much type information isn’t available without expanding macros recursively already, then you need to resolve dependencies and compile. You have a chicken or the egg problem then.
My biggest gripe is that proc-macros2 is still necessary and knowing when I have to convert types between that or the extern’d proc_macro types. #rustlang
As part of our ‘domain' #DNS library project, we are including diagnostics tooling. Instead of simply reimplementing ‘dig' in #rustlang, we wanted to rethink what operators would want from such a command line tool. Today, we're happy to release version 0.1.0 of ‘dnsi’. https://crates.io/crates/dnsi
@sophiajt just introduced #June: an systems language that is easier to use and learn, possibly quite interesting for application development. Will supposedly have #RustLang interoperability. Very interesting!
@diyelectromusic, since you're into embedded tech and microcontrollers, you may appreciate this one.
It's a Real-time Operating System kernel I wrote in C and Assembly for AVR chips. My intent was to learn about how operating systems interface with hardware.
I'd like to rewrite it with #Rust and finish the task scheduler.
Hmm… I guess I could probably write a blog post about how my quest to speed up regexp matching in a #ruby Rake task led me eventually to #rustlang and how it worked in the end… 💎🦀🤔
So now that -Zcheck-cfg is stabilized and enabled by default, there's no way to tell the compiler about custom cfgs other than a build script?
I routinely use a custom cfg for rustdoc so that I can use nightly features when publishing (both with docs.rs and CI). #[cfg(coverage)] is also used in some places.
Apparently spurious warnings are extremely wide-spread, so I'm not clear on why this was stabilized with such a glaring hole in it.
I came across this article the other day, titled “Why Rust cannot replace C++”.
I feel that the author completely fails to understand the opposing argument. The article claims that with “new” C++ features like smart pointers, you can write safe code in C++, therefore Rust is unnecessary.
But I don’t want a language where I can write safe code, I want a language where I must write safe code.
There’s this common statement that “the cognitive overhead of working with the borrow checker just isn’t worth the security benefits when you can write safe code in other languages”.
But the comparison is always to the “cognitive overhead” of writing something in some other language. When the comparison should be to writing something correctly in some other language.
Sure, it’s much easier to pass pointers (*, &, or shared_ptr) around, but now I have the “cognitive overhead” of ensuring that it’s only accessed from one thread at a time. Or not used after it’s been freed in the former cases.
When I’m working with the borrow checker that is something that I don’t have to think about. It’s less “cognitive overhead”.