| |
| ▲ | rienbdj a day ago | parent | next [-] | | > One of the biggest knocks against Rust as a systems programming language is that it has weak compile-time and metaprogramming capabilities compared to Zig and C++. Aren’t Rust macros more powerful than C++ template metaprogramming in practice? | | |
| ▲ | menaerus 16 hours ago | parent | next [-] | | No, they are not. | | |
| ▲ | aw1621107 15 hours ago | parent | next [-] | | They are both; there are things that Rust's macros can do metaprogramming-wise that C++ templates cannot do and vice-versa. Rust's macros work on a syntactic level, so they are more powerful in that they can work with "normally" invalid code and perform token-to-token transformations (and in the case of proc macros effectively function as compiler extensions/plugins) and less powerful in that they don't have access to semantic information. | |
| ▲ | aldanor 12 hours ago | parent | prev [-] | | Incorrect. |
| |
| ▲ | tialaramex a day ago | parent | prev [-] | | Rust has two separate macro systems. It has declarative "by example" macros which are a nicer way to write the sort of things where you show an intern this function for u8 and ask them to create seven more just like it except for i8, u16, i16, u32, i32, u64, i64. Unlike the C pre-processor these macros understand how loops work (sort of) and what types are, and so on, and they have some hygiene features which make them less likely to cause mayhem. Declarative macros deliberately don't share Rust's syntax because they are macros for Rust so if they shared the same syntax everything you do is escape upon escape sequence as you want the macro to emit a loop but not loop itself etc. But other than the syntax they are pretty friendly, a one day Rust bootstrap course should probably cover these macros at least enough that you don't use copy-paste to make those seven functions by hand. However the powerful feature you're thinking of is procedural or "proc" macros and those are a very different beast. The proc macros are effectively compiler plugins, when the compiler sees we invoked the proc macro, it just runs that code, natively. So in that sense these are certainly more powerful, they can for example install Python, "Oh, you don't have Python, but I'm a proc macro for running Python, I'll just install it...". Mara wrote several "joke" proc macros which show off how dangerous/ powerful it is, you should not use these, but one of them for example switches to the "nightly" Rust compiler and then seamlessly compiles parts of your software which don't work in stable Rust... |
| |
| ▲ | jesse__ a day ago | parent | prev | next [-] | | > powerful compile-time and metaprogramming capabilities While I agree that, generally, compile time metaprogramming is a tremendously powerful tool, the C++ template metaprogramming implementation is hilariously bad. Why, for example, is printing the source-code text of an enum value so goddamn hard? Why can I not just loop over the members of a class? How would I generate debug vis or serialization code with a normal-ish looking function call (spoiler, you can't, see cap'n proto, protobuf, flatbuffers, any automated dearimgui generator) These things are incredibly basic and C++ just completely shits all over itself when you try to do them with templates | | | |
| ▲ | sidkshatriya 20 hours ago | parent | prev [-] | | One of the biggest knocks against Rust as a systems programming language is that it has weak compile-time and metaprogramming capabilities compared to Zig and C++ In the space of language design, everything "more powerful" is not necessary good. Sometimes less power is better because it leads to more optimisable code, less implementation complexity, less abstraction, better LSP support. TL;DR More flexibility and complexity is not always good. Though I would also challenge the fact that Rust's metaprogramming model is "not powerful enough". I think it can be. | | |
| ▲ | germandiago 19 hours ago | parent [-] | | But compile-time processing is certainly useful in a performance-oriented language. And not only for performance but also for thread safety (eliminates initialization races, for example, for non-trivial objects). Rust is just less powerful. For example you cannot design something that comes evwn close to expression templates libraries. | | |
| ▲ | ux266478 15 hours ago | parent | next [-] | | > And not only for performance but also for thread safety This is already built-in to the language as a facet of the affine type system. I'm curious as to how familiar you actually are with Rust? > Rust is just less powerful. On the contrary. Zig and C++ have nothing even remotely close to proc macros. And both languages have to defer things like thread safety into haphazard metaprogramming instead of baking them into the language as a basic semantic guarantee. That's not a good thing. | | |
| ▲ | germandiago 9 hours ago | parent [-] | | Writing general generic code without repetition for Rust without specialization is ome thing where it fails. It does not have variadics or so powerful compile metaprogramming. It does not come even remotely close. Proc macros is basically plugins. I do not think thos is even part of the "language" as such. It is just plugging new stuff into the compiler. |
| |
| ▲ | aw1621107 17 hours ago | parent | prev [-] | | > For example you cannot design something that comes evwn close to expression templates libraries. You keep saying this and it's still wrong. Rust is quite capable of expression templates, as its iterator adapters prove. What it isn't capable of (yet) is specialization, which is an orthogonal feature. | | |
| ▲ | Conscat 16 hours ago | parent | next [-] | | Rust cannot take a const function and evaluate that into the argument of a const generic or a proc macro. As far as I can tell, the reasons are deeply fundamental to the architecture of rustc. It's difficult to express HOW FUNDAMENTAL this is to strongly typed zero overhead abstractions, and we see where Rust is lacking here in cases like `Option` and bitset implementations. | | |
| ▲ | aw1621107 16 hours ago | parent [-] | | > Rust cannot take a const function and evaluate that into the argument of a const generic Assuming I'm interpreting what you're saying here correctly, this seems wrong? For example, this compiles [0]: const fn foo(n: usize) -> usize {
n + 1
}
fn bar<const N: usize>() -> usize {
N + 1
}
pub fn baz() -> usize {
bar::<{foo(0)}>()
}
In any case, I'm a little confused how this is relevant to what I said?[0]: https://rust.godbolt.org/z/rrE1Wrx36 |
| |
| ▲ | menaerus 16 hours ago | parent | prev [-] | | > Rust is quite capable of expression templates, as its iterator adapters prove. AFAIU iterator adapters are not quite what expression templates are because they rely on the compiler optimizations rather than the built-in feature of the language, which enable you to do this without relying on the compiler pipeline. | | |
| ▲ | aw1621107 15 hours ago | parent [-] | | I had always thought expression templates at the very least needed the optimizer to inline/flatten the tree of function calls that are built up. For instance, for something like x + y * z I'd expect an expression template type like sum<vector, product<vector, vector>> where sum would effectively have: vector l;
product& r;
auto operator[](size_t i) {
return l[i] + r[i];
}
And then product<vector, vector> would effectively have: vector l;
vector r;
auto operator[](size_t i) {
return l[i] * r[i];
}
That would require the optimizer to inline the latter into the former to end up with a single expression, though. Is there a different way to express this that doesn't rely on the optimizer for inlining? | | |
| ▲ | menaerus 14 hours ago | parent [-] | | Expression templates do not rely on optimizer since you're not dealing with the computations directly but rather expressions (nodes) through which you are deferring the computation part until the very last moment (when you have a fully built an expression of expressions, basically almost an AST). This guarantees that you get zero cost when you really need it. What you're describing is something keen of copy elision and function folding though inlining which is pretty much basics in any c++ compiler and happens automatically without special care. | | |
| ▲ | aw1621107 14 hours ago | parent [-] | | > since you're not dealing with the computations directly but rather expressions (nodes) through which you are deferring the computation part until the very last moment (when you have a fully built an expression of expressions, basically almost an AST). Right, I understand that. What is not exactly clear to me is how you get from the tree of deferred expressions to the "flat" optimized expression without involving the optimizer. Take something like the above example for instance - w = x + y * z for vectors w/x/y/z. How do you get from that to effectively for (size_t i = 0; i < w.size(); ++i) {
w[i] = x[i] + y[i] * z[i];
}
without involving the optimizer at all? | | |
| ▲ | menaerus 2 hours ago | parent [-] | | The example is false because that's not how you would write an expression template for given computation so the question being how is it that the optimizer is not involved is also not quite set in the correct context so I can't give you an answer for that. Of course that the optimizer is generally going to be involved, as it is for all the code and not the expression templates, but expression templates do not require the optimizer in the way you're trying to suggest. Expression templates do not rely on O1, O2 or O3 levels being set - they work the same way in O0 too and that may be the hint you were looking for. |
|
|
|
|
|
|
|
|
| |
| ▲ | ozgrakkurt a day ago | parent [-] | | returning "impl Trait". async/await unpin/pin/waker. catch_unwind. procedural macros. "auto impl trait for type that implements other trait". I understand some of these kinds of features are because Rust is Rust but it still feels useless to learn. I'm not following rust development since about 2 years so don't know what the newest things are. | | |
| ▲ | tialaramex 21 hours ago | parent | next [-] | | RPIT (Return Position impl Trait) is Rust's spelling of existential types. That is, the compiler knows what we return (it has certain properties) but we didn't name it (we won't tell you what exactly it is), this can be for two reasons: 1. We didn't want to give the thing we're returning a name, it does have one, but we want that to be an implementation detail. In comparison the Rust stdlib's iterator functions all return specific named Iterators, e.g. the split method on strings returns a type actually named Split, with a remainder() function so you can stop and just get "everything else" from that function. That's an exhausting maintenance burden, if your library has some internal data structures whose values aren't really important or are unstable this allows you to duck out of all the extra documentation work, just say "It's an Iterator" with RPIT. 2. We literally cannot name this type, there's no agreed spelling for it. For example if you return a lambda its type does not have a name (in Rust or in C++) but this is a perfectly reasonable thing to want to do, just impossible without RPIT. Blanket trait implementations ("auto impl trait for type that implements other trait") are an important convenience for conversions. If somebody wrote a From implementation then you get the analogous Into, TryFrom and even TryInto all provided because of this feature. You could write them, but it'd be tedious and error prone, so the machine does it for you. | | |
| ▲ | ozgrakkurt 17 hours ago | parent [-] | | Like you said it is possible to not use this feature and it arguably creates better code. It is the right tradeoff to write those structs for libraries that absolutely have to avoid dynamic dispatch. In other cases it is better to give a trait object. A lambda is essentially a struct with a method so it is the same. I understand about auto trait impl and agree but it is still annoying to me | | |
| ▲ | Twey 17 hours ago | parent [-] | | > It is the right tradeoff to write those structs for libraries that absolutely have to avoid dynamic dispatch. In other cases it is better to give a trait object. IMO it is a hack to use dynamic dispatch (a runtime behaviour with honestly quite limited use cases, like plugin functionality) to get existential types (a type system feature). If you are okay with parametric polymorphism/generics (universal types) you should also be okay with RPIT (existential types), which is the same semantic feature with a different syntax, e.g. you can get the same effect by CPS-encoding except that the syntax makes it untenable. Because dynamic dispatch is a runtime behaviour it inherits a bunch of limitations that aren't inherent to existential types, a.k.a. Rust's ‘`dyn` safety’ requirements. For example, you can't have (abstract) associated types or functions associated with the type that don't take a magic ‘receiver’ pointer that can be used to look up the vtable. | | |
| ▲ | ozgrakkurt 16 hours ago | parent [-] | | It takes less time to compile and that is a huge upside for me personally. I am also not ok with parametric polymorphism except for containers like hashmap |
|
|
| |
| ▲ | mattstir 21 hours ago | parent | prev [-] | | Returning impl trait is useful when you can't name the type you're trying to return (e.g. a closure), types which are annoyingly long (e.g. a long iterator chain), and avoids the heap overhead of returning a `Box<dyn Trait>`. Async/await is just fundamental to making efficient programs, I'm not sure what to mention here. Reading a file from disk, waiting for network I/O, etc are all catastrophically slow in CPU time and having a mechanism to keep a thread doing useful other work is important. Actively writing code for the others you mentioned generally isn't required in the average program (e.g. you don't need to create your own proc macros, but it can help cut down boilerplate). To be fair though, I'm not sure how someone would know that if they weren't already used to the features. I imagine it must be what I feel like when I see probably average modern C++ and go "wtf is going on here" | | |
| ▲ | andriy_koval 15 hours ago | parent | next [-] | | > Reading a file from disk, waiting for network I/O, etc are all catastrophically slow in CPU time and having a mechanism to keep a thread doing useful other work is important. curious if you have benchmarks of "catastrofically slow". Also, on linux, mainstream implementation translates async calls to blocked logic with thread pool on kernel level anyway. | |
| ▲ | ozgrakkurt 17 hours ago | parent | prev [-] | | Impl trait is just an enabler to create bad code that explodes compile times imo. I didn’t ever see a piece of code that really needs it. I exclusively wrote rust for many years, so I do understand most of the features fair deeply. But I don’t think it is worth it in hindsight. |
|
|
|
