Re: Cassandra 5+ JDK Minimum Compatibility Requirement
It looks like there is a potential solution to the indeterministic bytebuffer: https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html & https://archive.fosdem.org/2020/schedule/event/bytebuffers/ Thanks, Vivekanand K. On Fri, May 9, 2025, 8:59 PM Vivekanand Koya <13vivekk...@gmail.com> wrote: > Made some progress. After adding > throughout build.xml and compiling the 5.03 branch with openjdk 17.0.15 > 2025-04-15 > OpenJDK Runtime Environment Temurin-17.0.15+6 (build 17.0.15+6) I got a > build Failed error at the same position in exception. Please see: > https://github.com/apache/cassandra/pull/4152 > > While debugging, it appears there is an idiosyncrasy how Netty was used > for efficient network operations. The unsafe casting was highlighted by the > compiler and eventually made its way to runtime. I drew a dependency graph > between types. It appears Java natively supports such functionality with > Project Loom (https://openjdk.org/jeps/444) ( > https://inside.java/2021/05/10/networking-io-with-virtual-threads/). I > understand that this is only part of the story. Please correct me if my > reasoning is wrong, wish to learn from your experience. Wish to see your > insights. > > Thanks, > Vivekanand K. > > On Fri, May 9, 2025 at 1:30 PM Brandon Williams wrote: > >> We thought we had this figured out when we did the big bang switch to >> ByteBuffers, then spent years finding subtle bugs that the tests >> didn't. >> >> Kind Regards, >> Brandon >> >> On Fri, May 9, 2025 at 3:24 PM Jon Haddad >> wrote: >> > >> > There’s a pretty simple solution here - breaking it up into several >> smaller patches. >> > >> > * Any changes should include tests that validate the checks are used >> correctly. >> > * It should also alleviate any issues with code conflicts and rebasing >> as the merges would happen slowly over time rather than all at once. >> > * If there’s two committers willing to spend time and work with OP on >> this, that should be enough to move it forward. >> > * There's a thread on user@ right now [1] where someone *just* ran >> into this issue, so I'd say addressing that one is a reasonable starting >> point. >> > >> > [1] https://lists.apache.org/thread/ykkwhjdpgyqzw5xtol4v5ysz664bxxl3 >> > >> > >> > >> > Jon >> > >> > >> > On Fri, May 9, 2025 at 12:16 PM C. Scott Andreas >> wrote: >> >> >> >> My thinking is most closely aligned with Blake and Benedict’s views >> here. >> >> >> >> For the specific refactor in question, I support adoption of the >> language feature for new code or to cut existing code over to the new >> syntax as changes are made to the respective areas of the codebase. But I >> don’t support a sweeping project-wide refactor on trunk in this case. >> >> >> >> Here is my thinking: >> >> >> >> - If there are 2000 target sites for the refactor, that means this is >> going to be a 5000+ line diff. >> >> - The safety improvement here is marginal but nonzero. >> >> - If we have a 5000 line refactor, it should accomplish a significant >> and compelling purpose in the project. >> >> - Any execution of the refactor will require manual review of each of >> those 2000 refactor sites on the part of the implementer and two reviewers. >> >> - Since the check is compile-time, we’d learn that by the initial >> refactor the first time it’s compiled, and we short-circuit to having >> gained 100% of the value by being able to fix the broken callsites. >> >> - The act of that per-call site review would inform us as to whether >> we had incorrect casts; and we would immediately achieve the value of the >> “safer” approach by having identified the bugs. >> >> - 2x reviewer coverage for a 5000 line patch set is a significant >> commitment of reviewer resources. These reviewer resources have significant >> opportunity cost and can put to a better purpose. >> >> - Blake/others mention that such refactors create conflicts when bug >> fixes are backported to previous releases, requiring refactors of those >> rebased patches to bring fixes to versions that predate the large refactor. >> >> >> >> I think this is a good language feature. I think we should use it. I >> think it’d be completely reasonable to cut existing syntax over to it as we >> make changes to the respective subsystems. >> >> >> >> But I wouldn’t do a b
Fwd: Cassandra 5 JDK21 Command Line actions
Hello, I've talked to ZGC members of the OpenJDK community on GC strategies. Wanted to share this information with Cassandra devs. Thanks, Vivekanand -- Forwarded message - From: Stefan Johansson Date: Fri, May 9, 2025, 2:00 AM Subject: Re: Cassandra 5 JDK21 Command Line actions To: Vivekanand Koya <13vivekk...@gmail.com>, Hi Vivekanand, I'm actually currently trying to figure out how much information I can share around the setup we used. I can summarize what is already public information from my presentations. I'm using Cassandra 4 and JDK 21, with tweaked command-line options (--add-opens and so) to get it to run properly. I try to do very minimal JVM/GC tuning apart from setting the heap size and enabling the use of NUMA and large pages. G1 is using a 31G fixed heap (-Xmx31g -Xms31g) to be able to make use of compressed oops, while ZGC is using a 32G fixed heap. The only GC tuning I do is setting a 50ms pause time goal (-XX:MaxGCPauseMillis=50) for one of the G1 runs to see how lowering the pause target affect the performance. The testing methodology is running the same scenario with more and more threads to add more and more pressure to the server instance. The server is running on its own host and it is a single node setup. The clients all run on a different machine and we use the cassandra-stress tool with more and more threads to generate the load. Regarding tuning, one of the big things with ZGC is that you generally should not have to do any tuning. That said, when using JDK 21 you need to supply the -XX:+ZGenerational option to enable the generational mode. In JDK 23 and later the generational mode is on by default and in JDK 24 ZGC is generational and it can't be turned off. Something to look out for when using ZGC is allocation stalls, those happen when ZGC can't collect and free up memory fast enough. Generally if you see allocation stalls, you need to increase the heap size to give ZGC more head room to complete the GC work in time. If the stalls happen due to unexpected spikes of allocations the SoftMaxHeapSize option can be used to set the heap size ZGC should aim at using, but can go over during spikes of allocations. For example -Xmx32g -XX:SoftMaxHeapSize=28g, would give ZGC 4g of "reserved head room" that will only be used when it can't keep up. I hope this helps, StefanJ On 2025-05-09 07:27, Vivekanand Koya wrote: Hello ZGC members, I work on the Apache Cassandra team implementing support for JDK21 in the upcoming Cassandra 5+ release. I need insight into JVM options providing comparable and perhaps improved performance compared to G1GC. Some work has been done using the previous defaults: https://github.com/apache/cassandra/commit/b15d4d6980e787ab5f3405ca8cb17a9c92a4aa47. Also, can you please provide the testing/benchmarking methodology used by Stefan Johansson when presenting at Devoxx. Hope to achieve greater outcomes together, Thanks, Vivekanand K.
Re: Cassandra 5+ JDK Minimum Compatibility Requirement
Sounds great. I would like to refactor the codebase (Trunk 5+) to eliminate unsafe explicit casting with instanceOf. Thanks, Vivekanand On Fri, May 9, 2025, 5:19 AM Benedict Elliott Smith wrote: > Yep, that approach seems more than sufficient to me. No need for lots of > ceremony, but good to keep everyone in the decision loop. > > On 9 May 2025, at 13:10, Josh McKenzie wrote: > > I think it doesn’t cost us much to briefly discuss new language features > before using them. > > I had that thought as well but on balance my intuition was there were > enough new features that the volume of discussion to do that would be a > poor cost/benefit compared to the "lazy consensus, revert" approach. > > So if I actually do the work required to have an opinion ;): > > https://docs.oracle.com/en/java/javase/21/language/java-language-changes-release.html#GUID-6459681C-6881-45D8-B0DB-395D1BD6DB9B > > JDK21: > - Record Patterns > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-7623D3AD-4141-4914-A384-60C65BD0C010> > - Pattern Matching for switch Expressions and Statements > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-E69EEA63-E204-41B4-AA7F-D58B26A3B232> > - String Templates > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-78F545D3-CDD0-415C-9B4B-6EF361D184F5> > - Unnamed Patterns and Variables > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-D54E1CF1-BDFD-4B57-8A6E-5B4C87F4D58A> > - Unnamed Classes and Instance Main Methods > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-35544A22-61AB-4928-99BB-A9DD1CA062FF> > JDK17: > - Sealed Classes > <https://docs.oracle.com/pls/topic/lookup?ctx=javase17&id=GUID-0C709461-CC33-419A-82BF-61461336E65F> > JDK16: > - Pattern Matching for instanceof > <https://docs.oracle.com/pls/topic/lookup?ctx=javase16&id=GUID-843060B5-240C-4F47-A7B0-95C42E5B08A7> > JDK15: > - Text Blocks > <https://docs.oracle.com/pls/topic/lookup?ctx=javase15&id=GUID-221D06A2-FF54-4DB3-A6DA-179B8F76DB05> > JDK14: > - Switch Expressions > <https://docs.oracle.com/pls/topic/lookup?ctx=javase14&id=GUID-BA4F63E3-4823-43C6-A5F3-BAA4A2EF3ADC> > JDK11: > - Local Variable Type Inference > <https://docs.oracle.com/en/java/javase/21/language/local-variable-type-inference.html#GUID-D2C58FE6-1065-4B50-9326-57DD8EC358AC> > (test > only, not prod code is where we landed) > > Assuming we just lazily evaluate and deal with new features as people* > actually care about them* and seeing them add value, a simple "[DISCUSS] > I'm thinking about using new language feature X; any objection?" lazy > consensus that we then dumped onto a wiki article / code style page as > "stuff we're good to use" would probably be fine? > > > On Fri, May 9, 2025, at 7:58 AM, Benedict wrote: > > > I think it doesn’t cost us much to briefly discuss new language features > before using them. Lambdas, Streams and var all have problems - and even > with the guidance we publish some are still misused. > > The flow scoping improvement to instanceof seems obviously good though. > > > On 9 May 2025, at 12:30, Josh McKenzie wrote: > > > For new feature work on trunk, targeting the highest supported language > level featureset (jdk17 right now, jdk21 within the next couple of weeks) > makes sense to me. For bugfixing, targeting the oldest supported GA branch > and the highest language level that works there would allow maximum > flexibility with minimal re-implementation. > > If anyone has any misgivings with certain features (i.e. the debate around > usage of "var") they can bring it up on the dev ML and we can adjust, but > otherwise I'd prefer to see us have more modern evolving options on how > contributors engage rather than less. > > On Fri, May 9, 2025, at 1:56 AM, Vivekanand Koya wrote: > > Hello, > > I want to understand the community's thoughts on using newer features > (post JDK11) in upcoming releases in Cassandra. An example is flow scoping > instead of explicitly casting types with instanceOf: > https://openjdk.org/jeps/395. I want your thoughts on JDK requirements > for the main Cassandra repository, Accord, and Sidecar. > > Much appreciated. > Thanks, > Vivekanand K. > > > > >
Re: Cassandra 5+ JDK Minimum Compatibility Requirement
I would say that https://openjdk.org/jeps/394 (instanceOf) aims to provide safer and less poisoning in the code by default. Instead of having a production server halt/impaired due to a RuntimeException, instead it is verified at compile time. If a new language feature makes code more robust and addresses a hazardous, historical design choice, I believe it's time has arrived. Curious to see what everyone thinks. Thanks, Vivekanand K. On Fri, May 9, 2025 at 9:51 AM Josh McKenzie wrote: > I would like to refactor the codebase (Trunk 5+) to eliminate unsafe > explicit casting with instanceOf. > > We have a rich history of broad sweeping refactors dying on the rocks of > the community's aversion to instability and risk w/out a concrete outcome > we're trying to achieve. :) > > All of which is to say: do we have examples of instanceOf casting blowing > things up for users that would warrant going through the codebase to tidy > this up? Between src/java and test/unit and test/distributed we have around > 2,000 occurrences of this pattern. > > On Fri, May 9, 2025, at 10:14 AM, Vivekanand Koya wrote: > > Sounds great. I would like to refactor the codebase (Trunk 5+) to > eliminate unsafe explicit casting with instanceOf. > > Thanks, > Vivekanand > > On Fri, May 9, 2025, 5:19 AM Benedict Elliott Smith > wrote: > > Yep, that approach seems more than sufficient to me. No need for lots of > ceremony, but good to keep everyone in the decision loop. > > On 9 May 2025, at 13:10, Josh McKenzie wrote: > > I think it doesn’t cost us much to briefly discuss new language features > before using them. > > I had that thought as well but on balance my intuition was there were > enough new features that the volume of discussion to do that would be a > poor cost/benefit compared to the "lazy consensus, revert" approach. > > So if I actually do the work required to have an opinion ;): > > https://docs.oracle.com/en/java/javase/21/language/java-language-changes-release.html#GUID-6459681C-6881-45D8-B0DB-395D1BD6DB9B > > JDK21: > - Record Patterns > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-7623D3AD-4141-4914-A384-60C65BD0C010> > - Pattern Matching for switch Expressions and Statements > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-E69EEA63-E204-41B4-AA7F-D58B26A3B232> > - String Templates > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-78F545D3-CDD0-415C-9B4B-6EF361D184F5> > - Unnamed Patterns and Variables > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-D54E1CF1-BDFD-4B57-8A6E-5B4C87F4D58A> > - Unnamed Classes and Instance Main Methods > <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-35544A22-61AB-4928-99BB-A9DD1CA062FF> > JDK17: > - Sealed Classes > <https://docs.oracle.com/pls/topic/lookup?ctx=javase17&id=GUID-0C709461-CC33-419A-82BF-61461336E65F> > JDK16: > - Pattern Matching for instanceof > <https://docs.oracle.com/pls/topic/lookup?ctx=javase16&id=GUID-843060B5-240C-4F47-A7B0-95C42E5B08A7> > JDK15: > - Text Blocks > <https://docs.oracle.com/pls/topic/lookup?ctx=javase15&id=GUID-221D06A2-FF54-4DB3-A6DA-179B8F76DB05> > JDK14: > - Switch Expressions > <https://docs.oracle.com/pls/topic/lookup?ctx=javase14&id=GUID-BA4F63E3-4823-43C6-A5F3-BAA4A2EF3ADC> > JDK11: > - Local Variable Type Inference > <https://docs.oracle.com/en/java/javase/21/language/local-variable-type-inference.html#GUID-D2C58FE6-1065-4B50-9326-57DD8EC358AC> > (test > only, not prod code is where we landed) > > Assuming we just lazily evaluate and deal with new features as people* > actually care about them* and seeing them add value, a simple "[DISCUSS] > I'm thinking about using new language feature X; any objection?" lazy > consensus that we then dumped onto a wiki article / code style page as > "stuff we're good to use" would probably be fine? > > > On Fri, May 9, 2025, at 7:58 AM, Benedict wrote: > > > I think it doesn’t cost us much to briefly discuss new language features > before using them. Lambdas, Streams and var all have problems - and even > with the guidance we publish some are still misused. > > The flow scoping improvement to instanceof seems obviously good though. > > > On 9 May 2025, at 12:30, Josh McKenzie wrote: > > > For new feature work on trunk, targeting the highest supported language > level featureset (jdk17 right now, jdk21 within the next couple of weeks) > makes sense to me. For bugfixing, targeting the oldest supported GA branch > and the highest language level that works there would allow maximum > flexibility with m
Re: Cassandra 5+ JDK Minimum Compatibility Requirement
I can also provide potential examples if you'd like. Thanks, Vivekanand K. On Fri, May 9, 2025 at 10:18 AM Vivekanand Koya <13vivekk...@gmail.com> wrote: > I would say that https://openjdk.org/jeps/394 (instanceOf) aims to > provide safer and less poisoning in the code by default. Instead of having > a production server halt/impaired due to a RuntimeException, instead it is > verified at compile time. If a new language feature makes code more robust > and addresses a hazardous, historical design choice, I believe it's time > has arrived. Curious to see what everyone thinks. > > Thanks, > Vivekanand K. > > On Fri, May 9, 2025 at 9:51 AM Josh McKenzie wrote: > >> I would like to refactor the codebase (Trunk 5+) to eliminate unsafe >> explicit casting with instanceOf. >> >> We have a rich history of broad sweeping refactors dying on the rocks of >> the community's aversion to instability and risk w/out a concrete outcome >> we're trying to achieve. :) >> >> All of which is to say: do we have examples of instanceOf casting blowing >> things up for users that would warrant going through the codebase to tidy >> this up? Between src/java and test/unit and test/distributed we have around >> 2,000 occurrences of this pattern. >> >> On Fri, May 9, 2025, at 10:14 AM, Vivekanand Koya wrote: >> >> Sounds great. I would like to refactor the codebase (Trunk 5+) to >> eliminate unsafe explicit casting with instanceOf. >> >> Thanks, >> Vivekanand >> >> On Fri, May 9, 2025, 5:19 AM Benedict Elliott Smith >> wrote: >> >> Yep, that approach seems more than sufficient to me. No need for lots of >> ceremony, but good to keep everyone in the decision loop. >> >> On 9 May 2025, at 13:10, Josh McKenzie wrote: >> >> I think it doesn’t cost us much to briefly discuss new language features >> before using them. >> >> I had that thought as well but on balance my intuition was there were >> enough new features that the volume of discussion to do that would be a >> poor cost/benefit compared to the "lazy consensus, revert" approach. >> >> So if I actually do the work required to have an opinion ;): >> >> https://docs.oracle.com/en/java/javase/21/language/java-language-changes-release.html#GUID-6459681C-6881-45D8-B0DB-395D1BD6DB9B >> >> JDK21: >> - Record Patterns >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-7623D3AD-4141-4914-A384-60C65BD0C010> >> - Pattern Matching for switch Expressions and Statements >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-E69EEA63-E204-41B4-AA7F-D58B26A3B232> >> - String Templates >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-78F545D3-CDD0-415C-9B4B-6EF361D184F5> >> - Unnamed Patterns and Variables >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-D54E1CF1-BDFD-4B57-8A6E-5B4C87F4D58A> >> - Unnamed Classes and Instance Main Methods >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-35544A22-61AB-4928-99BB-A9DD1CA062FF> >> JDK17: >> - Sealed Classes >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase17&id=GUID-0C709461-CC33-419A-82BF-61461336E65F> >> JDK16: >> - Pattern Matching for instanceof >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase16&id=GUID-843060B5-240C-4F47-A7B0-95C42E5B08A7> >> JDK15: >> - Text Blocks >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase15&id=GUID-221D06A2-FF54-4DB3-A6DA-179B8F76DB05> >> JDK14: >> - Switch Expressions >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase14&id=GUID-BA4F63E3-4823-43C6-A5F3-BAA4A2EF3ADC> >> JDK11: >> - Local Variable Type Inference >> <https://docs.oracle.com/en/java/javase/21/language/local-variable-type-inference.html#GUID-D2C58FE6-1065-4B50-9326-57DD8EC358AC> >> (test >> only, not prod code is where we landed) >> >> Assuming we just lazily evaluate and deal with new features as people* >> actually care about them* and seeing them add value, a simple "[DISCUSS] >> I'm thinking about using new language feature X; any objection?" lazy >> consensus that we then dumped onto a wiki article / code style page as >> "stuff we're good to use" would probably be fine? >> >> >> On Fri, May 9, 2025, at 7:58 AM, Benedict wrote: >> >> >> I think it doesn’t cost us much to briefly discuss new language features >> before using them. Lambdas, Streams and var all have problems - and even &g
Cassandra 5+ JDK Minimum Compatibility Requirement
Hello, I want to understand the community's thoughts on using newer features (post JDK11) in upcoming releases in Cassandra. An example is flow scoping instead of explicitly casting types with instanceOf: https://openjdk.org/jeps/395. I want your thoughts on JDK requirements for the main Cassandra repository, Accord, and Sidecar. Much appreciated. Thanks, Vivekanand K.
Re: Cassandra 5+ JDK Minimum Compatibility Requirement
gt; development, but the real concern I have with any large change is how it > complicates the process of fixing bugs across versions. On the other hand, > I don’t think that incorrectly casting objects has historically been a > source of pain for us, so it seems like the benefit would be small if any. > >> > >> On Fri, May 9, 2025, at 10:38 AM, Jon Haddad wrote: > >> > >> Why not? > >> > >> Personally, I hate the idea of treating a codebase (any codebase) like > a house of cards that can't be touched. It never made sense to me to try > to bundle new features / bug fixes with improvements to code quality. > >> > >> Making the code more reliable should be a goal in itself, rather than a > side effect of other work. > >> > >> Jon > >> > >> > >> > >> On Fri, May 9, 2025 at 10:31 AM Blake Eggleston > wrote: > >> > >> > >> This seems like a cool feature that will be useful in future > development work, but not something we should be proactively refactoring > the project to make use of. > >> > >> On Fri, May 9, 2025, at 10:18 AM, Vivekanand Koya wrote: > >> > >> I would say that https://openjdk.org/jeps/394 (instanceOf) aims to > provide safer and less poisoning in the code by default. Instead of having > a production server halt/impaired due to a RuntimeException, instead it is > verified at compile time. If a new language feature makes code more robust > and addresses a hazardous, historical design choice, I believe it's time > has arrived. Curious to see what everyone thinks. > >> > >> Thanks, > >> Vivekanand K. > >> > >> On Fri, May 9, 2025 at 9:51 AM Josh McKenzie > wrote: > >> > >> > >> I would like to refactor the codebase (Trunk 5+) to eliminate unsafe > explicit casting with instanceOf. > >> > >> We have a rich history of broad sweeping refactors dying on the rocks > of the community's aversion to instability and risk w/out a concrete > outcome we're trying to achieve. :) > >> > >> All of which is to say: do we have examples of instanceOf casting > blowing things up for users that would warrant going through the codebase > to tidy this up? Between src/java and test/unit and test/distributed we > have around 2,000 occurrences of this pattern. > >> > >> On Fri, May 9, 2025, at 10:14 AM, Vivekanand Koya wrote: > >> > >> Sounds great. I would like to refactor the codebase (Trunk 5+) to > eliminate unsafe explicit casting with instanceOf. > >> > >> Thanks, > >> Vivekanand > >> > >> On Fri, May 9, 2025, 5:19 AM Benedict Elliott Smith < > bened...@apache.org> wrote: > >> > >> Yep, that approach seems more than sufficient to me. No need for lots > of ceremony, but good to keep everyone in the decision loop. > >> > >> On 9 May 2025, at 13:10, Josh McKenzie wrote: > >> > >> I think it doesn’t cost us much to briefly discuss new language > features before using them. > >> > >> I had that thought as well but on balance my intuition was there were > enough new features that the volume of discussion to do that would be a > poor cost/benefit compared to the "lazy consensus, revert" approach. > >> > >> So if I actually do the work required to have an opinion ;): > >> > https://docs.oracle.com/en/java/javase/21/language/java-language-changes-release.html#GUID-6459681C-6881-45D8-B0DB-395D1BD6DB9B > >> > >> JDK21: > >> - Record Patterns > >> - Pattern Matching for switch Expressions and Statements > >> - String Templates > >> - Unnamed Patterns and Variables > >> - Unnamed Classes and Instance Main Methods > >> JDK17: > >> - Sealed Classes > >> JDK16: > >> - Pattern Matching for instanceof > >> JDK15: > >> - Text Blocks > >> JDK14: > >> - Switch Expressions > >> JDK11: > >> - Local Variable Type Inference (test only, not prod code is where we > landed) > >> > >> Assuming we just lazily evaluate and deal with new features as people > actually care about them and seeing them add value, a simple "[DISCUSS] I'm > thinking about using new language feature X; any objection?" lazy consensus > that we then dumped onto a wiki article / code style page as "stuff we're > good to use" would probably be fine? > >> > >> > >> On Fri, May 9, 2025, at 7:58 AM, Benedict wrote: > >> > >> >
