[HN Gopher] GCC Rust: GCC Front-End for Rust
___________________________________________________________________
GCC Rust: GCC Front-End for Rust
Author : varbhat
Score : 195 points
Date : 2021-01-10 15:19 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jeltz wrote:
| There is another project for implementing a GCC backend for Rust
| which instead uses the libgccjit API.
|
| https://github.com/antoyo/rustc_codegen_gcc
| anticensor wrote:
| They missed the opprtunity to name it as _grust_.
| codetrotter wrote:
| Gust of wind
| anticensor wrote:
| grust, not gust
| codetrotter wrote:
| I know. What I mean is that gust of wind would be even
| better.
| dleslie wrote:
| This is excellent; there's embedded targets that LLVM doesn't
| officially support and GCC does.
| mhh__ wrote:
| GCC is straight up faster in quite a few benchmarks (it's
| basically neck and neck in most benchmarks, and you should try
| both if it matters).
|
| GCC is also roughly even in compilation speed now
| https://www.phoronix.com/scan.php?page=news_item&px=GCC-Fast...
|
| LLVM is much easier to work with internally but GCC is a
| seriously good compiler even now.
| potatochup wrote:
| Does this mean that compilation target currently supported by GCC
| would now allow rust to target that architecture? Specifically
| I'm thinking of PPC cores with the VLE extension, which LLVM does
| not support (as far as I'm aware).
| volta87 wrote:
| llvm does support ppc64le cores with VSX extension; if thats
| what you mean
|
| in fact, IBM uses LLVM proper as its own compiler backend for
| its ppc processors
| ognarb wrote:
| This is very cool, maybe this could push the rust community to
| have a formal specification and a stable ABI in the future.
| steveklabnik wrote:
| The work on a spec is already going as fast as it reasonably
| can be.
|
| A stable ABI is unclear.
| rectang wrote:
| Glad you're going slow on the stable ABI and resisting the
| pressure to put out something half-baked. The C++ ABI is
| horribly fragile and complex. Unless the pitfalls of C++ can
| be avoided, making no ABI promises is better.
| tumdum_ wrote:
| No stable ABI makes distributing shared libraries harder :/
| chubot wrote:
| If you want to distributed stable shared libraries, you
| write to the C ABI, not the C++ ABI.
|
| Likewise Rust users should write to the C ABI for stabled
| shared libraries. (I believe there are a bunch of
| mechanisms to do that, though I'm not really a Rust user)
|
| For example look at what KDE does: https://community.kde.
| org/Policies/Binary_Compatibility_Issu...
|
| Yes, you have to do a lot of extra work. That's working
| as intended.
|
| It's sort of an oxymoron to expect to use every C++ or
| Rust feature in your user-facing ABI and have it be
| stable. They are incredibly rich languages, with
| drastically different notions of "function" than C has
| (let alone other constructs like data layout)
| steveklabnik wrote:
| (There are mechanisms to do this, yes)
| IshKebab wrote:
| Yes you should do that _now_ but only because Rust doesn
| 't have a stable ABI. If/when it does then there's
| nothing wrong with distributing shared libraries using
| the Rust ABI, just like there isn't really anything wrong
| with doing it in C++ nowadays as long as you don't use
| bleeding edge C++ stuff. The C++ ABIs are pretty stable.
| chubot wrote:
| _there isn 't really anything wrong with doing it in C++
| nowadays as long as you don't use bleeding edge C++
| stuff_
|
| That's the whole point of the KDE doc I linked. It's not
| a reasonable strategy to use unrestricted C++, just like
| it's not a reasonable strategy to use unrestricted Rust.
| You actually have to design an ABI, not just rely on the
| compiler to do it for you.
|
| I thought there was a GNOME doc too, but I couldn't find
| it. The point remains: there are lots of things in C++
| that people who care about stability don't use at their
| ABI boundaries.
| steveklabnik wrote:
| Everything is tradeoffs. Stable ABI can also lead to
| other issues, like performance problems. C++ is dealing
| with some of these right now, and there are some
| situations (very very micro benchmarks, to be clear)
| where Rust is faster than C++ due to ABI issues.
| Blikkentrekker wrote:
| Does it not already have them if the programmer elect for it
| by choosing `repr(C)`, or is there more to it than that?
| steveklabnik wrote:
| You are exposing an imprecision in the way that this is
| usually talked about, yes. If you are willing to use the C
| ABI, then you can use a combination of that repr and
| annotations on your functions and produce a shared object
| in Rust with a stable ABI.
|
| What people _usually_ mean here is that Rust would have its
| own stable ABI, that you would get "for free," without
| needing to do that work. (It's never actually free of
| course... but that's yet another detail that is usually
| papered over when people talk about this.)
| wiz21c wrote:
| from the readme :
|
| > The developers of the project are keen "Rustaceans" with a
| desire to give back to the Rust community and to learn what GCC
| is capable of when it comes to a modern language.
|
| So what's the answer right now ? How does GCC measures "against"
| rust ?
| pjmlp wrote:
| Given the amount of existing frontends for GCC, even if not
| included in the main branch, not sure what they imply as
| modern.
|
| Ada, D, Go, Modula-3, Modula-2, C++20
| vips7L wrote:
| RIP gcj.
| bonzini wrote:
| Front-end-independent optimizations are still slightly better
| in GCC than in LLVM.
| yorwba wrote:
| The timeline looks rather ambitious https://github.com/Rust-
| GCC/gccrs/milestones
| unanswered wrote:
| It also looks rather incomplete. Are they not planning on
| implementing borrowck? If chalk/polonius were ready and had a C
| API the roadmap would begin to make sense.
| Nullabillity wrote:
| Makes sense to me. As mrustc[0] mentions, implementing
| validation in a secondary compiler is much less important,
| because you can always just run the reference implementation
| as a glorified linter in the meantime.
|
| [0]: https://github.com/thepowersgang/mrustc
| mhh__ wrote:
| I suspect it's too late, but one lesson that can be learned from
| D is that having one frontend implementation with multiple
| backend glue layers is much more convenient than having one in D
| and one in C++ (I believe Iain Buclaw is in the process of moving
| the D frontend in gcc to use the proper D one as it's been
| lagging behind)
| steveklabnik wrote:
| There are pros to that approach, but also cons. The major con
| is that keeping the rustc frontend would make an existing Rust
| compiler be a requirement, and not having that makes
| bootstrapping easier, which is a major pro.
|
| This (among other things) was debated a _lot_.
| mhh__ wrote:
| > The major con
|
| A major con of not sharing is not having a backend at all.
| It's a lot of work to keep up with a moving target
| faitswulff wrote:
| I'm not sure if what I'm asking makes sense, but since it's
| written for a new backend, would the authors have to bootstrap it
| using a different toolchain? I guess what I'm asking is, could
| they use the LLVM Rust to build the GCC frontend or do they have
| to start all over with a different base language to get a first
| working version of a rust compiler?
| gumby wrote:
| It's not written in rust; gcc is written in c. There is no
| bootstrapping involved.
| Narishma wrote:
| C++ but yes.
| NieDzejkob wrote:
| GCC is no longer written in C, but in C++. They switched
| after GCC 4.7.
| saagarjha wrote:
| Of course, much of the code is still C.
| faitswulff wrote:
| Do gcc languages - even low level ones - remain written in c?
| pjmlp wrote:
| Besides the Ada example, GDC shares the D frontend, written
| in D, with other D implementations.
| guerby wrote:
| The GCC Ada frontend is written in Ada:
|
| https://gcc.gnu.org/wiki/GNAT
|
| There is also a port of the Ada frontend to LLVM backend:
|
| https://github.com/AdaCore/gnat-llvm
| singron wrote:
| As far as I can tell, this is written in C++ like the rest of
| GCC, so they don't need a rust compiler to bootstrap.
| faitswulff wrote:
| I see, so it's written in C++. Would it remain that way,
| though? AFAIK the LLVM Rust is, itself, written in Rust,
| right? I imagine that it would be a goal to do the same for
| gcc.
| pjmlp wrote:
| It could take the same approach as GDC and GNAT, by having
| the frontend written on the same language (D and Ada
| respectively), shared with other implementations using
| another set of backends.
| [deleted]
| strongdenial wrote:
| There is absolutely no reason why the GCC front-end needs
| to be written in Rust. The reason the LLVM front-end was
| written in Rust initially was so they could immediately
| test and use new features in what was at the time also the
| largest program in Rust. Re-writing the GCC front-end in
| Rust would just prolong an already rather unfortunate
| bootstrap problem with the language and it should be
| strongly discouraged.
|
| As it stands, the way to bootstrap the official Rust
| compiler from source with just a C/C++ compiler is a few
| options:
|
| * Compile OCaml (implemented in C), use it to build the
| original Rust front-end in OCaml and then build each
| successive version of the language until you hit 1.49. This
| option is not fun.
|
| * Compile mrustc, which is a C++ implemented compiler that
| supports Rust 1.29. Use that to build the actual Rust 1.29
| and then iterate building your way all the way to 1.49.
| That is less bad, but still not fun.
|
| * Compile the 1.49 compiler to WASM and run it via a C/C++
| implemented runtime in order to compile itself on the
| target system. This would also mean packaging and
| distributing the WASM generated code, which some
| distributions would refuse. I also am not sure if it's even
| currently feasible, as I don't follow the WASM situation
| closely.
|
| A compliant, independent C++ implementation that could be
| built in the ten minutes it takes to build GCC itself would
| be a very good thing to have and would be more friendly to
| distribution maintainers.
| Null-Set wrote:
| I don't see why a wasm blob would be any more palatable
| to maintainers than an executable.
| strongdenial wrote:
| Like I mentioned in my post, it wouldn't be for some
| depending how serious they take things. I'm well aware
| many would refuse generated artifacts, even compiled to
| source artifacts. For others not so strict, they may
| accept it since the WASM blob would be the same across
| targets, unlike an executable, so it lessens a burden as
| maintainers only have to generate it once for their
| distribution. It was never something I suggested the Rust
| maintainers provide a blob for, either.
|
| Regardless, it was worth mentioning as a potential
| option. I am one of the handful of maintainers for an
| experimental distribution where packages are either
| compiled or interpreted from tarballs and this would be
| something we'd consider. I'd MUCH rather have the GCC
| front-end option, however. So far, we've simply not
| packaged Rust and have accepted that as dead-ending our
| Firefox package. This may potentially revive it.
| varajelle wrote:
| > There is absolutely no reason why the GCC front-end
| needs to be written in Rust.
|
| How about memory safety and fearless concurrency?
| Guvante wrote:
| No one is saying that rustc should be rewritten in C.
| They are saying that an alternative compiler front-end in
| an alternative language is sensible.
| strongdenial wrote:
| Not a requirement for a GCC front-end and certainly not
| worth sacrificing a potentially faster path to
| bootstrapping the official compiler implementation. You
| should be worried about the ease by which various systems
| can bootstrap and adopt the language, which is a mostly
| solved problem for C/C++ but not a given for Rust itself.
| Some maintainers will absolutely refuse bootstrapping off
| of binary artifacts compiled from other systems, others
| won't even accept 'compiled to C' artifacts.
|
| Keeping a viable C++ implementation as part of GCC would
| be the smartest decision.
| CameronNemo wrote:
| Who are these groups who are demanding such easy
| bootstrapping? OS or distro developers? Programmers
| working on embedded and/or safety critical systems?
|
| I know OpenBSD avoids rust because of the bootstrapping
| issue, but they also avoid LLVM because of a licensing
| issue.
| bonzini wrote:
| A compiler front-end is pretty boring software in terms
| of memory safety. Lots of things that the front-end
| allocates are simply never freed.
|
| Have you ever seen GCC crash with a SIGSEGV? I rarely did
| even when I used to be a GCC developer.
| pm215 wrote:
| Indeed. Notoriously, a SEGV in gcc during compilation
| used to usually mean "your hardware is flaky":
| https://tldp.org/FAQ/sig11/html/index.html
| jjnoakes wrote:
| There are still out-of-bounds concerns and chasing
| through NULL pointers. (Not arguing against gcc's quality
| or stability, just listing memory safety concerns that
| transcend memory deallocation)
| rjsw wrote:
| I guess you could rewrite it in a language with no
| implementation at all if you are worried about purity.
| oconnor663 wrote:
| The LLVM-based Rust compiler uses a lot of unstable/nightly-
| only Rust features internally. So even if this project got to
| the point where it could compile all stable Rust programs, I
| think it would take quite a bit more work than that to be able
| to compile `rustc` itself. (It might be that the unstable stuff
| is mostly in the standard library and not the compiler itself?
| Does it make a difference?)
| steveklabnik wrote:
| > It might be that the unstable stuff is mostly in the
| standard library and not the compiler itself? Does it make a
| difference?
|
| It might. There are at least two major things off the top of
| my head, regarding libstd:
|
| 1. specialization is needed for performance around String and
| &str
|
| 2. const generics are needed to support some trait
| implementations
|
| We currently allow some stuff like this to leak through, in a
| sense, when we're sure that we're actually going to be making
| things stable someday. An alternative compiler could patch
| out 1, and accept slower code, but 2 would require way more
| effort.
|
| There has been some discussion about trying to remove
| unstable features from the compiler itself, specifically to
| make it easier to contribute to, but it unlikely that it will
| be completely removed from the current implementation of
| libstd for some time.
| [deleted]
| cbmuser wrote:
| Isn't mrustc already able to compile rustc?
| steveklabnik wrote:
| Yes.
| rcxdude wrote:
| If it was written in rust, there's no reason they couldn't use
| LLVM rust to start development until it became self-hosting.
| (Same as you can develop a self-hosting C compiler by starting
| with gcc)
| Ericson2314 wrote:
| A bit off topic, I hope someday GCC's build system gets
| overhauled. A huge advantage of LLVM is that it is quite easier
| to rebuild the runtime libraries without rebuilding the compiler.
| With GCC that's a pain, unless one takes the time to re-package
| GCC very carefully like https://github.com/richfelker/musl-cross-
| make and https://exherbo.org/.
|
| Maybe getting some new GCC devs in there with projects like this
| would help with that?
| ibraheemdev wrote:
| There was a thread posted on the rust forum a while back that
| laid out the goals of this project [0]:
|
| > A friend of mine (Luke) has been talking about the need for a
| Rust frontend for GCC to allow Rust to replace C in more places,
| such as system software. To allow some types of safety-critical
| software to be written in Rust, the GCC frontend would need to be
| an independent implementation of Rust, since the relevant specs
| require multiple independent implementations (so just attaching
| GCC as a new backend for rustc wouldn't work).
|
| Luke:
|
| > The goal is for the GNU Compiler Collection to have a peer
| level front end to the gfortran frontend, gcc frontend, g++
| frontend and all other frontends.
|
| > The goal is definitely not to have a compiler written in rust
| that compiles rust code [edit: unless there is an acceptable
| bootstrap process, and the final compiler produces GNU assembly
| output that compiles with GNU gas]
|
| > The goal is definitely not to have a hard critical dependence
| on LLVM.
|
| > The goal is to have code added, written in c, to the GNU
| Compiler Collection, which may be found here https://gcc.gnu.org
| 20 such that developers who are used to gcc may compile rust
| programs and link them against object files using binutils ld.
|
| > The primary reason why I raised this topic is because of an
| experiment permitting rust modules to be added to the linux
| kernel: https://lwn.net/Articles/797828
|
| > What that effectively means if that takes off is that the GNU
| Compiler Collection, which would be incapable of compiling that
| code, would be relegated to a second class citizen for the
| purposes of compiling the largest software project on the planet:
| the linux kernel.
|
| > Thus it is absolutely critical that GCC be capable not just of
| having rust capability but of having up to date rust capability.
|
| 0: https://users.rust-lang.org/t/call-for-help-implementing-
| an-...
| [deleted]
| Blikkentrekker wrote:
| Is a great deal of actual _Rust_ behavior not fairly intimately
| tied to _LLVM_? As far as I know it leaks various _LLVM_ details
| and much of the documentation about various functions documents
| them as being little more than a thin wrapper to various _LLVM_
| internals.
| monocasa wrote:
| I don't think much of the stable functionality exposes llvm
| internals. Part of stabilizing is removing the llvm leaks into
| the language.
| steveklabnik wrote:
| IMHO, "great deal" is overemphasizing it. There are some
| things, yes, but they are mostly smaller, more niche details
| that are even probably things we'd choose ourselves in many
| cases.
|
| That being said, there's also cases where Rust does _not_ have
| LLVM semantics, and that can cause bugs. Some famous examples
| being the loop optimization miscompilation, and &mut T
| currently not being marked noalias.
| masklinn wrote:
| > Some famous examples being the loop optimization
| miscompilation, and &mut T currently not being marked
| noalias.
|
| I don't think that's a case where Rust "doesn't have LLVM
| semantics" since the miscompilation was reproduced in
| standard C. Rather that rust is actively and _ubiquitously_
| leveraging otherwise rarely-exercised LLVM features,
| revealing a bunch of bugs (either leftovers or breakages) in
| them.
| steveklabnik wrote:
| The latter, you're right, I did make a mistake here. I was
| thinking of it as "Rust doesn't just do whatever LLVM does,
| see, we have semantics and LLVM compiles them wrong, so
| this is an example of that" but I forgot that actually, we
| _do_ specify "this follows what LLVM does" currently, and
| the miscompilation is just a plain bug. Extra embarrassing
| because IIRC I was the one who made the PR saying that.
|
| The former though is an area of significant divergence
| between Rust and C++ semantics, and LLVM directly following
| C++ semantics.
| masklinn wrote:
| > The former though is an area of significant divergence
| between Rust and C++ semantics, and LLVM blindly
| following C++ semantics.
|
| Ah I must have missed that, I thought you were talking
| about only one thing (since IIRC the noalias
| miscompilation is due to loop unrolling?)
| jdoerfert wrote:
| FWIW, `noalias`, aka. `__restrict__`, generally works
| fine but the inliner translates it into `noalias`
| metadata which is, still, ambiguous and also not handled
| properly in some cases. Loop unrolling is one of them but
| that will be fixed with https://reviews.llvm.org/D92887,
| a general problem is the ambiguity itself.
|
| There is a major effort to revamp the
| `noalias`/`restrict` handling going on for a while now.
| It takes quite long because it is hard and complex and we
| want to get it right.
|
| In case you are interested, here is the new design https:
| //reviews.llvm.org/differential/changeset/?ref=2170825
| here the overall code changes currently considered
| https://reviews.llvm.org/D69542 and here you can find
| information on our monthly LLVM Alias Analysis call https
| ://docs.google.com/document/d/1ybwEKDVtIbhIhK50qYtwKsL5..
| .
| steveklabnik wrote:
| I don't know the root cause of the noalias
| miscompilation, the thing I was referring to is
| https://github.com/rust-lang/rust/issues/28728
|
| TL;DR: C++ says that an infinite loop with no side
| effects is UB, Rust does not. Empty loops in Rust will
| disappear entirely when they should really loop forever.
|
| (I edited my comment slightly because, re-reading,
| "blindly" sounds too negative.)
| davidhyde wrote:
| Great point! If anyone is curious about how to write an
| "empty" loop that is not compiled away, I've seen this
| common implementation that doesn't even need the standard
| library:
|
| loop {
|
| core::sync::atomic::compiler_fence(
| core::sync::atomic::Ordering::SeqCst);
|
| }
| volta87 wrote:
| Notice that in C and C++ loops that might not terminate are
| UB, while in Rust they are just infinite loops.
|
| So there is a significant difference in semantics between
| Rust and C/C++ here.
| saagarjha wrote:
| C and C++ actually differ in semantics here; C allows
| infinite loops that are controlled by a constant
| expression.
| dagmx wrote:
| Potentially but there are alternative backends like cranelift
| so it's unlikely anything major is tied to just LLVM anymore
| chrisseaton wrote:
| I'd find that very surprising and interesting - I can't imagine
| which semantics could leak from LLVM into a language
| specification. Can you give some examples?
| Blikkentrekker wrote:
| For instance `std::ptr::offset` which is apparently a trivial
| wrapper around some _LLVM_ internal:
| https://llvm.org/docs/LangRef.html#getelementptr-instruction
|
| I'm not sure as to what capacity _GCC_ has a similar
| instruction but I heard that _LLVM_ 's using of signed
| integers here is apparently nonstandard and what lead to
| _Rust_ 's decisions for vectors to be limited to a certain
| size: https://doc.rust-lang.org/nomicon/vec-alloc.html
| chrisseaton wrote:
| getelementptr is just some pointer arithmetic - all
| backends can do that.
|
| And using signed integers is unusual yes, but again all
| backends (obviously) also support signed integers.
| steveklabnik wrote:
| IMHO, "Just some pointer arithmetic" is selling it a
| _bit_ short. There 's a lot of stuff there around
| provenance that matters, that is, there's a reason this
| is an intrinsic and not just a subtraction after casting
| both to an int.
|
| (I agree on the signed integer thing though.)
| stouset wrote:
| I don't know why you're italicizing LLVM, gcc, and Rust,
| but I (and perhaps others) find it relatively jarring as my
| brain automatically parses it as emphasis even though it
| clearly isn't intended to be.
|
| I only bring it up because it pretty drastically harms
| readability (for me at least, and to a degree I frankly
| find surprising). Just thought you may want to know.
| samb1729 wrote:
| Looking at their commenting history, they have a habit of
| italicising really often, so it's not specific to this
| topic. It does indeed make a lot of their comments
| annoying to read without obviously adding any value.
| codetrotter wrote:
| > It does indeed make a lot of their comments annoying to
| read without obviously adding any value
|
| I'm going to assume that you mean that _the italics_
| don't add value, and not their comments as a whole. I
| think your comment could be read either way. Anyways,
| even so others have since pointed out reasons why the
| might be used to doing so.
| Blikkentrekker wrote:
| This is indeed a point of contention among different
| styles of whether software titles should be italicized.
| Though the position that they should uniformly be is the
| minority one, it is certainly used by some outlets with
| considerable weight, and I believe it to be the
| consistent one if titles of books and films are too.
|
| Some style guides make the even more inconsistent
| distinction that only titles of video games be
| italicized, but titles of "application software" not be.
|
| I suppose that on _H.N._ , where such software is
| frequently mentioned, it does stand out more.
| unanswered wrote:
| The video games example seems consistent to me; we
| regularly italicize the names of plays (for example) but
| not the names of tools and businesses.
| Blikkentrekker wrote:
| Because tools and businesses are not titles that qualify
| for intellectual property, a piece of software is.
|
| I do not italicize Google the company either, but I do
| that of _Google_ the search engine.
|
| The titles of scientific research papers are also
| typically italicized.
| tssva wrote:
| Maybe he is used to writing in MLA style which calls for
| the titles of software to be italicized just as books,
| movies, etc are.
| balnaphone wrote:
| This is common nomenclature to enhance readability in
| fields that have a large number of neologisms and proper
| nouns, such as some technical domains, medicine,
| investment banking, and so on. It's particularly useful
| when names are in the same language as the base language
| (e.g. in English "Peter" is easily recognized as a name,
| but "better fish" means something in the language, but
| can also be used as a proper noun, so using italics for
| proper nouns serves to disambiguate the intended
| meaning).
| [deleted]
| CUViper wrote:
| Glibc malloc also limits the maximum according to
| ptrdiff_t, which is effectively the same as Rust isize.
| vlovich123 wrote:
| What I really hope is that the Rust community doesn't go out of
| its way to make this easier. Communicate and let value come back
| but there's an significant amount of value in keeping a single
| backend relies on. CPython has done the Python community a lot of
| good by keeping one official compiler/tool chain (despite the
| great work done by projects like JPython/PyPy).
|
| The only way to do this properly, if desirable, is to make GCC an
| official backend of the main frontend. That will defocus some
| progress that happens with LLVM (every feature has to be
| implemented on both backends) and can make dev lives hard (eg "oh
| this problem comes up with GCC so use the LLVM backend "). The
| value would be if the majority of bugs/features are in the shared
| frontend.
|
| This project though seems like a parallel implementation of Rust.
| That's valuable for the community and inevitable as a part of
| successful growth. I don't believe it's beneficial to the
| community though if this grows beyond a toy, niche project.
| steveklabnik wrote:
| The general sentiment of the community and leadership is that
| this project is a good thing, so you are unlikely to get your
| wish.
| [deleted]
| thesuperbigfrog wrote:
| >> The only way to do this properly, if desirable, is to make
| GCC an official backend of the main frontend. That will defocus
| some progress that happens with LLVM (every feature has to be
| implemented on both backends) and can make dev lives hard (eg
| "oh this problem comes up with GCC so use the LLVM backend ")
|
| No. The correct way is to create a Rust language specification
| that describes what the correct behavior is.
|
| Then whether LLVM, GCC, or something else is used does not
| matter. There won't be one implementation with defacto
| behavior, there will be multiple implementations that follow
| the spec.
|
| This is the way mature languages work.
| Blikkentrekker wrote:
| Such standardized specifications are typically a response to
| many divergent implementations existing and a need to
| standardize a common ground between them.
|
| Few languages find such specification before that time.
|
| _Python_ also lacks it despite some competing
| implementations, since none actually diverge enough from
| _CPython_.
| not2b wrote:
| It doesn't even have to stop progress. C++ does a new rev of
| the standard every 3 years. Rust has editions, which is a
| similar but less rigorous concept, and which could be made
| more rigorous.
| thesuperbigfrog wrote:
| Exactly. The C++ standard (https://isocpp.org/std/the-
| standard) is the specification that describes what a
| compiler must do to implement a particular "version" of C++
| (for example, C++ 20).
|
| Just as there is a C++ standard and multiple C++ compilers
| that implement the standard, there should be a Rust
| standard and multiple implementations.
|
| This is the way that mature languages work.
| steveklabnik wrote:
| This is the way that _very few_ languages work. Python is
| a great example of an extremely popular, mature language
| that does not work this way. It is unclear that most
| people think that this sort of process is required for
| "maturity."
|
| If this is the benchmark, then among popular languages
| you basically have C, C++, C#, JavaScript, and... is that
| it?
| zabzonk wrote:
| I wouldn't say it's a benchmark, but surely Pascal,
| Fortran and COBOL (to name but three) are all
| standardised?
| IainIreland wrote:
| In a past life I worked on a COBOL compiler for IBM.
|
| There is a COBOL specification, but AFAIK nobody actually
| implements it fully. Implementations pick and choose new
| features based on customer demand.
|
| Also, COBOL is dominated by large legacy codebases, which
| means that if there's a discrepancy between an
| implementation and the specification, the users normally
| don't want it fixed, because they may have written code
| that depends on the "incorrect" behaviour and it's a lot
| of work to audit.
|
| IBM built a new backend for its COBOL compiler using the
| optimizer from their JVM. IIRC by the time I left it
| generated code that was ~2x faster than the old compiler,
| but uptake was still slow because of migration concerns.
| In particular, we spent a lot of time working on features
| to help guarantee that code with some forms of undefined
| behaviour would have the same result as the old version.
| steveklabnik wrote:
| There are more languages that have standards, sure, but
| the languages you mention, at this point, and in general,
| are mostly relegated to historical maintenance and maybe
| some very specific niches. To me personally, a "mature"
| language that's not really being used isn't the goal. And
| if developers truly believed standardization was
| valuable, you'd expect this property to give them a
| significant leg up against the sorts of languages like
| Ruby, Python, PHP, Perl, TypeScript, etc.
|
| That being said, I do think, considering it longer, there
| are languages that I am missing, like SQL, and ones that
| have a spec, even if it's not under an ECMA/ISO process,
| like Java and Go, that I was forgetting.
|
| I still think that using this as a necessary condition
| for "maturity" is misguided.
| zabzonk wrote:
| Well, I agree that standardisation and "maturity"
| (whatever that may mean) are not connected, but I think
| most C and C++ programmers (to name two very widely used
| languages that I personally have a lot of knowledge of)
| find the respective standards for those languages very
| helpful, and somewhat lament the lack of formal standards
| for other languages they may use.
| steveklabnik wrote:
| Yes. I do think that standardization is generally good. I
| am pro Rust getting a specification! I just think it is
| one pro among many, and not something required for
| success.
| simias wrote:
| Remember that Rust is supposed to be an alternative to C or
| C++, where the "this problem comes up with GCC so use the LLVM
| backend" is really rare and generally a sign of a bad codebase
| (exceptions being things like the Linux kernel that are so
| huge, optimized and domain-specific that they often end up
| relying on compiler dialects).
|
| One exception to this is Visual Studio's toolchain but let's
| not talk about Visual Studio's toolchain on a weekend...
| pjmlp wrote:
| Yeah, when one forgets that there are more C and C++
| compilers out there in the industry than just the pair that
| the FOSS community cares about.
| not2b wrote:
| Strongly disagree. It will only benefit the language to have
| more than one quality implementation. C++ has benefited hugely
| by the competition between g++ and clang; both compilers have
| gotten much, much better. To be fair, it will take a while
| before the GCC Rust front end is competitive, but for some
| purposes it doesn't have to be, like bootstrapping.
|
| If "progress" means "rapidly add more and more new features in
| each release", multiple implementations will slow things down.
| But that problem can be addressed with editions: at some point,
| if the project is a success, the gcc front end will be a
| feature-complete version of some Rust edition, plus enough
| extra features to build an older version of the Rust compiler.
| At that point, you have a better solution to the bootstrapping
| problem (how to get a Rust compiler when you only have a C
| compiler and you want to build everything from source and not
| trust some binary you download from somewhere).
| jcelerier wrote:
| > C++ has benefited hugely by the competition between g++ and
| clang; both compilers have gotten much, much better.
|
| yet rust has a single implementation and by some metrics does
| better than both.
| pjmlp wrote:
| Compilation speed isn't one of them though.
| turminal wrote:
| >If "progress" means "rapidly add more and more new features
| in each release", multiple implementations will slow things
| down
|
| This has to happen at some point anyway otherwise we'll just
| get another C++. And I don't think Rust would benefit from
| that. New languages are designed to fix problems with the old
| ones, not to replicate them after all.
|
| I just hope the designers will choose that point wisely.
| pjmlp wrote:
| In some extent, given the use of macros and Haskell like
| libraries, it is already another C++.
|
| Besides, if Rust doesn't become another C++, it won't
| fulfil the industry needs that C++ caters for, thus while
| it might become a success in some domain, it won't replace
| C++ in the OS and GPGPU SDKs.
| turminal wrote:
| Having multiple independent implementations (and a spec) is key
| to being a serious portable systems language, a claim that Rust
| already makes. I believe it's too early for that, but sincerely
| wish them success achieving those goals in the future and
| having multiple implementations is certainly going to help
| here.
|
| > eg "oh this problem comes up with GCC so use the LLVM backend
| "
|
| The point of having multiple implementations is making the
| language independent of the underlying system. A programming
| language is an abstraction. The only way to test whether an
| abstraction is a good one is trying out how well it abstracts
| away various underlying systems. That's why Rust needs ports to
| various architectures, OSes and compiler backends. Having GCC
| as a backend counts double here, because you get a few new
| target architectures for free with the port not just a new
| backend.
|
| It's of course much different with Python but I can still
| clearly see how having an implementation defining a standard
| hurts the language.
___________________________________________________________________
(page generated 2021-01-10 23:00 UTC)