15 ms·
Trait objects are still no replacement for the areas in which subtype polymorphism excel, and Rusts' generics are a pittance compared to the completeness and ex
by moth-fuzz 5y ago
Trait objects are still no replacement for the areas in which subtype polymorphism excel, and Rusts' generics are a pittance compared to the completeness and expressiveness C++ templates. I know that sounds like flamebait, and yes I've read STL source code in all its underscored and abbreviated glory, and yes I've read that one snippet of the std::ranges proposal that people like to throw around. But the thing that always gets me is that most Rust proponents I've talked to simply define out of the equation Rust's problem areas - an oft-repeated mantra is that Rust 'pushes you to a good design' as if what is inherently a good design are what Rust is capable of and the areas it is less so are simply inherently poor designs anyway.
Sure you can do everything you'd want to do in C++ in Rust, but the developer experience when actually writing code is agonizing most of the time. I deeply miss C++ templates in most other languages, excepting fully dynamic languages, and D. Rust is, to me, more of a replacement for places I'd write C, and be in a C mindset. C++ (well-written, modern C++) is so much more than C, and so much more than people give it credit for. A true C++ contender would have to pass not just the C bar but the C++ bar as well, rather than looking at C++'s strengths over C and saying "actually those are bad things" like it's been popular to do for the last 10 years.
Speaking of replacing C, Rust is not without its strengths: the one place I find Rust truly a joy to write is OS dev, and similar low-level projects, in which the concepts and limitations of the language map to quite nicely to the expectations of the system. It seems like the obvious candidate for these types of applications (including embedded development) but there's little surrounding literature - it always baffles me that most people seem to be using Rust to write ... web services?
- fhd2 5y ago> it always baffles me that most people seem to be using Rust to write ... web services? I think it's the whole x-rewritten-in-rust-now-faster hype train. Although those limitations you mention, what's easy and hard to do, do have a more or less automatic impact on performance, fueling that train. I think of it like this: Programmer level 1: Makes something work in a higher level language Programmer level 2: Makes something work in a lower level language Programmer level 3: Makes something fast in a lower level language (in most cases just a few simple optimisations on top of #2) Programmer level 4: Makes something fast in a higher level language (object pooling, understanding how the GC and VM works to avoid GC pauses at the wrong time and all that) So with Rust (or yes, C++, though it's a bit more of a foot gun IMHO), level 2/3 people can write code that's efficient. What I think is somewhat unique about Rust is that it keeps programmers from making lots of common mistakes working with lower level languages - like it's designed for level 1/2 folks.
- natded 5y agoWriting web-services in Rust is easy and I don't understand the OP's confusion about it. Web-services are highly concurrent and benefit from async, both of which are areas where Rust excels at - and Rust looks like JavaScript most of the time when writing these so it is pretty clear what to do here if you need scale and performance. Then there's the plethora of other advantages you get from its great type system and inference etc.
- flooow 5y agoI agree completely, it's a very strange objection - Rust is one of the very best languages for web servers. I wish I could use it at work instead of Django. I think some C/C++ devs take a perverse pride in their language not being suitable to write web servers, because webdev is not real programming anyway (excepting the 'systemsy' parts like nginx). Well, Rust is great at systems, great at web servers, pretty good at one-off script, even pretty usable for frontend. Every time I hear someone pigeonhole it as just a systems language, I think - you're missing out.
- moth-fuzz 5y agoIt definitely wasn’t meant as a criticism - I think Rust is uniquely suited to writing web applications as well. I just find it funny that writing web apps is easy enough in Rust that it almost minimizes its opinionatedness, since you don’t really need to worry about difficult lifetimes or ownership when it’s JSON in, JSON out, and the database is just an externality, and you don’t have hard performance requirements despite Rust being made for performance. It seems like an impedance mismatch but it works out.
- choeger 5y agoYou shouldn't compare C++ templates to Rust polymorphism. The latter is decidable, the former is not. Compare C++ templates to Rust macros. Btw. Who likes C++ templates? They are such a roundabout way to program the compiler that it regularly hurts me. You need to understand a set of arbitrary rules (steered by implementation of the existing compilers, not language design, it seems) to make the compiler do what you want in many lines of code. And only fellow template lovers will have a chance to understand your intention. It is admittedly powerful, but compared to any decent macro implementation (Lisp, Haskell, OCaml, Rust) it is so much worse...
- salicideblock 5y ago> Btw. Who likes C++ templates? Saying I like them is a stretch, but I prefer to write a C++ template rather than a macro (C++ or Rust) any day.
- mlindner 5y agoC++ macros are completely unlike Rust macros so lumping them together makes no sense.
- edflsafoiewq 5y agoTemplates are not very much like macros. You cannot perform a syntactic rewrite at the point of instantiation that replaces the template use, and they are integrated into the semantics of eg. overload resolution in a way syntactic macros obviously can't be. I don't see why decidability should render them incomparable.
- choeger 5y ago> they are integrated into the semantics of eg. overload resolution in a way syntactic macros obviously can't be. Exactly, they are macros that can only be invoked via some weird implicit entry points. Proper macros could be used very much in the same way, of course, if the compiler recognizes their output correspondingly. You could, for instance, use macros to generate traits/type classes to enhance overloading. Why someone would prefer this code generation to be so implicit, I don't understand. > I don't see why decidability should render them incomparable. Of course you can compare them if you want to point out that particular difference. But if you claim that templates are more powerful, the obvious answer is: Sure, because they're not type safe. Templates simply aren't a type system extension, they're more like macros.
- imron 5y ago> compared to the completeness and expressiveness C++ templates. The error messages in particular - so very expressive.
- berkut 5y agoDefinitely for prototyping, as someone with years of 'advanced' C/C++/Python experience, and someone trying to learn Rust, I'm finding Rust's 'opinionated' ways of doing things very painful for things like fast prototyping, where you need to impl 'default' traits on structs, or create builders (which is almost as bad as C/C++'s split of declaration and implementation in that you have tightly-coupled things in different parts of the code.), sticking unwrap() everywhere to not handle all errors correctly at this stage, etc, etc. i.e. you don't really know what you want, seeing what works, how the data could be organised, refactoring in the early stages, and so much is in flux at this stage, the compiler's warning about all sorts of things, but I don't want to fix them as it might be a waste of time at that stage if you change things yet again, so just end up shoving: #[allow(dead_code)] above all enums or something, so I can actually see errors within all the warnings. Once you move past the prototyping stage on to full on production coding, I totally buy that in a lot of cases, the safety that Rust provides (if it compiles, it will almost certainly either panic or work, ignoring logic bugs), is a big win, but I'm not convinced yet for experimentation when prototyping...
- littlestymaar 5y agoI personally love Rust for prototyping for one particular reason: even if it's not as quick as what you'd do in dynamic languages (JS for me, for most people it would be Python) it comes with an enormous benefit: iterating on your prototype several times until you eventually reach the final version is much, much quicker than in any other language I know, simply because the compiler will catch almost any mistakes you make during your refactoring. So, The first draft is going to take like twice as long, but every subsequent iteration on your prototype will be much faster. I find the payoff time to be pretty quick (like one or two iteration are often enough), but obviously if you're doing a true one-shot that you're never gonna touch again, it won't be worth it (that being said in my experience, such situations are pretty rare and most one-shots end up being way more than what they where supposed to in the first place).
- berkut 5y agoYou can argue that (and I'd generally agree in most cases above a certain complexity size) about dynamic vs any static language though?
- kitd 5y agoI deeply miss C++ templates in most other languages, excepting fully dynamic languages, and D. Have you tried Zig? Comptime templating it one of its selling points. https://ziglang.org/documentation/0.8.1/#comptime https://ziglang.org/documentation/0.8.1/#comptime
- moth-fuzz 5y agoI loooove Zig - my only gripe with Zig is that it feels somewhat arcane at times, and the documentation was borderline absent last I checked. I follow Andrew Kelley on twitter and am fascinated by his exploits. Crystal has a similar macro system that I enjoy, from what I've used of it. Rust macros are similarly satisfying in what you can accomplish with them, but the implementation is so immeasurably difficult, it's almost never worth it to bother, from a general design standpoint. As far as C replacements go, Zig has my vote for the most approachable but also the most well thought-out. I couldn't sing its praises enough.
- lenkite 5y agoWould love Zig if it had RAII.
- AndyKelley 5y agoRAII works fine in Zig
- lenkite 5y agoNo it doesn't. https://github.com/ziglang/zig/issues/782 https://github.com/ziglang/zig/issues/782
- AndyKelley 5y agoshow me a raii code example in C++ and I'll show you the zig equivalent
- 5y ago
- ReleaseCandidat 5y ago> the one place I find Rust truly a joy to write is OS dev, and similar low-level projects That's what Rust actually is useful for. And what C++ should have been used for. It has grown in the abomination it is, because the people (well, yes, me too ;) abused it as language for 'everything'. I do actually fear that the same will happen to Rust. Btw. most people use Rust to write web services because most people actually write web services ;)
- natded 5y agoSubtyping is mostly a bad idea so losing that doesn't matter.
- forrestthewoods 5y agotemplates are definitely more powerful than Rust generics. And "enterprise" Rust code can easily become so infested with traits it's as unreadable as C++ template spaghetti. STL is a special level of unreadable. But "enterprise Rust" might be worse than "enterprise C++" at times. I am curious, what are some actual things you have done with templates that you couldn't do with generics? I'm pretty firmly in the camp of "most of C++'s strengths over C are bad". So I'm struggling. I'd maybe possibly say C++ templates are better for math? Which is true. Rust generics are not great for complex math. However eigen is nightmare monster that absolutely ruins my compile times so I'm not sure whether this counts as a win or loss for templates. Maybe a bit of both. Rust is still duper bad at UI. Even if there are some imgui-like Rust libraries doing cool things. I've never seen a C++ GUI library that didn't suck horribly. But at least it was possible.
- pjmlp 5y agoTraits, macros and crate features actually.
- hannofcart 5y agoI think you're right in the power and expressiveness of C++ templates and in how "modern C++" is a joy to code in but I suspect you have the privilege of working in a codebase that does not have much legacy C++ that you have to maintain. Most large C++ codebases that have been running in production over decades are unfortunately a Frankenstein's monster written in a mix of old style C with classes C++ code full of malloc and free footguns, heavily OOP driven prefer-inheritance over composition era code full of virtual destructor footguns, and the modern nicer RAII std::unique/shared_ptr memory management based C++ code. And a lot of template and macro magic thrown in across each of those eras. So you can get really productive in modern C++ pretty quickly and it can be an enjoyable experience. But to maintain a large old C++ codebase you are going to have to grok a lot of stuff. So much that I really can't find too many people who can hold it all in their head. I certainly can't. Finally, am not sure if there was a hint of derision about Rust being primarily used for web services but I think it's a great thing if the next generation of web services will be developed in something as efficient as Rust rather than more resource hungry counterparts like Python or JS. Good for the balance sheet. Good for the environment. Good for the web devs who get expressive easy to understand code with a lot of guard rails built in.
- pjmlp 5y agoUntil Rust gets the compilation story sorted out, what you save on the computer center gets spent in developer workstations.
- pas 5y agoDo you mean compile time? > what you save on the computer center gets spent in developer workstations. um, that cat is already out of the bag. unless you work on mobile or web frontend most backends are big, ugly, have a lot of dependencies, running them needs ALL the RAM anyway :)
- rapsey 5y agoC++ is slow as well.
- 5y ago