In that case, while you can always try to discuss it on IRLO, realistically speaking the probability of that being implemented is pretty small I'm afraid.
I knew the chance was pretty small, so it’s just a wish. And/or/not would’ve been added a long time ago if it was gonna happen.
Even though I prefer textual and/or/not over symbolic &&/||/!, mixing them is worse. If both of them exist, then everyone has to learn to read both of them. And anyone who contributes to more than one project has to memorize the idiosyncratic preferences of the maintainer.
Rust should not add and/or/not aliases. It has made its choice and should stick with it.
While they’re at it, Rust should get rid of one of the module directory structures, going with either mymod/mod.rs or mymod.rs. I don’t care which choice Rust makes. Just pick one.
It's a pity that I can't have them, but I think you're right. Thank you for helping me figure this out.
This reminds me: if we're breaking backwards compatibility, please go with foo/foo.rs. To me, it's objectively better than mod.rs.
Realistically, I actually think the dual module styles can be helpful. Having an entire folder per module can get ugly fast; and contrariwise, when you have multiple large submodules, it can be extremely nice to have each module self contained in a folder, instead of spilling out into the parent folder. IOW, I don't think either style can be removed without severe damage to old and new projects alike.
How would you handle wanting to have the equivalent of
mod foo {
mod foo { /* … */ }
}
with that file structure? mod is a keyword, so it doesn't apply to foo/mod.rs.
That is the only downside, but I think I'm personally okay with that. I've never seen that module structure before. I can understand people not liking it.
Complete Transformer from scratch using Rust.
Halfway there with a functional Neural Network till now.
Just a matter of understanding the inner workings and math of transformer to implement that too.
Functors! Real functors are a really cool concept, and Rust would benefit from them. Basic mathematical formulas, such as the Fourier transformation, are based on functors. Furthermore, without functors, real monads cannot be implemented in Rust. Monads are one of the coolest features of Haskell.
The Typesignature of a functor is (a -> b) -> f(a) -> f(y)
I prefer if Rust considers the Kotlin creator way, when you do programming in Rust less formal. Rust provides a good diagnostic and ways to fix compilation error, but why instead you can just tell less formal what you need and then Rust compiler can produce a right code?
Having studied Fourier Analysis in Uni and having implemented my own Fast Fourier Transform I have never heard the word "functor" associated with them. So I'm curious, how does an FFT look in Haskell?
Const expressions as generic parameters in function signatures. Eg:
fn concat_arrays<T, const R: usize, const L: usize>(
lhs: [T; L],
rhs: [T; R],
) -> [T; const { R + L }] {
todo!()
}
The typenum and generic_array crates are beautiful achievements, but it shouldn't take so much special notation and recursive type checking to convince the compiler that if l take a length A array and a length B array, with sizes known at compile time, I'd like to allocate a length A+B array for my result. Or that an MxN matrix should be stored as an M*N length array.
Doesn't Rust have something very valuable here that C++ doesn't have? That is: editions and the ability to change the language in a way that allows the community to "break" old code?
It seems that Sean Baxter's circle compiler shows you can do something similar with C++, by enabling new language features with per file # directives, but the people who govern C++ apparently don't want to change the language that much.
I spent about two years trying to use C++ on a new project, before I finally gave up and started learning Rust. If Visual Studio had worked as well the IntelliJ Rust plugin, instead of choking on "2020 modules" and other things, I might still be working on my C++ code...
Would "stable ABI and shared library support" allow one to distribute a closed source Rust library?
I'd like that, but I don't know if the tradeoffs are too costly.
The trouble with that (as it so often is) is interoperability. You still can't break compatibility with the ABI of older versions, nor the "soft ABI" (things like borrowck that may leak across library boundaries). And if the new features don't break anything, then they didn't need to be gated in the first place. In the end, you have a narrow sliver of half-hearted surface-level patches you can apply in a selective, non-breaking way to a language.
It seems like it's a big deal, but not impossible. If you break ABI, then apps that are linked statically are okay, but apps that depended on a shared library will now have a problem. So that would mean if an operating system wanted to provide shared Rust libraries it would need to provide them for every ABI version. That's not great, but it still seems to me like it's better than being stuck unable to improve a programming language for 30 years.