[HN Gopher] I Support GCC-Rs
___________________________________________________________________
I Support GCC-Rs
Author : lukastyrychtr
Score : 55 points
Date : 2021-06-07 17:06 UTC (5 hours ago)
(HTM) web link (chorman64.medium.com)
(TXT) w3m dump (chorman64.medium.com)
| NextHendrix wrote:
| >I can choose the compilers I want to support based on the
| available features and compliance with the standard.
|
| >I support GCC-Rs
|
| What standard will you hold it to with rust, afaik there isn't
| one.
| gspr wrote:
| It's covered in the first few entries in the FAQ:
| https://github.com/Rust-GCC/gccrs/wiki/Frequently-Asked-Ques...
| duped wrote:
| The conversation over gcc-rs online has always seemed weird to
| me. These are open source projects that aren't really competing
| for the same resources, people are free to work on what they find
| interesting and everyone should support their freedom to do so.
|
| That said I think if you had money involved it would be better
| spent creating LLVM backends than porting yet another language to
| gcc. I'm not sure "this is time consuming to bootstrap from gcc
| 4" is a compelling enough argument, at least nowhere near
| compelling as "this programming language cannot target these
| processor families because the backend doesn't exist and no one
| has the time to write one."
| int_19h wrote:
| For the curious, here's the comment that it seems to be
| referencing:
|
| https://www.reddit.com/r/rust/comments/njckp1/rustc_codegen_...
|
| That comment does have many valid points. Note that the issue at
| hand isn't whether an alternative implementation of the compiler
| is viable at all, but rather whether an alternative _front-end_
| (i.e. parsing, type checking etc) is desirable. I have to admit
| that I don 't really see any advantages to having multiple
| frontends, when the one that's already there is open source under
| a permissive license.
| User23 wrote:
| Isn't a big part of why SBCL exists because CMUCL had a similarly
| gnarly bootstrapping sequence?
| epage wrote:
| As someone who has had to deal with legacy C++ compilers from
| multiple platforms, I didn't have the luxury of dropping
| compilers I didn't like but instead had to program to the lowest
| common (working) denominator of those frontends.
|
| For a frontend to be taken seriously, I see the following
| questions needing to be addressed:
|
| - How long until the frontend is viable?
|
| - What will it take to keep the frontend is viable?
|
| - How far will each frontend lag in shipping lang/lib features?
|
| - What is the relative user upgrade cadence of each frontend?
|
| - How do developers test multiple frontend versions?
|
| - How do developers workaround frontend bugs?
|
| - How do we communicate out frontend support for crates,
| especially if crate authors take the approach of this person and
| drop support as they become a problem for them?
|
| A GCC backend for rustc is a smaller, well scoped target that can
| more easily be kept up-to-date (I would hope, upstreamed in Rust)
| that resolves a lot of the pressing needs (platform support).
|
| For any finite resource allocation, I see getting a GCC backend
| to be a priority for quick wins and then focus on gcc-rs as an
| experimental hedge against future problems.
| Narishma wrote:
| > For any finite resource allocation, I see getting a GCC
| backend to be a priority for quick wins and then focus on gcc-
| rs as an experimental hedge against future problems.
|
| Doesn't that only work if it's the same people working on all
| those things? AFAIK, it's different people doing the different
| projects. You can't just re-assign open-source developers
| however you want.
| CUViper wrote:
| You can't directly re-assign those developers, but you can
| try to influence their decisions. It's not only about the
| current developers either, but also potential new
| contributors that may be considering either project.
| choeger wrote:
| We need stable and free infrastructure. It is unfortunate how few
| people realize what GCC does for everyone. It certainly ain't
| perfect, but imagine we only had clang/llvm. Llvm regularly
| breaks the API and cannot be bootstrapped, AFAIK. Without GCC, I
| doubt we had android, or capable cheap routers, the whole python
| and node.js ecosystems would be in a completely different
| situation, and we would permanently facing the threat of
| propiatary languages. I support rust in GCC, too (and I am glad
| that they also have Go support).
| TazeTSchnitzel wrote:
| > LLVM [...] cannot be bootstrapped
|
| How? Can't you compile it with GCC?
| mjw1007 wrote:
| Thinking about the dangers of subtle incompatibilities, I think
| the existence of crater[1] could make a huge difference, once
| alternative implementations are far enough along.
|
| Arguably the nearest thing to a specification for the Rust
| language at present is "what crater would be happy with".
|
| That seems more useful than thinking of rustc as a reference
| implementation, because when I read the release notes every now
| and again they say things to the effect of "this change is
| technically backwards-incompatible but crater reassures us that
| it won't cause anyone any trouble".
|
| [1] https://github.com/rust-lang/crater
| kevincox wrote:
| > mrustc is not the solution [...] as it's only capable of
| building rustc 1.39
|
| This seems like an odd point. Instead of updating mrustc to
| support a couple of more features every once and a while we
| should write a whole new frontend? It seems like they are
| basically solving the same problem, except mrustc has chosen a
| subset of it (it assumes correct code). Of course GCC-rs also has
| a subset in a way as most of the codegen is handled by the GCC
| core.
|
| To be clear I'm not saying that mrustc is a better approach to
| bootstrapping, but for this specific point is seems that the two
| approaches are basically equivalent.
| Arnavion wrote:
| There are other reasons given why mrustc is not the solution.
| Even if mrustc was updated to 1.51 those reasons would not go
| away.
| [deleted]
___________________________________________________________________
(page generated 2021-06-07 23:01 UTC)