To all the "why bother" rustaceans
To all the "why bother" rustaceans
Posted Dec 8, 2022 0:13 UTC (Thu) by Subsentient (guest, #142918)Parent article: Rust support coming to GCC
Is it a duplication of effort? Yes. Does the functionality already exist in another project? Yes.
Same thing with GCC and LLVM for the most-part, excluding some odd CPU targets.
Do you think we should stop working on GCC because LLVM exists? What about vice-versa?
We *want* a completely untethered rustc implementation. That's part of the point!
I don't *want* the rustc reference implementation to have a total chokehold on the language, that's bad for a systems language that needs to run in many targets with odd requirements.
So please, stop asking why, stop aggressively trying to kill independent implementations, and start understanding that the total independence and duplication of effort is *part of the point*.
Posted Dec 8, 2022 1:42 UTC (Thu)
by Subsentient (guest, #142918)
[Link] (1 responses)
For example, can you give me any documentation on when, exactly, implicit reborrows occur?
Sometimes I wonder if part of the reason Rust devs especially seem to oppose independent compilers is that they know these bugs will be brought into more public view and they're embarrassed, because they added features for convenience without any forethought for documenting those behaviors consistently and completely.
Posted Dec 8, 2022 8:47 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
I think the heart of the problem is something which hasn't occurred to you at all because of a C background. Rust's compiler accepts a _subset_ of legal Rust.
This is the other option for Rice's theorem, which avoids the catastrophe of C++ and to a lesser extent C, in which sure, the compiler definitely accepts all legal C++ / C but alas it also accepts myriad random other programs with no meaning, and provides you with no diagnostics, they just do... something.
In Rust all the programs that compile are legal Rust. Some of the programs which don't compile are legal Rust too, which is unfortunate, but hey, you're a human, you can fix the problem, whereas with the C++ approach you don't even know there's a problem.
Posted Dec 8, 2022 3:40 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Because it can split the ecosystem if one of the implementations can't keep up with new features. Which is a real problem because Rust is still evolving rapidly.
Posted Dec 8, 2022 16:13 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
Too many specs to me feel as if they're written to describe what happens.
A good spec attempts to be complete and consistent. And sensible.
?Best done? by compiling a truth table and making sure all possible values are, at a minimum, addressed.
As a perfect example of a cock-up, let's take the following truth table from the "gentoo compile a kernel" set up.
Flag A - is there a separate boot partition?
If flag A is false, flag B is meaningless so that's two out of four accounted for.
What's the point of having the options if the only thing that works is the default? Never mind the fact I wanted "A = true, B = false" because I did NOT want the automated install stomping over my live boot partition and leaving me with a system that wouldn't boot.
Never mind that the suggested work-around "to achieve the same effect" was to set the "don't install" flag - which not only doesn't put the install files in the /boot directory, but actually caused the build to blow up with "can't find input files" ...
I know they're volunteers, but a little bit of common sense and quality control (and pride in their own work) wouldn't go amiss...
Cheers,
Posted Dec 8, 2022 18:54 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
Too many specs to me feel as if they're written to describe what happens. I think this is a key thing having multiple implementations is supposed to address. If you have only one implementation, it's really easy to slip into treating that implementation as the primary specification, with the written specification as nothing but a description of the implementation. Having multiple implementations makes that less likely.
Posted Dec 8, 2022 21:02 UTC (Thu)
by amacater (subscriber, #790)
[Link]
Posted Dec 8, 2022 15:59 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (5 responses)
Having multiple, independent implementations complicates things. You can have one main branch that still makes most of the decisions, in which case everyone else is playing catch-up and the implementations aren't really equal. You can have each branch free to come up with its own new ideas, in which case you get different dialects, each with their own quirks. Or you can have some kind of bureaucratic standardization process, which will slow language development.
In practice, you'll probably have some mix of the three; that seems to be what happens with languages like C. There will be a formal, standard-defined version of the language, but compiler writers will keep trying to expand the language with incompatible, non-standard extensions. Eventually, the standards committee will have to sort through the extensions and try to convert them into a new version, but it will lack the coherence of having a single implementation with some vision behind it.
Posted Dec 8, 2022 17:10 UTC (Thu)
by koh (subscriber, #101482)
[Link] (4 responses)
> but it will lack the coherence of having a single implementation with some vision behind it.
Whether there is any coherence in current rustc's development is still an open question. The C (and also C++) standards committee(s) have members from several unrelated interest groups, each of which either prefer the semantics of different (sets of) compilers or have no clear preference at all. This makes for a more balanced discussion on the pros/cons of a particular approach because (ideally) there is no "bubble" all committee members share. Whether that need for a compromise of technical, backwards-compatibility and visionary constraints has been taken into account is hard to convey when the group of people responsible for such features has only the single implementation "rustc".
So language development may be slower, though personally as a mainly C++ developer, it is already too fast for me to keep up. I've only recently looked at C++20 ranges/views and will not learn how to write (a correct return type of) coroutines anytime soon - and the next C++23 is ready soon... I'd be interested to hear about examples of both, how the current Rust development model actually produced coherent parts of the language and also where breaking revisions needed to be done. Without such kind of evaluation, I don't think the "it's more complicated to have lots of implementations" argument is going to be strong.
Posted Dec 8, 2022 20:18 UTC (Thu)
by hunger (subscriber, #36242)
[Link] (3 responses)
We get an implementation of any new feature to play with in the nightly compiler builds (and those are actually easy to install and play with!). These features get promoted to stable when everybody agrees that they are good (the tools used are available to everybody!). Usually this promotion involves a crater run: All publically available rust code is build to see if something breaks due to the changes.
So we get one or two new features per compiler release every 6 weeks that are tested, work and did not break any (known) existing code. I find that much easier to digest than the "C++ spec drops" every couple of years with an overwhelming list of new things -- many of which incomplete -- that I can not use in my project since my compiler does not support them yet.
Posted Dec 8, 2022 21:11 UTC (Thu)
by mbunkus (subscriber, #87248)
[Link]
Posted Dec 8, 2022 22:01 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
It's one thing that GCC, Clang and MSVC need their own modules implementation, quite another that each of the three needs to write their own functions to format containers of things. No benefit accrues to C++ programmers from three different but hopefully equivalent implementations of these library features. At best you wasted 2x the effort, at worst now they behave slightly differently and so programmers need to compensate for that. So Rust (as far as I know) avoids that, GCC Rust won't re-implement Vec and Eq and Iterator and so on.
I also think the Rust model, though not always faster, is just more effective. WG21 (the "C++ Committee") has these periodic meetups to make a lot of its decisions. The argument is that if you're all together in Hawaii (for example) this lets you focus and so you can be more productive. But there are huge problems not only in terms of accessibility/ equity (if you're a Google employee in San Francisco then Hawaii is maybe affordable even if work isn't paying, not so much for a Polish teenager...) but because this crushes down the decision making process. Some people are going to hear about your idea for the first time an hour before they vote that it's not interesting and the committee doesn't want to see it next time. Would it have helped if your example was better motivated? If you'd worn tighter pants ? If you'd laughed at their joke ? Maybe they were just hungry and you'd have had better luck after lunch.
I have opinions about Rust RFC #3334 (Niches). They're strong enough opinions that I wrote something on the ticket and I might do it again. If you scheduled a specific video chat I might make it. Would I go to Hawaii? No. Fortunately Rust doesn't make decisions by flying to Hawaii.
Other people have opinions about that RFC. Instead of listening to them over the course of an hour, maybe while slightly hungover, I have been able to read them at my leisure over days, sometimes rolling an idea back and forth in my mind. I think some of the opinions are more right now than when I first saw them. I have questions I didn't have when the process began. I am confident WG21 could not replicate this process and get work down on their committed schedules.
Posted Dec 8, 2022 23:27 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 8, 2022 19:58 UTC (Thu)
by hunger (subscriber, #36242)
[Link] (4 responses)
That was the value proposition I also saw in gcc-rust. Then I saw a presentation at the linux plumbers conference about how they want to ease maintenence by using the rustc compiler crates for things like the borrow checker (once they can actually compile those).
How independent are two compilers when they share implementation of core parts like the borrow checker?
Posted Dec 8, 2022 22:47 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Also, the rules for Rust are (basically) "`&mut` is unique and cannot coexist with any `&` at the same time". The borrow checker is an imperfect tool to verify this and, as such, more of an implementation detail (like ADL lookup in a C++ compiler might be; as long as the *rules* are enforced, the implementation isn't all that important). Note that this new implementation is already a parallel one of the existing borrow checker and doing the work any GCC one might have done anyways. So I think it's still interesting for two frontends to send information to this to check "is it allowed?".
Posted Dec 9, 2022 9:29 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
Rust chooses to answer conservatively, Don't Know counts as No. All three borrow checkers, the one in Rust 1.0, the current one with Non-lexical lifetimes, and Polonius, are conservative, but each increases the range of correct Rust programs which successfully compile over the last.
The conservative choice offers safety, which is Rust's priority, at a cost of programmer inconvenience, which can be iteratively improved upon by working on the borrow checker. Thus, I believe Rust can and should specify that the actual rules are (basically) as you describe, but with a clarifying note that since these are semantic rules any compiler must be conservative. Maybe the note can specify that a conforming compiler must at least be able to allow X where X is some sane baseline of borrow simplicity.
Posted Dec 9, 2022 13:11 UTC (Fri)
by amacater (subscriber, #790)
[Link] (1 responses)
Posted Dec 9, 2022 15:26 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link]
Rust's stability promise has a number of limitations, the one crucial here is that you don't get to depend on bugs. So if the borrow checker, no matter which one, was mistakenly allowing an invalid construction, Rust won't keep that working in future versions.
To all the "why bother" rustaceans
So much of more advanced Rust can only be learned via trial and error, obscure slightly-wrong Stack Overflow answers, and reading the rustc source code.
That is a big, big problem, at least in my book.
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
Flag B - automount said boot partition before modifying?
If flag B is true, that's what you'd expect, fine, that's the default.
If flag B is false - the build blows up and refuses to run.
Wol
To all the "why bother" rustaceans
And you shouldn't need an alternative implementation (other than for bugs in the compiler) if the spec is done properly.
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans
To all the "why bother" rustaceans