[HN Gopher] Progress toward a GCC-based Rust compiler
___________________________________________________________________
Progress toward a GCC-based Rust compiler
Author : askl
Score : 231 points
Date : 2023-12-18 15:51 UTC (7 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| vlovich123 wrote:
| The claims in the article feel kinda weak as to the motivation.
|
| > Cohen's EuroRust talk highlighted that one of the major reasons
| gccrs is being developed is to be able to take advantage of GCC's
| security plugins. There is a wide range of existing GCC plugins
| that can aid in debugging, static analysis, or hardening; these
| work on the GCC intermediate representation
|
| > One more reason for gccrs to exist is Rust for Linux, the
| initiative to add Rust support to the Linux kernel. Cohen said
| the Linux kernel is a key motivator for the project because there
| are a lot of kernel people who would prefer the kernel to be
| compiled only by the GNU toolchain.
|
| That explains why you'd want GCC as the backend but not why you
| need a duplicate front end. I think it's a bad idea to have
| multiple front ends and Rust should learn from the mistakes of
| C++ which even with a standards body has to deal with a mess of
| switches, differing levels of language support for each compiler
| making cross-platform development harder, platform-specific
| language bugs etc etc.
|
| > A lot of care is being put into gccrs not becoming a "superset"
| of Rust, as Cohen put it. The project wants to make sure that it
| does not create a special "GNU Rust" language, but is trying
| instead to replicate the output of rustc -- bugs, quirks, and
| all. Both the Rust and GCC test suites are being used to
| accomplish this.
|
| In other words, I'd love gccrs folks to explain why their
| approach is a better one than rustc_codegen_gcc considering the
| latter is able to achieve this with far less effort and risk.
| gkbrk wrote:
| > Rust should learn from the mistakes of C++
|
| Rust should learn from the mistakes of C++ and C, which are one
| of the longest lasting, biggest impact, widely deployed
| languages of all time?
|
| It's confusing when people think language standards are bad,
| and instead of saying this code is C99 or C++11, they like
| saying "this code works with the Rustc binary / source code
| with the SHA256 hash e49d560cd008344edf745b8052ef714b0759580889
| 8c835f17f962a10012f964".
| flooow wrote:
| Or, y'know, "rustc 1.74.0" like a normal person.
| gpm wrote:
| And in the rare instances where you're using in-development
| features "rust nightly-2023-12-18"
|
| Literally the only reason to specify via a hash* would be
| if you were using such a bleeding edge feature that it was
| only merged in the last 48 hours or so and no nightly
| versions had been cut.
|
| *Or I suppose you don't trust the supply chain, and you
| either aren't satisfied with or can't create tooling that
| checks the hash against a lockfile, but then you have the
| same problem with literally any other compiler for any
| language.
| rcxdude wrote:
| Indeed. If I'm specifying a hash for anything I'm
| definitely not leaving things up to the very, very wide
| range of behaviours covered by the C and C++ standards.
| legends2k wrote:
| That's besides the point. Adhering to a language standard
| is much clearer than specifying it by a language compiler's
| version. Behaviour is documented in the former while one
| has to observe the output of a binary (and hope that side
| effects are understood with their full gravity).
| estebank wrote:
| But no-one writes code against the standard. We all write
| code against the reality of the compiler(s) we use. If
| there's a compiler bug, you either use a different
| version, a different vendor, or we side step the code
| triggering the issue. The spec only tells you that the
| vendor might fix this in the future.
| wongarsu wrote:
| But barely anyone gets to write C++11. You write C++11
| for MSVC2022, or C++11 that compiles with LLVM 15+ and
| GCC 8+, and maybe MSVC if you invest a couple hours of
| effort into it. That's really not that different from
| saying you require a minimum compiler version of Rust
| 1.74.0.
| pornel wrote:
| C and C++ are widely used _despite_ their language, compiler,
| and build system fragmentation. Each platform /compiler combo
| needs ifdefs and workarounds that have been done for so long
| they're considered a normal thing (or people say MSVC and
| others don't count, and C is just GCC+POSIX).
|
| There's value in multiple implementations ensuring code isn't
| bug-compatible, but at the same time in C and C++ there's
| plenty of unnecessary differences and unspecified details due
| to historical reasons, and the narrow scope of their specs.
| gkbrk wrote:
| Yes, that's how the story goes. Languages with specs are
| widely deployed despite being fragmented and bad, not
| because people find value in multiple implementations. Must
| be a coincidence that C, C++, Javascript and C# and Java
| all fall under this umbrella.
| legobmw99 wrote:
| Java and C# seem to have actually gotten the idea of
| multiple implementations correct, in the sense that I
| have never needed to worry about the specific runtime
| being used as long as I get my language version correct.
| I have basically never seen a C/C++ program of more than
| a few hundred lines that doesn't include something like
| #ifdef WIN32 ...
| bluGill wrote:
| Is there more than one Java implementation that is
| usable? All I can find are obsolete products that never
| got very far.
| gkbrk wrote:
| Here are a few Java implementations that I've used
| recently.
|
| - My Android phone
|
| - OpenJDK on my laptop
|
| - leJOS for a university robotics course to run on Lego
| robots
|
| - Smart cards, I have a couple in my wallet
|
| Perhaps I'd call the Lego robot stuff obsolete, certainly
| not the Android userspace or smart cards though.
| vlovich123 wrote:
| Your Android phone and the latest Java share very little
| commonality. It only recently supports Java 11 which is 5
| years old at this point. The other non-OpenJDK
| implementations you mentioned are much more niche (I
| imagine the smart cards run JavaCard which is still
| probably going to be running an OpenJDK offshoot).
| gkbrk wrote:
| Who said anything about the latest Java. Since Java has
| versioned specs, platform X can support one version, and
| you can target it based on that information even if other
| versions come out and get supported by other platforms.
|
| For example C89 and C99 are pretty old, and modern C has
| a lot that is different from them. But they still get
| targeted and deployed, and enjoy a decent following.
| Because even in 2024, you can write a new C89 compiler
| and people's existing and new C89 code will compile on it
| if you implement it right.
| sunshowers wrote:
| But as a developer I do want to use (some of) the latest
| features as soon as they become available. That's why
| most of my crates have an N-2 stable version policy.
| vlovich123 wrote:
| And since Rust does a release every 6 weeks, we're
| talking a ~4 month lag. That's unheard of for C/C++.
| pjmlp wrote:
| Java 17 LTS is supported from Android 12 onwards.
|
| PTC, Aicas, microEJ, OpenJ9, Azul, GraalVM are a couple
| of alternative JVM implementations.
| vlovich123 wrote:
| Again. I'm not claiming that alternative implementations
| don't exist, just that they're not particularly
| common/popular compared with OpenJDK/Oracle (which is
| largely the same codebase). Android is the only
| alternative implementation with serious adoption and it
| lags quite heavily.
|
| BTW GraalVM is based on OpenJDK so I don't really
| understand your point there. It's not a ground-up
| reimplementation of the spec.
| pjmlp wrote:
| GraalVM uses another complete infrastructure, JIT and GC
| compilers, which affect runtime execution, and existing
| tooling.
|
| Doesn't matter how popular they are, they exist because
| there is a business need, and several people are willing
| to pay for them, in some cases lots of money bags,
| because they fulfill needs not available in OpenJDK.
| hansjorg wrote:
| Eclipse OpenJ9 (previously IBM J9) is in active
| development and supports Java 21.
| vintermann wrote:
| Well, there's Android... and Unity, which as I recall is
| stuck on an old version of C# and its own way of doing
| things. I also had the interesting experience of working
| with OSGI at work a couple of years.
| bluGill wrote:
| Or do languages get specs because they are widespread and
| becoming fragmented? That clearly apples to C and C++ -
| both were implemented first and then a formal spec was
| written in response to fragmentation.
| vlovich123 wrote:
| C# has multiple compilers and runtimes? Mono used to be a
| separate thing but if I recall correctly mono has been
| adopted by MS & a lot merged between the two.
|
| JavaScript itself is a very simple language with most of
| the complexity living in disparate runtimes and that
| there are multiple runtime implementations is a very real
| problem requiring complex polyfills that age poorly that
| are maintained by the community. For what it's worth
| TypeScript has a single implementation and it's extremely
| popular in this community.
|
| Java is probably the "best" here but really there's still
| only the Sun & OpenJDK implementations and the OpenJDK
| and Oracle are basically the same if I recall correctly
| with the main difference being the inclusion of
| proprietary "enterprise" components that Oracle can
| charge money for. There are other implementations of the
| standard but they're much more niche (e.g. Azul systems).
| A point against disparate implementations is how Java on
| Android is now basically a fork & a different language
| from modern-day Java (although I believe that's mostly
| because of the Oracle lawsuit).
|
| Python is widely deployed & CPython remains the version
| that most people deploy. Forks find it difficult to keep
| up with the changes (e.g. PyPy for the longest time
| lagged quite badly although it seems like they're doing a
| better job keeping up these days). The forks have
| significantly less adoption than CPython though.
|
| It seems unlikely that independent Rust front end
| implementations will benefit it's popularity. Having GCC
| code gen is valuable but integrating that behind the Rust
| front-end sounds like a better idea and is way further
| along. gccrs is targeting a 3 year old version of Rust
| that still isn't complete while the GCC backend is being
| used to successfully compile the Linux kernel. My bet is
| that gccrs will end up closer to gcj because it is
| difficult to keep up.
| lioeters wrote:
| > TypeScript has a single implementation
|
| It's probably a matter of time until there's a TypeScript
| compiler implemented in Rust. But the surface area of the
| language is pretty big, and I imagine it will always lag
| behind the official compiler.
|
| > Forks find it difficult to keep up with the changes
|
| That's interesting to think of multiple implementation of
| a language as "forks" rather than spec-compliant
| compilers and runtimes. But the problem remains the same,
| the time and effort necessary to constantly keep up with
| the reference implementation, the upstream.
| vlovich123 wrote:
| There's been plenty of attempts to implement TS in
| another language or whatnot. They all struggle with
| keeping up with the pace of change cause the team behind
| TS is quite large. There was an effort to do a fairly
| straight port into Rust which actually turned out quite
| well, but then the "why" question comes up - the reason
| would be to do better performance but improving
| performance requires changing the design which a
| transliteration approach can't give you & the more of the
| design you change, the harder it is to keep up with
| incoming changes putting you back at square 1. I think
| Rust rewrites of TS compilers (as long as TS is seeing
| substantial changes which it has been) will be worse than
| PyPy which is basically a neat party trick without
| serious adoption.
| gkbrk wrote:
| > C# has multiple compilers and runtimes?
|
| Yes. Roslyn, Mono and some Mono-like thing from Unity to
| compile it into C++.
|
| > Mono used to be a separate thing
|
| Mono is still a thing. The last commit was around 3
| months ago.
|
| > multiple runtime implementations is a very real problem
| requiring complex polyfills
|
| You can target a version of the spec and any
| implementation that supports that version will run your
| code. If you go off-spec, that's really on you, and if
| the implementation has bugs, that's on the
| implementation.
|
| > TypeScript has a single implementation
|
| esbuild can build typescript code. I use it instead of
| tsc in my build pipeline, and only use tsc for type-
| checking.
|
| > [Typescript is] extremely popular in this community
|
| esbuild is extremely popular in the JS/TS community too.
| The second most-popular TS compiler probably.
|
| > [Java has] only the Sun & OpenJDK implementations
|
| That's not true. There are multiple JDKs and even more
| JVMs.
|
| > Java on Android is now basically a fork & a different
| language from modern-day Java
|
| Good thing Java has specs with multiple versions, so you
| can target a version that is implemented by your target
| platform and it will run on any implementation that
| supports that version.
|
| > Python is widely deployed & CPython remains the version
| that most people deploy. > The forks have significantly
| less adoption than CPython though.
|
| That is because Python doesn't have a real spec or
| standard, at least nothing solid compared to the other
| languages with specs or standards.
|
| > It seems unlikely that independent Rust front end
| implementations will benefit it's popularity.
|
| It seems unlikely that people working on an open-source
| project will only have the popularity of another open-
| source project in mind when they spend their time.
| vlovich123 wrote:
| > Yes. Roslyn, Mono and some Mono-like thing from Unity
| to compile it into C++.
|
| Roslyn is more like the next gen compiler and will be
| included in Mono once it's ready to replace msc. I view
| it as closer to polonius because it's an evolutionary
| step to upgrade the previous compiler into a new
| implementation. It's still a single reference
| implementation.
|
| > Mono is still a thing
|
| I think you misunderstood my point. It had started as a
| fork but then Microsoft adopted it by buying Xamarin.
| It's not totally clear to me if it's actually a fork at
| this point or if it's merged and shares a lot of code
| with .NET core. I could be mistaken but Mono and .Net
| core these days also share quite a bit of code.
|
| > rebuild can build typescript code
|
| Yes, there are plenty of transpilers because the language
| is easy to desugar into JavaScript (intentionally so - TS
| stopped accepting any language syntax extensions and
| follows ES 1:1 now and all the development is in the
| typing layer). That's very different from a forked
| implementation of the type checker which is the real meat
| of the TS language compiler.
|
| > The second most popular TS compiler probably
|
| It's a transpiler and not a compiler. If TS had
| substantial language extensions on top of JS that it was
| regularly adding, all these forks would be dead in the
| water.
|
| > That's not true. There are multiple JDKs and even more
| JVMs
|
| I meant to say they're the only ones with any meaningful
| adoption. All the other JDKs and JVMs are much more niche
| and often benefit from living in a niche that is often
| behind on the adoption curve (i.e. still running Java 8
| or something or are willing to stay on older Java
| versions because there's some key benefit in the other
| version that is operationally critical).
|
| > Good thing Java has specs with multiple versions, so
| that you can target a version...
|
| Good for people implementing forks, less good for people
| living within the ecosystem in terms of having to worry
| about which version of the compiler to support with their
| library. For what it's worth Rust also has language
| versions but it's more like an LTS version of the
| language whereas Java versions come out more frequently &
| each implementation is on whatever year they wanted to
| snapshot against.
| Rohansi wrote:
| FYI Mono has been shipping Roslyn as its C# compiler for
| a few years now. Mono's C# compiler only fully supports
| up to C# 6 while Roslyn supports C# 12, the latest
| version.
|
| Mono shares a lot of code with .NET (Core) but is mostly
| limited to the standard libraries and compiler. Mono is
| still its own separate implementation of the CLR
| (runtime/"JVM") and supports much more platforms than
| .NET (Core) today.
| tester756 wrote:
| >Yes. Roslyn, Mono and some Mono-like thing from Unity to
| compile it into C++.
|
| Mono has approx. 0.x% market share outside Unity. Also
| Mono is used by .NET Core for Blazor WASM iirc.
|
| Let's don't compare this scenario of sane world with the
| mess that exists in C++ world.
| ragnese wrote:
| > It's confusing when people think language standards are
| bad, and instead of saying this code is C99 or C++11, they
| like saying "this code works with the Rustc binary / source
| code with the SHA256 hash e49d560cd008344edf745b8052ef714b075
| 95808898c835f17f962a10012f964".
|
| I don't know if that's totally fair. I remember that it took
| quite a while for C++ compilers to actually implement all of
| C++11. So, it was totally normal at the time to change what
| subset of C++11 we were using to appease whatever version of
| GCC was in RHEL at the time.
| staunton wrote:
| Technically, no compiler ever implemented "all" of c++11...
| You'd have to implement garbage collection, for example :D
| the_why_of_y wrote:
| Not to mention "export", which was in C++98 but only ever
| supported by Comeau C++.
| rcxdude wrote:
| The long-lasting and widespread nature of C and C++ is _why_
| their mistakes are the ones most worth learning from.
| sophacles wrote:
| > the longest lasting, biggest impact, widely deployed
| languages of all time
|
| Can be true at the same time as:
|
| c and c++ have made mistakes, and have had issues as a result
| of bad choices
|
| The later should be learned from by any language in a place
| to not make those same mistakes. We call this technological
| progress, and its OK.
| bluGill wrote:
| C and C++ both learn from the mistakes of others too. Of
| course as mature languages they have a lot they cannot
| change. However when they do propose new features it is
| common to look at what other languages have done. C++'s
| thread model is better than Java's because they were able
| to look at the things Java got wrong (in hindsight, those
| choices looked good at the time to smart people - lets not
| pick on Java for not predicting how modern hardware would
| evolve in the future. Indeed it is possible in a few years
| hardware will evolve differently again and C++'s thread
| model will then be just as wrong despite me today calling
| it good)
| sunshowers wrote:
| I think people generally specify their MSRVs as version
| numbers for libraries, and often a pinned toolchain file for
| applications. I haven't seen anyone use a hash for this,
| though I'm sure I might have missed something.
|
| I don't think language standards are "bad".
| Guvante wrote:
| That phrase doesn't mean what you think it is.
|
| "Learn from the mistakes of X" doesn't mean X is bad, it
| means X made mistakes.
| bryanlarsen wrote:
| > Rust should learn from the mistakes of C++
|
| They are. You quoted them doing it, the care taken not to
| become a superset. The problem with C/C++ stemmed from compiler
| vendors competing with each other to be "better" than their
| peers.
|
| Multiple front ends of an implementation of a language usually
| shakes out a bunch of bugs and misimplementations. That's the
| primary benefit of having multiple front ends IMO.
| delfinom wrote:
| >The problem with C/C++ stemmed from compiler vendors
| competing with each other to be "better" than their peers.
|
| Yea but this is Linux and OSS. NIHisms are fucking rampant
| everywhere.
|
| I give it a year before gccrs announces a new "gnurs" mode
| with language extensions.
| saghm wrote:
| I'd be surprised about this mostly because I can't imagine
| anyone using gcc-specific Rust extensions. Not only does
| rustc have an extraordinary amount of traction by being
| basically the only choice up until this point, Rust doesn't
| really have the reputation of moving slowly to adopt new
| features; if anything, there's been as much skepticism
| about new features added over the years as excitement. I
| can honestly imagine more people adopting a Rust
| implementation with a commitment _not_ to add new features
| that are added to rustc than one that adds its own separate
| features.
|
| Even as someone who probably will never use gccrs, I think
| having more than one implementation of Rust is a good thing
| for the language (for all the usual reasons that get
| cited). In the long term, I'd love for Rust to eventually
| to be able to specify its semantics in a way that isn't
| tied to rustc, which is a moving target and gets murky when
| you consider implementation-specific bugs.
| nequo wrote:
| > Rust doesn't really have the reputation of moving
| slowly to adopt new features
|
| There are some exceptions to this. Although there are
| possibly good reasons for such features moving slowly, a
| competing compiler could popularize them before they are
| stabilized in rustc. One example is generators[1] but
| there's a longer list in The Unstable Book.[2]
|
| [1] https://github.com/rust-lang/rust/issues/43122
|
| [2] https://doc.rust-lang.org/stable/unstable-
| book/language-feat...
| estebank wrote:
| Prevalent use of nightly Rust purely for specific
| unstable features would do the same. It's been a while
| since there has been a "must have" feature has kept
| people confined to nightly, though.
| Guvante wrote:
| I feel like having a distinct implementation that is
| unstable is more likely.
|
| Stabilizing things from rustc is a recipe for disaster as
| if rustc builds something new you are in a bad place.
| Guvante wrote:
| NIHI is usually "using product X is almost as hard (or
| expensive )as building it"
|
| Linux tends to shun unfree software which is a very
| different take. Buy or build is roughly money vs time (aka
| money). Software freedom is not the same thing.
|
| Also why does software freedom lead to divergences?
| Certainly GCC partook in the arms race around C++ but
| recently they have been pretty good about aiming for full
| standard support as the goal. (The exception being proposed
| features but that is unavoidable when C++ prefers battle
| tested proposals)
| pjmlp wrote:
| Actually one of the problems we are having with compilers
| catching up with ISO is that since C++11, features aren't
| battle tested, rather designed in paper or some special
| compiler branch, and eventually adopted by everyone.
| Guvante wrote:
| Honestly depending on the feature that might be for the
| best. If all three compilers have distinct on by default
| divergent settings that would be terrible.
|
| My point is outside of instances where everyone agrees
| something has to change you need a compiler branch at the
| minimum. This means the compiler you changed will get
| that feature first.
|
| Given it takes years to implement the full standard this
| leads to divergence between the compilers in standards
| compliance.
|
| Honestly all totally workable but makes talking about
| "standard C++" hard.
| pjmlp wrote:
| There are more than three compilers, and many of the
| changes if done at all in an existing compiler, are a mix
| between private branches and ongoing unstable features,
| hardly battle tested as the first standards were, when
| existing practice is what came into the standard.
| neuromanser wrote:
| > I think it's a bad idea to have multiple front ends and Rust
| should learn from the mistakes of C++ which even with a
| standards body has to deal with a mess of switches
|
| I do not disagree, yet at the same time, having the same set of
| switches across different languages is nice, too.
| ndiddy wrote:
| Having another Rust implementation allows for an "audit" to
| help validate the Rust spec and get rid of any unspecified
| behavior. It would also give users options. If I hit a compiler
| bug in MSVC, I can file a report, switch to GCC and keep
| working on my project until the bug is fixed. With Rust, that's
| not currently possible.
| VBprogrammer wrote:
| I don't have a lot of experience in C or C++ but I wonder if
| this ever works in practice for a non-trivial codebase? I'd
| be really surprised if, without diligently committing to
| maintaining compatibility with the two compilers, it was easy
| to up sticks and move between them.
| cozzyd wrote:
| It's pretty easy to move between gcc/clang/icc for most
| codebases. Though there are some useful features still that
| are gcc only. (And probably some that are clang only,
| though I pretty much only use gcc...)
| logicchains wrote:
| >I'd be really surprised if, without diligently committing
| to maintaining compatibility with the two compilers, it was
| easy to up sticks and move between them
|
| Many places deliberately compile with multiple compilers as
| part of the build/test pipeline, to benefit from more
| compiler warnings, diagnostics etc.
| jupp0r wrote:
| There are lots of libraries that need to compile on a
| variety of platforms (ie different versions of LLVM for
| Android and MacOS, MSVC for Windows and GCC for some
| embedded targets not well supported by LLVM).
| ska wrote:
| It works but you have to keep it at least "semi-active".
| Some shops have CI services setup to cross compile etc.
| already. Mainly I've seen this not as a tool to maintain a
| "backup" but as a way to shake out bugs and keep non-
| portable stuff from creeping into the codebase.
|
| You could probably do most of it with conservative linting
| and some in-house knowledge of portability issues, non-
| standard compiler extensions, etc.
|
| It's typically a _lot_ easier to do this for different
| compiler, same target, than different targets.
| Guvante wrote:
| Our codebase works on all three, we compile on MSVC for
| Windows, GCC for Linux, and Clang for Mac.
|
| It isn't easy and honestly the idea of "just don't use MSVC
| for a while" is strange to me. Sure you can compile with
| any of them but almost certainly you are going to stick to
| one for a given use case.
|
| "This release is on a different compiler" isn't something
| you do because of a bug. Instead your roll back a version
| or avoid using the unsupported feature until a fix is
| released.
|
| The reason is as much as they are supposed to do the same
| thing the reality is bugs are bugs, e.g. if you invoke
| undefined behavior you will generally get consistent
| results with a given compiler but all bets are off if you
| swap. Similarly it is hard not to rely on implementation
| defined behavior without building your own standard library
| which specifically defines that behavior across compilers.
| gpderetta wrote:
| It is quite common. In most places I have worked we did GCC
| and clang builds. Some did GCC/clang/msvc/ICC.
|
| And of course plenty of OSS libraries support many
| compilers even beyond the main three.
| jandrewrogers wrote:
| Many complex C++ codebases have full parallel CI pipelines
| for GCC and LLVM. It encourages good code hygiene and
| occasionally identifies bugs in the compiler toolchain.
|
| If you are using intrinsics or other architecture-specific
| features, there is a similar practice of requiring full CI
| pipelines for at least two CPU architectures. Again, it
| occasionally finds interesting bugs.
|
| For systems I work on we usually have 4 CI pipelines for
| the combo of GCC/LLVM and ARM/x86 for these purposes. It
| costs a bit more but is generally worth it from a code
| quality perspective.
| izacus wrote:
| Adding CI pipeline running compiles on MSVC was one of
| the big shakeouts of undefined behaviour and bugs in our
| C++ codebase - while making that compiler happy is
| annoying if you come from Unixy land, it did force us to
| shed quite a few bad habits and even find several bugs in
| that endeavor.
|
| (And then we could ship the product on Windows, so that
| was nice.)
| vlovich123 wrote:
| The C++ spec regularly has all sorts of errata and
| misdesigns. Not sure I buy this argument.
| KolmogorovComp wrote:
| Rust has currently no formal specification, so what would you
| use as an arbiter?
|
| Also the article says otherwise > The project wants to make
| sure that it does not create a special "GNU Rust" language,
| but is trying instead to replicate the output of rustc --
| bugs, quirks, and all
| lambda wrote:
| You use the same process as for deciding if changes to
| rustc are compliant or not; the judgement of the language
| and compiler teams.
|
| And running into these kinds of questions, both in a single
| project that evolves over time (rustc) and a separate
| project, help to feed information back into what you need
| for a formal specification; which is something that is
| being planned out. Having a second implementation can help
| find these areas where you might need to be narrower or
| broader in your specification, in order to clarify enough
| for it to be implementable or broaden it enough to
| accommodate reasonable implementation differences.
|
| They are not trying to diverge in language implementation,
| but there will always be simple compiler bugs, which may
| crop up in one implementation but not another. For
| instance, some LLVM optimization pass may miscompile some
| code; gccrs wouldn't necessarily be trying to recreate that
| exact bug. I think that "bugs, quirks, and all" really
| means that they aren't trying to fix major limitations of
| rustc, such as introducing a whole different borrow checker
| model which might allow some programs that current rustc
| does not. They're trying to fairly faithfully recreate the
| language that rustc implements, even if some aspects might
| be considered sub-optimal, but they aren't going to re-
| implement every ICE and miscompilation, those are places
| where there could be differences.
| KolmogorovComp wrote:
| I agree with you it has benefits, what I'm wondering
| about is if not more bugs (though not the same ones)
| would be fixed by contributing directly to rustc compared
| to the massive effort of building a new compiler.
| Narishma wrote:
| It's about finding those bugs in the first place. Working
| on a different implementation is one way of doing that.
| slashdev wrote:
| I hit a compiler bug in rust and downgraded it to an earlier
| stable version. That's usually enough.
| tester756 wrote:
| >Having another Rust implementation allows for an "audit" to
| help validate the Rust spec and get rid of any unspecified
| behavior. It would also give users options. If I hit a
| compiler bug in MSVC, I can file a report, switch to GCC and
| keep working on my project until the bug is fixed. With Rust,
| that's not currently possible.
|
| Theory is cool, but in practice other compiler has its own
| quirks too
|
| How about having one compiler which is used by all
| developers, which increases chances of bugs getting caught
| faster and fixed faster meanwhile you just use workaround?
| nindalf wrote:
| Your sentiment is a commonly expressed one, but not usually
| by people who have adopted Rust. It's usually Clang/MSVC/GCC
| users who have decided this is the optimal flow and want to
| replicate it in all future codebases they work in, regardless
| of language.
|
| In reality if you hit a compiler bug in Rust or Go (or any
| other language with one main impl like Python, Ruby...) you
| would file a report and do one of two things - downgrade the
| compiler (if it's an option) or write the code a different
| way. Compiler bugs in these languages are rare enough that
| this approach works well.
|
| That said, for people who are really keen on a spec, there is
| one being worked on (https://blog.rust-lang.org/inside-
| rust/2023/11/15/spec-visio...).
|
| But this GCCRS effort doesn't get you any closer to your
| ideal C/C++ style workflow because they are committing to
| matching the semantics of the main compiler exactly. Bugs and
| all. And that's the way it should be. Today Rust is
| substantially simpler because every project is built exactly
| the same way - cargo build. The ecosystem becomes worse if I
| have to install a different toolchain and learn a different
| build system with a different compiler for every new project
| I interact with.
| rhdunn wrote:
| So by that definition you would only want one web browser as
| there are currently multiple HTML+CSS+JavaScript "front ends".
| In which case, you end up with a Chrome monopoly where Google
| gets to decide what the web looks like!
| mtrower wrote:
| A goodly number of people appear to want just that.
|
| I don't agree, mind you, but someone reading your comment
| with this mindset will probably be reinforced rather than
| swayed.
| bayindirh wrote:
| The main motivation is having a GPL licensed, independently
| developed complete Rust compiler which is not dependent on
| LLVM.
| cozzyd wrote:
| Yes this is important. Otherwise in the future you'll see
| proprietary rust distributions for various devices or with
| specific features
| GrumpySloth wrote:
| C++ and Java, which have many implementations, also have
| proprietary distributions, see Apple's fork of Clang,
| Microsoft's MSVC, Azul VM, Jamaica VM, ...
|
| And some of them are pretty nice. Life is good.
| bayindirh wrote:
| When you don't have a GPL implementation, the only good
| implementation might be closed source fork of the LLVM
| version, effectively forking Rust into Rust and Rustium.
| Will life be good then?
| sunshowers wrote:
| This seems like an astoundingly remote possibility.
| bayindirh wrote:
| Given the companies backing LLVM and the surrounding
| ecosystem, I think it's an astounding possibility.
|
| Companies love permissive licenses for a reason.
| swsieber wrote:
| You'll still see those though? A fully GPL implementation
| doesn't prevent the current implementation from being used
| in a proprietary rust distribution... unless of course the
| GPL implementation were to fork from the current
| implementation... which is the main thing people against
| the GPL implementation are worried about
| bayindirh wrote:
| I think, the GCCRS project takes the rustc implementation
| as reference, and targets 100% compatibility with them as
| a fundamental goal and requirement. There is no schism
| involved.
| mhh__ wrote:
| There are arguments for and against but for colour: D in GCC
| uses a shared frontend, which means it's not hard to maintain
| the frontend aspects -- but that also means the frontend is a
| monoculture which is not very healthy at the moment.
|
| If someone will pay you to do it I would do a new frontend --
| it's surprisingly little work to get something you can
| bootstrap with.
| p0nce wrote:
| Having maintained both C++ and D for different compilers,
| it's way easier to do it in D since the front-end features
| are the same (modulo builtins) and the stdlib is 99% the
| same.
| edelsohn wrote:
| Based on that logic, why did the LLVM community develop Clang,
| Clang++, libc++, etc. instead of continuing with DragonEgg?
| There already were GCC, G++, libstdc++ , as well as EDG C++
| front-end.
|
| GCC, Clang, MSVC, and other compilers complement each other,
| serve different purposes, and serve different markets. They
| also ensure that the language is robust and conforms to a
| specification, not whatever quirks a single implementation
| happens to provide. And multiple implementations avoids the
| dangers of relying on a single implementation, which could have
| future problems with security, governance, etc.
|
| The GNU Toolchain Project, the LLVM Project, the Rust project
| all have experienced issues and it's good to not rely on a
| single point of failure. Redundancy and anti-fragility is your
| friend.
| vlovich123 wrote:
| LLVM saw growth for a number of reasons, but nothing to do
| because it was actually beneficial for the C++ ecosystem:
|
| * A C++ codebase. At the time GCC was written in C which
| slowed development (it's now a C++ codebase adopting the
| lessons LLVM provided)
|
| * It had a friendlier license than GCC which switched to
| GPLv3 and thus Google & Apple moved their compiler teams to
| work on LLVM over time.
|
| * Libc++ is a combination of friendlier license + avoiding
| the hot garbage that was (maybe still is?) libstdc++ (e.g.
| there were incompatible design decisions in libstdc++ that
| inhibited implementing the C++ spec like SSO). There were
| also build time improvements if I recall correctly.
|
| * LLVM provided a fresher architecture which made it more
| convenient as a research platform (indeed most compiler
| academics target LLVM rather than GCC for new research
| ideas).
|
| Basically, the reason LLVM was invested in instead of
| DragonEgg was a mixture of license & the GCC community being
| quite difficult to work with causing huge amounts of
| investments by industry and academia into LLVM. Once those
| projects took off, even after GCC fixed their community
| issues they still had the license problem and the LLVM
| community was strongly independent.
|
| Compilers don't typically generate security issues so that's
| not a problem. There are questions of governance but due to
| the permissive license that Rust uses governance problems can
| be rectified by forking without building a new compiler from
| the ground up (e.g. what happened with NodeJS until the
| governance issues were resolved and the fork reabsorbed).
|
| It's funny you mention the different C++ compilers consider
| that Clang is well on its way of becoming the dominant
| compiler. It's already targeting to be a full drop-in
| replacement for MSVC and it's fully capable of replacing GCC
| on Linux unless you're on a rarer platform where GCC has a
| bit richer history in the embedded space). I think over the
| long term GCC is likely to die and it's entirely possible
| that MSVC will abandon their in-house and instead use clang
| (same as they did abandoning IE & adopting Blink). It will be
| interesting to see if ICC starts porting their optimizations
| to LLVM and making them freely available - I can't imagine
| ICC licenses really bring in enough money to justify things.
| rayiner wrote:
| I'm surprised at the negative reaction to GCC-RS. If a language
| doesn't have multiple implementations, it's a pretty sad excuse
| for a language.
| sylware wrote:
| The problem is on the long run: syntax stability, avoiding
| feature creeps with extensions/attributes, like we actually
| have with C (c++ is beyond saving due to its absurd and
| grotesque complexity).
|
| Without that, you won't have real-life alternatives.
| ajross wrote:
| > avoiding feature creeps with extensions/attributes,
|
| That seems like a purely semantic argument? Rust is adding
| features _extremely_ rapidly! You 're just saying it's
| "development" if it's done by one entity but "creep" if it's
| done by someone else?
| PoignardAzur wrote:
| > _I'm surprised at the negative reaction to GCC-RS. If a
| language doesn't have multiple implementations, it's a pretty
| sad excuse for a language._
|
| That used to be the common wisdom (especially because of
| C/C++), but it's a lot more debated these days.
|
| The consensus in the Rust community is that the current
| situation (one canonical-by-definition compiler, lots of
| documentation, a minimal spec for safety-critical industries,
| and specs for some modular sub-parts) get most of the
| advantages of multiple implementations without the drawbacks.
| not2b wrote:
| I think that the people who are debating it are missing some
| things. It often happens that only when a second
| implementation is attempted, unspecified holes in the
| documentation are exposed and standards are tightened up. Any
| differences in the two compilers will either mean that
| there's a bug in the new implementation (most likely), a bug
| or unclear issue in the documentation, or a bug in the mature
| implementation (it happens).
|
| And no, the official compiler isn't canonical by definition.
| If it were, it would mean it has no bugs, and if there's a
| crash or a wrong result that's what the language is supposed
| to do.
| vlovich123 wrote:
| Everything in engineering is trade offs. A single front end
| ends up in a stronger position for the _community_ (i.e.
| the users of the language) because bug reports are easier
| (only one project to report them to), collaboration is
| easier /simpler for OSS maintainers (no issues where "crate
| foo works fine on rustc but doesn't on gccrs" to
| triage/maintain), and language features come quicker (no
| need to synchronize/debate with other implementations). The
| downsides of underspecification are much smaller by
| comparison. As far as documentation goes that's a red
| herring because gccrs is reusing the single standard
| library implementation which means that any documentation
| issues would still exist (I don't think I've even once
| needed to lookup documentation for the compiler & language
| docs issues would be shared as well since rustc in this
| model still remains the canonical ground truth).
| not2b wrote:
| At this point, gccrs is quite immature, so you can simply
| ignore it. If we get to the point where its quality is
| good enough, this will change, but the likelihood is that
| any problems found will result in improvements to
| documentation (if something is underspecified). There
| could also be optimization bugs in LLVM that aren't
| present in GCC, so we could find bugs in rustc that
| aren't in gccrs at some point, but I think that will only
| be significant if gccrs greatly improves.
|
| For now, anyone who finds that "crate foo works fine on
| rustc but doesn't on gccrs" can just report a bug to
| gccrs.
| vlovich123 wrote:
| I'm not saying that gccrs contributors should stop. If
| they want to invest their time & energy into it kudos. I
| happen to think the costs outweighs the benefits but
| you're right that I can just ignore it to no ill effect
| right now. Where I would caution that though is when the
| Rust project starts needing to making accommodations to
| help gccrs (which is something described in the article).
| It's possible that some accommodations help Rust anyway /
| there's no harm, but it's also useful to be mindful that
| more & more of these accommodations can start to have a
| negative cost over time & thus impact Rust as a whole &
| these costs are obnoxiously hard to quantify and because
| people like to get along there's a general preference to
| be more accommodating. That's the real danger that gccrs
| poses and the intangible benefits that you lay out are
| likely not that significant in the long term compared
| with the cost to build gccrs / modify Rust to accommodate
| gccrs. Of course, we're just arguing over opinions since
| it's so hard to quantify any of this.
| binary132 wrote:
| sounds like cope for the fact that there is not a good spec
| (a "Standard", perhaps?) tbh
| Longlius wrote:
| >it's a lot more debated these days
|
| By who specifically? I only ever see arguments against
| standardization and multiple implementations from the Rust
| community.
| duped wrote:
| Just personally I can see the virtue of multiple/different
| implementations. But the issue is building on top of gcc. The
| GNU toolchain is a dumpster fire, and I legitimately don't know
| how anyone can develop on it.
|
| Not just ideologically, I mean literally - I don't understand
| how one sets up a development environment for GCC itself. I've
| had the misfortune of bootstrapping it a handful of times and
| it's the single worst behaved piece of software I've ever seen.
| charcircuit wrote:
| >the Linux kernel is a key motivator for the project because
| there are a lot of kernel people who would prefer the kernel to
| be compiled only by the GNU toolchain.
|
| Linux can already be compiled with clang if you want an all LLVM
| based toolchain. The duplicate effort of developing and
| maintaining this does not sound worth it to have GNU "purity."
| mtrower wrote:
| I think you may be misunderstanding here. They aren't trying to
| keep the kennel GNU exclusive ---- they merely want the option
| for a pre GNU toolchain.
| thesuperbigfrog wrote:
| Rust needs a language standard:
|
| https://blog.m-ou.se/rust-standard/
|
| https://rust-lang.github.io/rfcs/3355-rust-spec.html
|
| https://github.com/rust-lang/rfcs/pull/3355
|
| There are many organizations and industries that will not adopt
| Rust until it has a standard.
|
| C, C++, C#, and even JavaScript (ECMAScript) have language
| standards. Why shouldn't Rust have one too?
|
| C: https://www.iso.org/standard/74528.html
|
| C++: https://isocpp.org/std/the-standard
|
| C#: https://learn.microsoft.com/en-us/dotnet/csharp/language-
| ref...
|
| JavaScript / ECMAScript: https://ecma-
| international.org/publications-and-standards/st...
| ajross wrote:
| Yeah. The culture crash here is shocking dissonant. The people
| you'd normally expect to be the biggest voices for
| documentation robustness are...
|
| ... suddenly finding themselves in the "Actually, language
| standards are bad" camp, all because of a tribal opposition to
| the FSF?
|
| Write the standard. Then argue that gccrust doesn't do it
| right. Don't refuse to document the language just to hamstring
| a competitor.
|
| Also, please start with the borrow checker semantics. I don't
| think I've ever met anyone who could explain exactly what the
| rules are regarding what it can/can't prove.
| estebank wrote:
| There's been active work on a Rust specification for a while
| now. It'll happen.
|
| https://blog.rust-lang.org/inside-rust/2023/11/15/spec-
| visio...
| Rusky wrote:
| What culture crash? The Rust project has a language
| reference, is working on expanding it into a more formal
| spec, and there are efforts like Ferrocene's to qualify the
| existing compiler for use in safety critical environments.
|
| The argument is not that language standards are bad, it's
| that a C++-like ISO standard is unnecessary (when the quality
| documentation can exist in another form) and C++-like
| implementation fragmentation is bad.
|
| (Have you read the NLL RFC? The Polonius work?)
| jen20 wrote:
| > There are many organizations and industries that will not
| adopt Rust until it has a standard.
|
| Counterpoint: rust is doing fine without those organizations
| and industries. Why change what is working well?
| yjftsjthsd-h wrote:
| If rust wants to replace memory-unsafe languages, it needs to
| cover their use cases.
| thesuperbigfrog wrote:
| >> Counterpoint: rust is doing fine without those
| organizations and industries. Why change what is working
| well?
|
| Because Rust is a game changer.
|
| Wouldn't it be better to have Rust used for the code that
| runs on automobiles and aircraft? Or you would prefer that
| they keep using (subsets of) C and C++?
|
| Is the security of your Internet-of-Things (IoT) devices good
| enough or could they be better?
|
| What do you have against Rust being used in more places and
| for more purposes?
| faitswulff wrote:
| Ferrous Systems has a basically bog standard Rust 1.68
| compiler that's been certified for use in the most safety
| critical environments: https://ferrous-
| systems.com/blog/officially-qualified-ferroc...
|
| This happened without a standard.
| thesuperbigfrog wrote:
| >> This happened without a standard.
|
| They created a specification for Ferrocene:
|
| https://spec.ferrocene.dev/
|
| While it is technically not a Rust language standard, it
| serves a similar purpose for Ferrocene.
| gkbrk wrote:
| Is it doing fine without those? It seems like every time
| someone makes a personal or professional project in C/C++,
| the Rust community floods the comments section and talks
| about how it's irresponsible to use C/C++ and how the author
| should just throw away the whole project and re-write it in
| Rust.
|
| It happens so often it became a meme at this point.
| sgift wrote:
| > It happens so often it became a meme at this point.
|
| No, the meme is kept alive by C++ people who say that this
| happens without it actually happen. It happened a long time
| ago a few times, since then it's either an active
| discussion about languages, where for some reason talking
| about Rust is a problem, but every other language is okay
| or it's someone feeling attacked by the mere idea that
| projects which only could be done in C++ could now also be
| done by another language and starts crying about how the
| Rust community would flood every topic.
|
| There's no longer an area where C++ is the only available
| option. Get over it. The rest of the world did a long time
| ago.
| mjw1007 wrote:
| That RFC is accepted, and this is starting to happen.
|
| Progress has been disappointingly slow, but the project is
| alive, and has potential to speed up next year.
|
| https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
| starlevel003 wrote:
| > That RFC is accepted, and this is starting to happen.
|
| > Progress has been disappointingly slow,
|
| I don't think there's ever been a more concise summary of
| Rust.
| gkbrk wrote:
| Go has a really nice spec and multiple implementations too.
|
| https://go.dev/ref/spec
| loeg wrote:
| Does any other go implementation support the full language? I
| thought gccgo lagged significantly.
| eikenberry wrote:
| The official GCC releases tend to lag a bit as they are
| released on a longer cadence than the standard Go compiler
| but upstream. The current release is a bit further behind
| than normal due to the complexities around implementing the
| generics back end, but it is being worked on
| (https://groups.google.com/g/golang-dev/c/5ZKcPsDo1fg).
| faitswulff wrote:
| Mara's blog post (your first link) says essentially that Rust
| does not need a standard since it already has means for adding
| features and maintaining compatibility.
| thesuperbigfrog wrote:
| Mara's blog post also describes the benefits of standardizing
| Rust.
|
| Since she created the RFC for standardizing Rust
| (https://github.com/rust-lang/rfcs/pull/3355) and is also on
| the team that is working on Rust standardization
| (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-
| visio...), I think she was making the point that Rust has
| good controls in place for adding features while
| compatibility, not that "Rust does not need a standard".
|
| If she really believed that Rust does not need a standard,
| why would she create the RFC and join the team working on the
| effort?
|
| Rust is a great language. There is no reason why it should
| not have a standard to better formalize its requirements and
| behaviors.
| faitswulff wrote:
| Yes, it's a nuanced blog post. But that also means it
| doesn't coming out swinging hard for needing a standard,
| either. It seems like there is as strong an argument to be
| made that "Rust is a great language. There is no reason why
| it needs a standard."
|
| See the Ferrocene compiler which has been qualified for ISO
| standards. It's essentially a standard Rust 1.68 compiler
| with a lot of added documentation. If you need a Rust
| compiler for safety critical environments, it's reasonably
| priced and requires essentially zero changes to the Rust
| compiler that they didn't just upstream. Without a
| standard.
|
| Yes, it would be nice to have a standard for reducing
| ambiguity. But does the language _need_ a standard? And if
| so, then for what purpose?
| thesuperbigfrog wrote:
| They created a specification for Ferrocene because Rust
| does not _yet_ have a language standard:
|
| https://spec.ferrocene.dev/
|
| >> But does the language need a standard?
|
| Yes, Rust needs a standard.
|
| >> And if so, then for what purpose?
|
| For the same purpose that all standards have--to formally
| define it in writing.
|
| Ferrocene's web site (https://ferrous-
| systems.com/ferrocene/) shows that it meets the ISO 26262
| standard (https://en.wikipedia.org/wiki/ISO_26262).
|
| Why does ISO 26262 matter? What purpose does it serve?
| Couldn't a vehicle manufacturer just say "our vehicles
| are safe"?
|
| Which would you trust more: a vehicle that is verified to
| meet ISO 26262 standards, or a vehicle whose manufacturer
| tells you "it's safe" without formally defining what
| "safe" means?
|
| I stated it above, but I will re-state it here: Without a
| language standard, there are many organizations and
| industries that _will not_ use Rust. Not because Rust is
| not a fantastic tool for the job, but because laws,
| regulations, etc. _require_ standardization and
| qualification of components.
|
| This means that I _can_ use a qualified C compiler and
| toolchain to write safety-critical code, but I _can 't_
| use Rust despite the fact that Rust is a better choice
| and will help to prevent problems. Standards _do_ matter.
| Rust needs a language standard.
| faitswulff wrote:
| > For the same purpose that all standards have--to
| formally define it in writing.
|
| This is tautological. It's equivalent to saying "it needs
| a standard to be written because it needs a written
| standard."
|
| I mean what use case is there for Rust language users
| that isn't already met by the Ferrocene project? And the
| Ferrocene project is not a standard as in "other
| implementations will be found lacking," but a description
| of the 1.68 compiler as-is. That is a specification, not
| a standard. Ferrous Systems did not need Rust to have a
| standard in order to qualify the compiler for ISO 26262
| and IEC 61508.
| thesuperbigfrog wrote:
| >> "it needs a standard to be written because it needs a
| written standard."
|
| Yes. And if the law in your country requires it to be
| standardized for specific use cases, then a language
| standard is needed.
|
| >> what use case is there for Rust language users that
| isn't already met by the Ferrocene project?
|
| Can you legally use Rust for the control software in
| aircraft? (https://en.wikipedia.org/wiki/DO-178C)
|
| What about the safety systems for railroads?
| (https://ldra.com/ldra-blog/software-safety-and-security-
| stan...)
|
| What about the control systems for nuclear reactors?
| (https://www.nrc.gov/docs/ML1300/ML13007A173.pdf)
| faitswulff wrote:
| And if you need a ISO 26262 qualified Rust compiler, one
| exists. Hurrah.
|
| Since you edited your post...simply having a standard
| won't immediately qualify the language for those
| industries. There is only a tenuous link between having a
| standard and qualifying the language for industrial use.
| ivanjermakov wrote:
| This is really odd to me. Language design should start with
| specification. Your compiler is just a reference
| implementation.
| sunshowers wrote:
| Rust language design does start from specifications, namely
| RFCs. What is being discussed here is producing a more formal
| specification than the ones that currently exist.
| pie_flavor wrote:
| The Ferrocene spec permits Rust to be used in those industries.
| johnklos wrote:
| So we'll finally see Rust support for all the architectures that
| gcc supports that LLVM doesn't, like Alpha, SuperH and VAX, for
| starters. That'll be nice!
| Asraelite wrote:
| I would assume it also means additional configuration options
| for already-supported architectures.
|
| For example, I recently discovered that with RISC-V, GCC
| supports the RV32E target but LLVM doesn't.
| monocasa wrote:
| Are you sure about that?
|
| I was pretty sure that llvm has supported RV32E for years
| now. https://reviews.llvm.org/D70401?id=395048
| Asraelite wrote:
| Oh, last time I checked clang didn't support it.
|
| In any case, there are a lot of other compiler flags that
| are exclusive to gcc.
| segfaultbuserr wrote:
| Can't wait to see some PDP-11 machine code from Rust (the last
| time I checked, freestanding C compiling still worked on GCC).
| gumby wrote:
| > A lot of care is being put into gccrs not becoming a "superset"
| of Rust, as Cohen put it. The project wants to make sure that it
| does not create a special "GNU Rust" language, _but is trying
| instead to replicate the output of rustc -- bugs, quirks, and
| all_.
|
| In my experience, the part in italics is a significant mistake.
|
| Rust does not have a specification; there is a reference but it
| is explicitly not normative. A language udocumented except for a
| single reference implementation (as is tpday's fashion) have a
| long term weakness. What is the motivation for slavishly trying
| to maintain compatibility with the bugs and accidental quirks of
| another implementation? To guarantee that existing code will work
| in both implementations, which sounds sensible. And it is a
| sensible goal, but it does so at enormous cost by enforcing it in
| the wrong place.
|
| The problem is that sometimes decisions are wrong, and sometimes
| bugs are written. But when you promise that all implementations
| will be bug compatible as part of compatibility you are also
| signing up to fossilize these bugs whether you want to or not.
|
| A good example of someone who embraced this (to their credit!) is
| Microsoft: they spend a lot of person-power making sure that old
| programs continue to run while trying to fix security and
| reliability bugs. Rust need not and should not sign up for this
| burden so early in its lifespan. They should learn from history.
|
| If they want the language to evolve they should embrace QA and
| QC. Famously "you cannot test quality into a product". You need
| QA: architecture, design, design and code reviews, etc to ensure
| that things will work properly and when not, that "failure heads
| in the appropriate direction". Then later in the development
| cycle QC (test cases) tries to see if you missed. This doesn't
| just apply to product development -- it applies to language
| development especially.
|
| The strong standards (e.g. ComonLisp, C++, FORTRAN) embraced this
| belief. The weak, de facto ones (Most notably Python, but plenty
| of others) can still become popular, but change is difficult.
| Look at how long the Python 2->3 transition took, and how few
| python implementations there are.
| mkesper wrote:
| Thanks for posting the lwn.net link, reminded me of renewing my
| subscription!
| sophacles wrote:
| It's a good subscription to have. I've gotten far more value
| from my LWN subscription than I spent, and recommend everyone
| that does lowish level work get one.
___________________________________________________________________
(page generated 2023-12-18 23:00 UTC)