|
Top-level
 @scherzog @lina A lot of C++ developer actually hate the language and refuse to use its modern features, but I would be shocked to hear that said by one who does use them. C++ is an evolving language that's trying more and more to leverage compile time safety assertions. Rust is more or less just an extreme application of the same concept: it's better if the compiler can catch your errors. Aren't the kernel developers hostile to anything not C or asm? Linus really hates us C++ devs... 29 comments
@rastilin @scherzog @lina I can readily beat the crap out of a great amount of C code, performance wise, with C++ so I'm not sure what you're measuring there. Look at how a C vs. C++ developer might make a binary tree for example: C++ version is faster and safer. If you want to do build time processing in C you're also stuck with the preprocessor. Maybe the C++ code was crap, or maybe it's something C++ is really bad at...I dunno, but it sounds suspect.  @crazyeddie @rastilin @scherzog @lina Benchmarks like that are ran against theoretically perfect implementations of various algorithms, not whatever a developer would realistically write unless given infinite time and knowledge. Having readily available and well-optimized algorithm and other utility libraries is very helpful, like you say. @mid_kid @crazyeddie @scherzog @lina So the question is also, which language can self-optimize better? I think Rust would beat out C and C++ in these situations. Though I can't be sure. @rastilin @mid_kid @scherzog @lina Entirely possible. C++ uses its type system to help optimize, I'm sure Rust can. I don't know Rust, but it at least has the potential to do things I don't see C++ ever being able to achieve, or at least a long time. Thread safety for example: way back I watched Meyers present his "red/green" stuff that tried...but it was ungainly and nothing came of it. We have other tools to help, but yeah...it's a thing.  @rastilin oh yeah, I remember that one. The C++ code they used was pretty bad, they were writing C++ as if it were Java and taking a bunch of overhead. Expect that C++ is generally between Rust and C in performance (Rust advantage here being not following calling convention that C++ must abide too to just compile, C++ advantage being not taking 6 million years to compile the 24 million lines of the codebase) @Archivist @rastilin @scherzog @lina I feel for the maintainers a bit here. It's already a lot of work. It's the same reason teams are slow to adopt new C++ standards and idioms. @crazyeddie @lina Idk, the person I hear it most from is very much a C++Next fanboy. The usual reactions to any complaints about the language are "ah but C++25/30/40 will address that" and that failing again "skill issue, shoulda used $feature". My biggest problem with C++ is that nothing really pushed people towards the modern helper features so all the old style code remains mainstream. @scherzog @lina Yep. The number of C++ developers who actually get to use modern features of the language is way smaller than the total number of C++ devs. Community members are one thing, but in the field it's all old shit and nobody wants to update for fear the whole house of cards will collapse if some intern flies off the handle using new features they don't understand...you know, because code reviews are in the process but it all just gets checked off. That's how those discussions go @scherzog @lina But whoever said, "Just make it right the first time," had to be pure moron. Doesn't matter the language. An experienced developer has experienced too much failure to think remotely like that anymore. You only think you can write consistently elegant code and designs that always just work is if you've never tried to do it. In ANY language. I'd have a hard time working with a person that said that. I'd be always thinking how stupid they must be. @scherzog @crazyeddie @lina It should be noted that all languages suffer from it will be in the next version. Rust is no difference. Just Rust versioning is not as mainstream; you almost always required to use the newest version and never support 5-10 year old software. Plus Rust the langauge still does not a decent specifications; it is what ever rustc does. Yes there is a movement to fix that but not fast enough. @pinskia @crazyeddie @lina The difference is that in Rust the compiler bugs you to actually adopt the latest best practices with varying degrees of insistence and helpfulness, while in C++ you can go for 20 years without ever even hearing about them. And if you do hear about them chances are that at least one of the developers of the code base is an old curmudgeon who doesn't like the syntax for new features and so you are stuck with (a subset of) C++98. @pinskia @scherzog @crazyeddie @lina > Plus Rust the langauge still does not a decent specifications Could we please stop to use this argument where the arternatives don't have specs either. The language used in the kernel is /not/ ISO C, it's C with GNU dialect. It litteraly took years to make it possible to compile it with clang and it's not possible to compile it with MSVC. Having a spec does help C in the kernel. Rust not having a spec should therfore be a non issue. @pinskia @scherzog @crazyeddie @lina I may have been in the wrong, I didn't know GNU extension where specified. I still don't think that spec are needed, just good documentation.  @robinm @pinskia @scherzog @crazyeddie @lina For a programming language, a specification is actually really important. It resolves ambiguities and also defines where ambiguities are. People argue about undefined behavior problems because we *know* where those are. And that's incredibly valuable. @Conan_Kudo @pinskia @scherzog @crazyeddie @lina How is a spec more valuable than documentation? And UB are unfortunately underspecified in Rust, C and C++. We don't have a complete list for any of those languages. @robinm @pinskia @scherzog @crazyeddie @lina Well, a spec *is* documentation. But I imagine that's not what you meant, and you refer to usage documentation (e.g. documenting how to consume it rather than what it is). But you need both for a good picture of the language you are using. Rust has great usage documentation but crap documentation about Rust *itself*. And that can be a problem when you hit weird edges that you need clarity to resolve. @Conan_Kudo @pinskia @scherzog @crazyeddie @lina I'm surprised because I read a lot of C++ papers (I'd about 5% of them since many years) for fun, but I never needed to refer to them to resolve issue when using C++. However I do use cppreference.com a lot. And the only time I did not found what I needed in cppreference and had to open the corresponding paper (it was about deducing this), I just read the usage example, lot the implementation notes in legalized language. @robinm @pinskia @scherzog @crazyeddie @lina At least for me, it's rare that I go back to the spec documentation, but when I have to, it's mostly to understand the intent of things and what the constraints they designed it for. But I know people that use that same information to come up with "tricks" to squeeze out everything from the language without breaking things. (I'm also glad I don't live in that world where I need to think of that! 😂) @Conan_Kudo @pinskia @scherzog @crazyeddie @lina In your case, aren't the Rust RFC enough, or does divergeance between when they where accepted and the real implementation too much? And when you speak about squeezing out everything from the language feels like compiler work (which isn't an issue if there is a single blessed implementation) than application/library work, or do I miss something? @robinm @pinskia @scherzog @crazyeddie @lina Sometimes the divergence is meaningful between RFC and implementation. And even with a single compiler implementation, squeezing everything out the language matters. Because if you don't know what is safe to squeeze, the assumption can be violated in an upcoming revision without any real warning. It's the equivalent of dealing with nightly/unstable rust features. I'm also for having multiple compiler implementations, which is way harder with no spec. @Conan_Kudo @pinskia @scherzog @crazyeddie @lina Makes sence. thanks for the detailled explanation. @robinm @Conan_Kudo @pinskia @scherzog @lina C++ has some really deep ends that you'll only be able to resolve by looking at the standard. I think the most obscure one I helped answer was a guy trying to disable a copy constructor but allow construction via an implicit cast operator on the same type--or something...weird thing to do, but why wasn't the compiler allowing it?? It's this weird rule in the standard language that tosses every other possible resolution BUT copy out of even lookup. @crazyeddie @robinm @Conan_Kudo @scherzog @lina Even in a small language like P4 (which has a specifications), there are many corner cases that don't get flushed out always (in both the spec and the compiler). Examples for the spec were https://github.com/p4lang/p4-spec/pull/1076 https://github.com/p4lang/p4-spec/issues/1096, https://github.com/p4lang/p4-spec/issues/1037 (you can look up the reference compiler issues too). @robinm @scherzog @crazyeddie @lina Let's compare Rust to P4. Yes P4 is a much smaller language but it has a specifications and even that specifications had holes in it which has been fixed when someone started implementing a secondary compiler for it. Rust still is behind in that matter. P4-16 had a spec from the begining while Rust didn't. P4-16 was a language designed over P4-14 to be a specifications driven language while Rust was done as an implementation driven language.  @scherzog @crazyeddie @lina also some of the newish features in C++ are just rust features with runtime costs instead of compile time ones. |
Gregory's Server
@crazyeddie @scherzog @lina
The worst part is that in benchmarks, Rust beats out C++ and is only very slightly slower than C (by 7%), but would probably be more secure and more reliable in practice.
It might also be faster than C in production since it can better optimize itself.