Proposed Carbon roadmap for 2021 #253
Conversation
This document tries to lay out a high-level roadmap for Carbon in 2021 following the [roadmap process](/docs/project/roadmap_process.md). The initial draft of this was here: https://docs.google.com/document/d/19ER9jKG0gXth063wdJIeSaegrO0P8Cye2SIdoVvlhrU/edit Currently, the content is in a proposal. I'd also be happy to lift it to live in its own document as part of the project documentation if people prefer.
chandlerc
added
proposal rfc
|
One comment that came up as @dabrahams and I were discussing this: it might be nice to add a lower resolution outline of likely subsequent (post-2021) goals to help telegraph where things are going. |
|
I also think it's crucial that (soon, but not immediately) we have a higher
resolution outline of intermediate goals during 2021.
…On Thu, Feb 4, 2021 at 5:41 PM Chandler Carruth ***@***.***> wrote:
One comment that came up as @dabrahams <https://github.com/dabrahams> and
I were discussing this: it might be nice to add a lower resolution outline
of likely subsequent (post-2021) goals to help telegraph where things are
going.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#253 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAKYIIMQFEWWW4Q47FOGB3S5NEGJANCNFSM4XAPRMQA>
.
--
-Dave
|
|
I just pushed a significant update to the wording here. Mostly, this tries to zoom in on the concrete things we want to achieve in 2021, and on the outcome of moving faster rather than the input of more resources being devoted to the project. Please take a look and let me know what you all think. I've also added a high-level outline of what the longer term path might look like to help contextualize, etc. @dabrahams also suggested:
Do you have any suggestions on where / how you'd like to see something like this? The wording rework has focused some on the concrete things, but it hasn't really added more resolution. |
|
|
||
| - Increase the investment by existing individuals and organizations. | ||
| - Increase the breadth of different individuals and organizations investing in | ||
| Carbon. |
There was a problem hiding this comment.
I don't know if something like this belongs here or in a different section, but I think we need some way to quantify what it means to "speed up development." Neither of the above two bullets correspond in any obvious way to development speed.
| Carbon. | |
| Carbon. | |
| - Establish some statistics that serve as approximate measurement of progress (e.g. the number of distinct tests in executable semantics). | |
| - Establish development rhythm and process that results in steady progress by that measurement. |
There was a problem hiding this comment.
I think increasing the effort invested in Carbon does correspond somewhat with speed?
But to be clear, all of these are directional goals, not concrete outcomes. I feel like what you're suggesting are concrete outcomes and so don't really fit here.
I somewhat prefer the higher level outcomes we have below, which I don't think are achievable without a significant increase in speed, and I think also will unblock further improvements (by unblocking further increases in investment).
| that we are including as broad and representative a set of perspectives in the | ||
| evolution of Carbon as possible. | ||
|
|
||
| ### Example ports of C libraries to Carbon (100% of [woff2](https://github.com/google/woff2), 99% of [RE2](https://github.com/google/re2)) |
There was a problem hiding this comment.
Is it a problem that our ports only address code written to follow Google's coding standard?
There was a problem hiding this comment.
Not sure how much of Google's coding standards woff2 really follows...
But generally, while we have one or two I think we'll have lots of weaknesses. Long term, we should add more here.
One suggestion was made in discussion to add some of the HPC community's canonical benchmarks. I don't know what those are or what the exact link is, but would love to have additions to this list maybe from @dhollman ?
proposals/p0253.md
Outdated
| Stretch goals if we can hit the above: | ||
|
|
||
| - Automatic code formatter on top of the implementation infrastructure. | ||
| - A compiler explorer fork with REPL integrated. |
There was a problem hiding this comment.
I don't know what a "compiler explorer fork" means; I suggest clarifying or omitting this bullet.
There was a problem hiding this comment.
A fork of http://compiler-explorer.com -- I've linked the text.
| Instead, it should focus on letting us track large/high-level impact on | ||
| different phases as they are developed or features are added. They may also help | ||
| illustrate initial high-level performance characteristics of the implementation, | ||
| but the long term focus should be on end-to-end user metrics. |
There was a problem hiding this comment.
I don't believe generating executable code is even important at this stage. Capturing all the semantics in the executable semantics interpreter and having a plausible compilation strategy should be enough.
There was a problem hiding this comment.
This came up in some in-person discussions, but to relay here I really think we need to have a reasonable demo as early as possible to help reset people's ingrained assumptions around both how fast compilation / tooling can be as well as how complex the compiler ultimately will be.
| implementation. The intent is to reflect that _completing_ coverage of the | ||
| features in the specification is a slightly lower priority, and instead we | ||
| should rapidly spike out as complete of a demo as possible and come back to the | ||
| semantics if possible. |
There was a problem hiding this comment.
I would strongly encourage inverting this philosophy. IMO the demo should be the executable semantic specification. There's no reason a demo needs to be fast in the first year. If we know what our design means, producing executable code, linking, and optimizing is a somewhat mechanical process. If we emphasize “real tooling” over something that corresponds to a specification, I worry we will invest a great deal of energy in layers of the system that aren't needed in order to prove that we can create a migration and interop path, which will slow progress, and that we will never end up with an accurate specification.
There was a problem hiding this comment.
See above -- I still feel fairly strongly about the need to have a "real" demo.
Co-authored-by: Dave Abrahams <[email protected]>
|
(And found a suggestions that I missed when reading -- thanks Jon!) |
jonmeow
added
needs decision
and removed
proposal rfc
mmdriley
added
proposal accepted
Co-authored-by: Chandler Carruth <[email protected]>
This document tries to lay out a high-level roadmap for Carbon in 2021 following the [roadmap process](/docs/project/roadmap_process.md). Co-authored-by: Dave Abrahams <[email protected]>
Co-authored-by: Chandler Carruth <[email protected]>
This document tries to lay out a high-level roadmap for Carbon in 2021
following the roadmap process.
The initial draft of this was here:
https://docs.google.com/document/d/19ER9jKG0gXth063wdJIeSaegrO0P8Cye2SIdoVvlhrU/edit
Currently, the content is in a proposal. I'd also be happy to lift it to
live in its own document as part of the project documentation if people
prefer.