Comments by "George Albany" (@Spartan322) on "ThePrimeTime" channel.

  1. Especially C++20, concepts absolutely fix the template problems way too well,, shame that modules still don't work properly on any compilers though.
    26
  2. Lot of people forget that C++ is second to none with performance against safety, its safety is opt-in but heavily advised while being a trivial interop with C, I don't see anything supplanting that functionality for the simple fact that C++ provides something that literally does not exist anywhere else.
    24
  3. Most people that complain about security problems don't actually understand security in my experience, granted I'm not great with it either, but there are people I know personally who do know security because they work in high risk engineering environments, (like aeronautics and defense) they still use C and C++, most of them preferred C++, and I've been told a few times they'll never switch to something like Rust. Its quite likely the Rust developers don't actually understand security either and haven't actually worked in a field where security is vital. When the US government starts imposing something technical, its usually because it completely misunderstood the problem and developed the worst fix possible to said problem. They do it repeatedly in defense contracting and I know of people who've directly suffered and died of such things in the military.
    21
  4. I've experienced a number of cases where that happened with MSVC as well, I'm not sure there is any compiler that doesn't suffer from it.
    10
  5. Honestly C++20 concepts and constraints solve the metaprogramming issue completely by erasing the compile time type while preserving a type contract, and the compiler flat out tells you why something failed, it can also perform constraint overloading and allows you to perform compile-time conditional type introspection with if constexpr, all major compilers support most of the major C++20 concept feature set (least that matters) and as someone who has personally used it in a codebase with excessive template metaprogramming its been a godsend to protect the templates from massive nonsense statements of problems I have no way to understand, and even better it gives you a clear understanding of how a template works from an interface perspective. Next thing I'm waiting for is properly functioning modules in all major compilers.
    8
  6. Honestly I despise a lot of the Rust community, it doesn't serve an original purpose, it co-opts the purposes of other languages, sometimes without good justification compared to the alternatives, and then it gets injected everywhere like "replace everything with Rust" no matter how unsuitable it would be for that. Aside from despising the language for numerous reasons (its ideas are nice, but its implementation is the worst way you could've done it) the community is absolutely horrible for Rust, I've been in regular non-rust programming places, but as soon as you criticize Rust for anything, they absolutely lose their crap and call you names. I can't stand Rust, and even more I can't stand its community, its no wonder its representatives are so crap.
    7
  7. I hate Rust's syntax as a hobbyist in syntax design and parser development, you could not have made a much worse language syntax then Rust, Lisp makes more sense. Rust has interesting ideas, but I can't see a good reason to use it over C++, every protection it has can be just as well handled in C++ since C++11, C++ has been capable of memory safety since C++98, the problem is people keep assigning C programmers to C++ and then you're surprised when they open the C memory hole? We've had static analyzers for years telling people to stop doing that, and Rust has plenty of holes in its "sound type system" that people will abuse just the same as they did in C once anyone becomes competent in it, with competence mixed with time and performance constraints always brings a lack of safety even in "safe" code. "Safe Rust" can still perform buffer overflows and people will eventually rely on the existence of that behavior too. Course they might also just completely disregard "Safe Rust" which inherently produces bugs because it is impossible to understand Rust's overprotective behavior well enough to account for it in unsafe code, its the same as just writing straight C, all you did was move the problem down the line, if you keep pushing C developers over to Rust, and they keep struggling with the borrow checker, lifetimes, and the traits system to do even simple things people will just do what they did in C and C++ and disable the safety checks because they got in the way, and now you just fell right back to square one except now you get to claim "memory safety". That aside the ability to write and read the syntax easily determines the maintenance cost, Rust is not a maintainable language because of its verbosity, I don't foresee anyone wanting to keep any legacy Rust, (its enough of a pain maintaining legacy C when its readable, now imagine legacy Rust) which makes it questionable to try and replace C with, at least Zig is better for this.
    7
  8. Can also determine if you're in a consteval state of the function now too.
    6
  9.  @ThePrimeTimeagen  Not if you don't need the atomic counter, weak references should only be used when you absolutely need the atomic reference counter.
    6
  10. Thing is the elimination of UB as a concept kinda misunderstands why it exists in the first place, it exists so you know what the software promises to do, its just a contract, and its a useful contract for optimization, C is ubiquitous specifically because of this, I think the writer of this article grossly misunderstands that C evolving as the a multi-platform language is what inherently allowed every other language following it to exist. If I have to write C, I'd like to have a linter inform me about UB, then I can choose when and when not to use it. (as I do in fact take advantage of UB even in C++ because it actually is a very useful tool) Cool thing about UB is that you can access implementation defined behavior that transcends a library, reaching the hardware, which is all on its own useful functionality too. (like messing with the vtables, there are no vtables in C++, their existence is completely implementation defined so any way to access them is inherently UB) Personally I'd prefer if we could have optional UB, the core standard has no UB but then the standard requires the standard machine to disable certain defined behavior that it deems useful without having to modify the language, this is definitely a gripe I have with the "no UB" languages because they treat UB as if it never served a purpose instead of only being poorly implemented. Even more helpful if we had categories of UB.
    6
  11. @joseoncrack Been doing C++ for over a decade, still prefer it to anything else, though I do wish it were better but that's just cause everything else sucks.
    5
  12. You're talking to one right now, I hate Rust and don't find Zig compelling, and I'll always love C++ over C. I also spend some of my free time reading the C++ proposal papers for fun.
    5
  13. Not everything in the kernel needs speed, but as for those that do, Rust actually will almost never be preferred.
    5
  14. If you know how to use RAII, it protects you from memory leaks by forgetting to free the memory because you returned in an unexpected place.
    5
  15. Not to mention since C++11 its been very memory safe, (technically auto_ptr was C++98, RAII was capable to do it since at least C++98, but good inbuilt smart pointers have been in C++ since C++11) and when you have spans and ranges/range-views and C++23's adding things like out_ptr and inout_ptr negating the need to manually manage memory even with C functions, to say C++ can't accomplish the same things as Rust or Zig is just dumb.
    5
  16. public and private functions have nothing to do with security, that's purely about API encapsulation, even if they're private you can still call them
    5
  17. Its the same for their standard library, it seems to me that Rust devs don't understand anything about ABI breakage or API contract violations. Kinda makes me wonder if the "experienced devs" in Rust actually have any real software experience. Or perhaps they're taken hold by some utopian dream of Rust where the common software concerns don't matter completely forgetting that changing a language doesn't fix most of the suffering of software development, most of software suffering is an inherent technology issue.
    5
  18. All move constructors do is swap the data, they never need to allocate, they're literally the fastest way to assign something that isn't immediately constructed, this would be the same in Rust as in C++, copy constructors mostly function for making immutable data or duplicate data you wish to modify, which I might add, you could just use CoW containers and that'll happen automatically only when you modify the data, you can also control allocations better in C++. Also gonna point out, all compilers can optimize objects out just as well as Rust, that's not really a Rust specific thing (technically there are no objects in C++, it also produces glorified strange C binaries) that's kinda inherent to how compilation (to assembly) is supposed to work, and for languages that get compiled to a binary without a bytecode, that's pretty much what always happens. Also you can just disable exceptions in C++ and now you don't need to throw, C++23 is also getting std::expected to enable library ease of use for this case.
    4
  19. I can't think of a case where using modern C++ has ever resulted in losing memory safety that wouldn't have needed to be lost in Rust anyway. Every time I've ever run into this its specifically because I used C over relying on C++.
    4
  20.  @tiranito2834  Doesn't help that move semantics pretty much replicate that behavior in a way that is easier to track and intuitively understand, obviously with the cost of it being less safe, which honestly I'm totally fine with the theoretical lack of safety because it kinda requires deliberate action to cause such problems, and C++ is actually pretty good with move semantics, the annoying thing is duplication of code to write out move semantics for your classes.
    4
  21. I guess you can restrict access to the reflection system, but that requires more work and almost nobody actually does it.
    4
  22. C++ doesn't copy data by default, it depends on the type, if you implement a copy constructor and don't use references, sure it'll probably perform a copy, but move semantics are a natural part of the language and the language will defer to using that which is almost as cheap (and in most cases is just as cheap) as a direct reference. (so long as it has a trivial destructor) Now if you simply make classes and don't use references without a constructor, (and aggregator type) the expectation is that it will try to perform copy construction, unless your types contained in the object are not themselves default constructible in which case that may also not be the case.
    4
  23.  @Resurr3ction  UB tends to fall into one of two big camps, it gets optimized out in some manner, or it does something kinda like what you would expect strangely, it depends on what specific behavior you're asking of the compiler as to what it will do, and there are some manners to actually force UB optimizations, 95% of which are compiler intrinsics (like std::unreachable is implemented via compiler intrinsics and is guaranteed to trigger optimizations that either trap or remove the unreachable case)
    4
  24. Honestly with C++20 and C++23, even going back to C++17, its already immensely safe, if you don't use stick to the C way of doing things, it pretty much solves the same problems as Rust without forcing you into a paradigm that has you wrestling with the borrow checker or the language in general.
    4
  25. The memory security concerns aren't anywhere as significant as people make them out to be either since you can compile the address and data stacks to be distinct places, and even then unsafe memory exploits aren't the most commonly exploited types, so memory safety won't actually negate the exploits in the wild.
    4
  26. @ Rust's desire to mandate runtime costs for memory safety and elimination of undefined behavior prevents a lot of optimizations that make C++ really fast. (granted its fast, one of the faster compiled languages when you don't consider build times, but C and C++ will still have it beat)
    4
  27. @ That which is fast can have safety integrated on top of it, that which is safe can't have speed integrated on top of it, its a one way street, if you need memory bounds checking, you can do it in C++, its always been part of the standard, but majority of the time its not needed/wanted, you don't want runtime bounds checking when you already know the bounds at runtime can't violate, that's a needless waste of performance the compiler is incapable to optimize.
    4
  28. Majority of the time a vector (dynamic array) with a pool, SBO, and/or static buffer are just as good as a fixed size array, unless you have some reason you need to avoid heap allocations.
    4
  29. @rusi6219 Spoken as the lingua franca in much of Europe, East Asia, and even through a large part of the Middle East, its about as universal as can be right now, it has more popularity for communication then French had in the medieval period, which is where we get the very definition of lingua franca from. (its literally in the name)
    3
  30. @ Its formally used and recognized as such in the Philippines, South Korea, Japan, India and China. As well as anywhere that's had moderate internet access for around two decades. And lingua franca literally translates to "language of the Franks".
    3
  31. @ "Removing reachable code is not an optimization. It is arbitrariness." That's objectively false, it absolutely is an optimization.
    3
  32. I don't really get the point of claiming to have a better language when the language will deliberately get in your way for almost everything. I don't like any of these new language syntaxes with the postfix type declarations for example, but at least Zig is actually capable to be a replacement for C, Rust doesn't really do anything better then C++, the ABI is guaranteed to be compatible just as it is in C allowing shared libraries and fast compilations.
    3
  33. I still don't see Rust's borrow checker solving any problems that RAII in C++ didn't solve better. Could've overhauled the concept of RAII instead, the borrow check is simply the worst choice, especially in claiming to be simple, its only "simple" when you don't come against something that makes you have to think about it, systematically RAII is a lot simpler and easier to wrap your head around, and if you want to violate it, you can do so without breaking the language.
    3
  34. That's also C, there are better alternatives in the standard library to scanf for C++ unless you need absolute speed, though there is a library that does what fmt did for printf but for scanf. Its called scnlib, its performance alongside safety should be better then any other alternative.
    3
  35. @ A number of the compile-time safety features also prevent the compiler from properly performing optimizations that are comparatively easy for a compiler to do in C++.
    3
  36.  @thekwoka4707  Its demonstrably still slower then C and C++ in every case, there isn't a single a case where Rust beats C and C++ in performance because Rust makes numerous runtime cost decisions for safety concerns, safety and performance are a tradeoff, if you can't understand that then you don't actually understand any of the languages or anything about language design, and there are plenty of cases where you can't get around that and Rust does not permit you such. I've said nothing untrue, if you don't understand tradeoffs, you aren't a software engineer.
    3
  37.  @yapdog  99% of the time its because people completely ignore the standard, while UB may or may not work in some version of GCC, there isn't a version where lack of UB failed, that's supposed to be one of the reasons for a linter. And that's why I deliberately try to avoid UB unless I am required to use it.
    2
  38. C++ works specifically because you can use C when you need to and then output a C linkable elements using extern "C", so you can use no cost abstractions in C++, like unique_ptr is a no cost abstraction so long as the destructor is trivial and so long as you use the default delete function. There is no reason not to use unique_ptr in such code because it costs you even less then nothing in C-like C++, which honestly you should just be using good C++ practices, but whatever.
    2
  39. @ "It is my program, my responsibility. Nobody dare to remove or omit code I wrote from MY program." Follow the standard and that's guaranteed with the as-is rule. No matter the language if you don't follow the standard, no compiler has the obligation to produce expected results. Its pretty simple and easy to follow the standard so you're without excuse especially when we have linters for this.
    2
  40. @ "Compiler MUST compile every my command, as is. Otherwise it is bad compiler." That's not remotely true in any language. That's only true in an assembler, stop writing in a programming language if you want that.
    2
  41. To be fair, also presumes that you're iterating the list, if you aren't, they aren't as bad, but in most cases when you make a container of elements that isn't like a map/dictionary, you're usually iterating it, hence why lists tend not to be a great container to resort to.
    2
  42.  @minneelyyyy  "Although I do have to disagree with OP, while I do recognize that a lot of memory bugs don't end up being actually able to be exploited, there are a number of actual major exploits that have happened." For some of the big ones sure, but most of the blame for those already lies in legacy support anyway, (in a legacy C syntax too) and Rust wouldn't fix that either. Like had they written those sections in even proper C++98 with RAII, they wouldn't have happened either, Rust wouldn't have solved it anymore then C++ should have, and the reason C++ didn't solve it was because it wasn't written in C++, and you wouldn't have been able to replace it because people still rely on the C functionality as it was written for compatibility. A lot of Rust developers don't understand legacy and maintainable code, what was first written will be relied upon to never change else you will brick systems. and Rust has enough holes in even its "safe" system that it will absolutely be abused to accomplish similar things, its just a matter of people getting good and learning the esoteric things like they did with C++.
    2
  43. Pretty sure its an Option<Box>
    2
  44.  @virgodem  Rust's desire to mandate runtime costs for memory safety and elimination of undefined behavior prevents a lot of optimizations that make C++ really fast. (granted its fast, one of the faster compiled languages when you don't consider build times, but C and C++ will still have it beat) A number of the compile-time safety features also prevent the compiler from properly performing optimizations that are comparatively easy for a compiler to do in C++. That which is fast can have safety integrated on top of it, that which is safe can't have speed integrated on top of it, its a one way street, if you need memory bounds checking, you can do it in C++, its always been part of the standard, but majority of the time its not needed/wanted, you don't want runtime bounds checking when you already know the bounds at runtime can't violate, that's a needless waste of performance the compiler is incapable to optimize.
    2
  45. @ And what if I told you I was in Turkey? What becomes of your argument then?
    1
  46. @ Don't ask fallacious dumb questions and you won't get a smartass answer.
    1
  47. @ That's still not a refutation, you really love your fallacious deflections.
    1
  48. @rusi6219 And how would you respond if I wasn't American?
    1
  49. @ In the former Soviet bloc that be true, but outside that it most certainly isn't.
    1
  50. @ "Yeah, compiler MUST NOT optimize via UB and via removing reachable code, written by programmer." As a C++ developer who has used it to handle optimization, this is a terrible take, it is the only way to take advantage of performance improvements that are per-platform or per-compiler in many cases.
    1