Gregory's Server@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.
|
15 comments
@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. |
@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.