Renaming SIG-dynamic-languages to SIG-Guest-Languages

[calvinrp]

This PR broadens the scope of the SIG to all guest languages to be more explicitly inclusive.

[esoterra]

Thanks for creating this! For some context to other readers, the group has been discussing which languages should join and how to make it clear to languages we think should that they are welcome. For example, making it clear to Go and Kotlin developers that they are invited to participate.

We haven't really found the distinction between dynamic and not dynamic languages to be as useful as expected. Many languages that are dynamic have a combination of ahead-of-time and interpreted/runtime aspects and the group ends up covering many topics which are of general interest to all guest languages.

The subgroup system gives the group the ability to split off topics and projects specific to one language into their own meetings to focus the main meeting on general discussions, which to me ameliorates concerns about scope creep & lack of focus that might come to mind.

[tschneidereit]

Thank you for this proposal, Calvin and Kyle!

One concern I have is that making the SIG be about all guest languages is a pretty sizable increase in scope. In the call I attended where we talked about maybe renaming it, the name we discussed was SIG-Managed-Languages, to highlight the fact that the topics aren't too much about the type system but about whether a language has a big runtime (such as languages like Java, Kotlin, or Go), or even an interpreter (like JS and Python).

Renaming to SIG-Guest-Languages would bring languages like Rust and C++ in scope. Is that intended? And if so, do you have a sense of what the implications would be?

[esoterra]

After that call, I went looking for definitions of "managed languages" and things that show its common usage in order to determine what language we would use in the charter to draw this line.

One of the first results for managed Languages is Wikipedia, which provides the following definition.

Managed code is computer program code that requires and will execute only under the management of a Common Language Infrastructure (CLI); Virtual Execution System (VES); virtual machine, e.g. .NET, CoreFX, or .NET Framework; Common Language Runtime (CLR); or Mono. The term was coined by Microsoft.

Some other definitions, including one used on Microsoft's website, are broader and are just synonyms for "language with a runtime".

managed code is just that: code whose execution is managed by a runtime.

There are other places where the term is used broadly (e.g. Managed Programming Languages and Runtimes 2022) and narrowly (e.g. common StackOverflow replies), but I'm concerned that since there is this mix of understandings of the word declaring that the BA has a "Managed Language" group might imply to some that we are Microsoft-focused.

Beyond the question of "Managed Language" as a term and whether it means what we intend to the majority of our audience, I'm also not sure that the exercise of "line finding" to decide what is and isn't in the group is useful. A decent amount of what is common among languages with runtimes is also in common with languages that don't have them and so discussions and work around componentizing tools and efforts like the dynamic linking project are clearly relevant to runtime/managed languages but also a variety of other languages.

I think cargo-component and related Rust work would be a good inclusion in the group and that different dynamic language tools can learn from, use, and adapt what Peter Heune has done to integrate the registry into cargo-component.

[tschneidereit]

Ah, that's very interesting—I wasn't at all aware of the .Net-specific coinage of the term. I agree that that makes using it a bit less of an obvious choice.

And while I agree that in the abstract, line-finding isn't necessarily a fruitful exercise, I do think that if we call the SIG "Guest-Languages", it really should be about all guest languages concerns. That's what I was getting at with my question about the implications: how would the SIG include the work on guest languages it hasn't been dealing with as much so far? And how would it involve the people working on those languages?

[esoterra]

Thanks TSC, we've reviewed our operations and believe that the subgroup process provides the tools to scale as needed in the short term as we onboard more projects. We'll continue to keep an eye on how our expanded scope affects the way the group needs to be organized. @guybedford and I will be reaching out to guest bindings projects authors and publicly announcing the group's new scope once the repos are all renamed and everything is set up and ready to welcome them.

PR's for the meetings repo (#106) and the SIG's repo (#2) have been opened and will be merged in after this PR is.