Finally something that I think is a worthwhile contribution from me to the Rust ecosystem :'D Almost 2 months of work porting this almost insane data structure from a research grade C++ implementation... but it seems to be worth it based on the current performance under high contention, where the std RwLock<BTreeMap> seems to fall behind significantly, so it may be of use for some actual projects. I am actually considering rewriting it in nightly because some of the unstable features would make the implementation much easier and maintainable. I will highly appreciate any feedback.
A high-performance concurrent ordered map for Rust. It stores keys as &[u8] and supports variable-length keys by building a trie of B+trees, based on the Masstree paper.
Keeping this post short, because I know it's a really niche and complex data structure that not many people will be interested in. Please check links below, I tried to keep an iterative divan benchmark record throughout the development, which you will be able to find in the repo inside the runs/ folder. It does win in almost all realistic workload against similar data structures compared with (which is highly suspicious and I am not sure what else I can do to make the benches more fair and rigorous O.O).
Disclaimer: Yes, a $20 claude subscription was used during development to write the large amount of tests and docs for the codebase :'D Sorry! I checked most of them, but some of the docs may still be stale, especially for the WIDTH 24 variant, which I wouldn't recommend using anyway.
Also, if anyone has time, please consider contributing by adding some more benchmarks. Please note that it is theoretically impossible for any complex concurrent data structure to compete with std's RwLock<BTreeMap> in PURE read cases, these data structures are optimized to perform under contention (concurrent read + write).
For example, here's a comparison between them, if you properly batch them, BTreeMap works well when there is no write contention. But if you even add 5% writers and increase contention, Rw:Lock<BTreeMap> starts to scale negatively with higher threads. Maybe someone will be able to provide a pattern to show otherwise:
─ 02_point_get_zipf_64B │ │ │ │ │
│ ├─ masstree15 │ │ │ │ │
│ │ ├─ 1 10.1 ms │ 13.22 ms │ 10.83 ms │ 11.03 ms │ 200 │ 200
│ │ │ 4.945 Mitem/s │ 3.779 Mitem/s │ 4.612 Mitem/s │ 4.53 Mitem/s │ │
│ │ ├─ 2 11 ms │ 14.16 ms │ 11.51 ms │ 11.74 ms │ 200 │ 200
│ │ │ 9.09 Mitem/s │ 7.057 Mitem/s │ 8.685 Mitem/s │ 8.517 Mitem/s │ │
│ │ ├─ 3 11.46 ms │ 16.47 ms │ 11.93 ms │ 12.37 ms │ 200 │ 200
│ │ │ 13.07 Mitem/s │ 9.103 Mitem/s │ 12.56 Mitem/s │ 12.12 Mitem/s │ │
│ │ ├─ 4 11.61 ms │ 16.77 ms │ 11.84 ms │ 12.48 ms │ 200 │ 200
│ │ │ 17.22 Mitem/s │ 11.92 Mitem/s │ 16.88 Mitem/s │ 16.01 Mitem/s │ │
│ │ ├─ 5 11.77 ms │ 16.25 ms │ 12.23 ms │ 12.96 ms │ 200 │ 200
│ │ │ 21.23 Mitem/s │ 15.37 Mitem/s │ 20.42 Mitem/s │ 19.28 Mitem/s │ │
│ │ ╰─ 6 11.94 ms │ 16.16 ms │ 12.2 ms │ 12.87 ms │ 200 │ 200
│ │ 25.11 Mitem/s │ 18.55 Mitem/s │ 24.57 Mitem/s │ 23.3 Mitem/s │ │
│ ├─ parking_rwlock_btreemap │ │ │ │ │
│ │ ├─ 1 9.136 ms │ 14.92 ms │ 9.469 ms │ 10.04 ms │ 200 │ 200
│ │ │ 5.472 Mitem/s │ 3.35 Mitem/s │ 5.28 Mitem/s │ 4.975 Mitem/s │ │
│ │ ├─ 2 10.07 ms │ 15.25 ms │ 11.93 ms │ 12.47 ms │ 200 │ 200
│ │ │ 9.92 Mitem/s │ 6.555 Mitem/s │ 8.376 Mitem/s │ 8.015 Mitem/s │ │
│ │ ├─ 3 10.51 ms │ 16.94 ms │ 12.7 ms │ 13.1 ms │ 200 │ 200
│ │ │ 14.27 Mitem/s │ 8.851 Mitem/s │ 11.8 Mitem/s │ 11.44 Mitem/s │ │
│ │ ├─ 4 13.37 ms │ 17.82 ms │ 13.62 ms │ 14.19 ms │ 200 │ 200
│ │ │ 14.95 Mitem/s │ 11.21 Mitem/s │ 14.67 Mitem/s │ 14.09 Mitem/s │ │
│ │ ├─ 5 14.78 ms │ 18.5 ms │ 15.57 ms │ 15.96 ms │ 200 │ 200
│ │ │ 16.9 Mitem/s │ 13.51 Mitem/s │ 16.04 Mitem/s │ 15.65 Mitem/s │ │
│ │ ╰─ 6 16.1 ms │ 20.05 ms │ 16.47 ms │ 17.05 ms │ 200 │ 200
│ │ 18.63 Mitem/s │ 14.95 Mitem/s │ 18.21 Mitem/s │ 17.58 Mitem/s │ │
│ ├─ parking_rwlock_btreemap_batched │ │ │ │ │
│ │ ├─ 1 9.028 ms │ 15.3 ms │ 9.565 ms │ 10.54 ms │ 200 │ 200
│ │ │ 5.538 Mitem/s │ 3.267 Mitem/s │ 5.226 Mitem/s │ 4.741 Mitem/s │ │
│ │ ├─ 2 9.186 ms │ 14.73 ms │ 9.782 ms │ 10.25 ms │ 200 │ 200
│ │ │ 10.88 Mitem/s │ 6.787 Mitem/s │ 10.22 Mitem/s │ 9.755 Mitem/s │ │
│ │ ├─ 3 9.431 ms │ 14.52 ms │ 9.906 ms │ 10.3 ms │ 200 │ 200
│ │ │ 15.9 Mitem/s │ 10.32 Mitem/s │ 15.14 Mitem/s │ 14.55 Mitem/s │ │
│ │ ├─ 4 9.616 ms │ 15.18 ms │ 10 ms │ 10.89 ms │ 200 │ 200
│ │ │ 20.79 Mitem/s │ 13.17 Mitem/s │ 19.98 Mitem/s │ 18.35 Mitem/s │ │
│ │ ├─ 5 9.708 ms │ 15.07 ms │ 10.09 ms │ 10.73 ms │ 200 │ 200
│ │ │ 25.75 Mitem/s │ 16.58 Mitem/s │ 24.75 Mitem/s │ 23.29 Mitem/s │ │
│ │ ╰─ 6 9.833 ms │ 15.56 ms │ 10.31 ms │ 11.33 ms │ 200 │ 200
│ │ 30.5 Mitem/s │ 19.27 Mitem/s │ 29.09 Mitem/s │ 26.45 Mitem/s │ │
│ ├─ std_rwlock_btreemap │ │ │ │ │
│ │ ├─ 1 9.051 ms │ 13.67 ms │ 9.332 ms │ 9.582 ms │ 200 │ 200
│ │ │ 5.524 Mitem/s │ 3.655 Mitem/s │ 5.357 Mitem/s │ 5.218 Mitem/s │ │
│ │ ├─ 2 9.91 ms │ 16.97 ms │ 11.85 ms │ 12.1 ms │ 200 │ 200
│ │ │ 10.09 Mitem/s │ 5.891 Mitem/s │ 8.435 Mitem/s │ 8.263 Mitem/s │ │
│ │ ├─ 3 11.31 ms │ 18.32 ms │ 12.74 ms │ 12.92 ms │ 200 │ 200
│ │ │ 13.25 Mitem/s │ 8.184 Mitem/s │ 11.76 Mitem/s │ 11.6 Mitem/s │ │
│ │ ├─ 4 13.26 ms │ 17.81 ms │ 13.54 ms │ 14.02 ms │ 200 │ 200
│ │ │ 15.07 Mitem/s │ 11.22 Mitem/s │ 14.76 Mitem/s │ 14.25 Mitem/s │ │
│ │ ├─ 5 13.44 ms │ 18.26 ms │ 14.65 ms │ 15.23 ms │ 200 │ 200
│ │ │ 18.6 Mitem/s │ 13.69 Mitem/s │ 17.05 Mitem/s │ 16.41 Mitem/s │ │
│ │ ╰─ 6 15.99 ms │ 19.61 ms │ 16.23 ms │ 16.75 ms │ 200 │ 200
│ │ 18.75 Mitem/s │ 15.29 Mitem/s │ 18.48 Mitem/s │ 17.9 Mitem/s │ │
│ ╰─ std_rwlock_btreemap_batched │ │ │ │ │
│ ├─ 1 9.245 ms │ 12.93 ms │ 9.584 ms │ 9.845 ms │ 200 │ 200
│ │ 5.407 Mitem/s │ 3.864 Mitem/s │ 5.216 Mitem/s │ 5.078 Mitem/s │ │
│ ├─ 2 9.38 ms │ 13.87 ms │ 9.847 ms │ 10.28 ms │ 200 │ 200
│ │ 10.66 Mitem/s │ 7.209 Mitem/s │ 10.15 Mitem/s │ 9.721 Mitem/s │ │
│ ├─ 3 9.559 ms │ 13.25 ms │ 10.1 ms │ 10.38 ms │ 200 │ 200
│ │ 15.69 Mitem/s │ 11.31 Mitem/s │ 14.83 Mitem/s │ 14.44 Mitem/s │ │
│ ├─ 4 9.748 ms │ 14.74 ms │ 10.19 ms │ 10.93 ms │ 200 │ 200
│ │ 20.51 Mitem/s │ 13.56 Mitem/s │ 19.62 Mitem/s │ 18.29 Mitem/s │ │
│ ├─ 5 9.981 ms │ 17.08 ms │ 10.37 ms │ 11.12 ms │ 200 │ 200
│ │ 25.04 Mitem/s │ 14.63 Mitem/s │ 24.09 Mitem/s │ 22.46 Mitem/s │ │
│ ╰─ 6 10.13 ms │ 15.24 ms │ 10.45 ms │ 11.29 ms │ 200 │ 200
│ 29.6 Mitem/s │ 19.67 Mitem/s │ 28.69 Mitem/s │ 26.55 Mitem/s │ │
├─ 03b_mixed_zipf_hotset_95_5_64B │ │ │ │ │
│ ├─ masstree15 │ │ │ │ │
│ │ ├─ 1 3.884 ms │ 7.671 ms │ 4.062 ms │ 4.409 ms │ 200 │ 200
│ │ │ 12.87 Mitem/s │ 6.517 Mitem/s │ 12.3 Mitem/s │ 11.33 Mitem/s │ │
│ │ ├─ 2 4.349 ms │ 7.803 ms │ 5.264 ms │ 5.519 ms │ 200 │ 200
│ │ │ 22.99 Mitem/s │ 12.81 Mitem/s │ 18.99 Mitem/s │ 18.11 Mitem/s │ │
│ │ ├─ 3 4.698 ms │ 9.504 ms │ 6.172 ms │ 6.891 ms │ 200 │ 200
│ │ │ 31.92 Mitem/s │ 15.78 Mitem/s │ 24.3 Mitem/s │ 21.76 Mitem/s │ │
│ │ ├─ 4 5.7 ms │ 9.433 ms │ 8.306 ms │ 7.556 ms │ 200 │ 200
│ │ │ 35.08 Mitem/s │ 21.2 Mitem/s │ 24.07 Mitem/s │ 26.46 Mitem/s │ │
│ │ ├─ 5 6.227 ms │ 10.1 ms │ 7.921 ms │ 7.885 ms │ 200 │ 200
│ │ │ 40.14 Mitem/s │ 24.75 Mitem/s │ 31.56 Mitem/s │ 31.7 Mitem/s │ │
│ │ ╰─ 6 6.618 ms │ 11.5 ms │ 7.842 ms │ 7.989 ms │ 200 │ 200
│ │ 45.33 Mitem/s │ 26.06 Mitem/s │ 38.25 Mitem/s │ 37.54 Mitem/s │ │
│ ├─ parking_rwlock_btreemap │ │ │ │ │
│ │ ├─ 1 4.328 ms │ 8.271 ms │ 4.43 ms │ 4.802 ms │ 200 │ 200
│ │ │ 11.55 Mitem/s │ 6.045 Mitem/s │ 11.28 Mitem/s │ 10.41 Mitem/s │ │
│ │ ├─ 2 6.492 ms │ 13.85 ms │ 10.85 ms │ 11.12 ms │ 200 │ 200
│ │ │ 15.4 Mitem/s │ 7.218 Mitem/s │ 9.208 Mitem/s │ 8.988 Mitem/s │ │
│ │ ├─ 3 8.62 ms │ 16.1 ms │ 13.48 ms │ 13.55 ms │ 200 │ 200
│ │ │ 17.4 Mitem/s │ 9.311 Mitem/s │ 11.12 Mitem/s │ 11.06 Mitem/s │ │
│ │ ├─ 4 16.08 ms │ 22.4 ms │ 17.17 ms │ 17.43 ms │ 200 │ 200
│ │ │ 12.43 Mitem/s │ 8.928 Mitem/s │ 11.64 Mitem/s │ 11.46 Mitem/s │ │
│ │ ├─ 5 19.65 ms │ 26.99 ms │ 22.74 ms │ 22.77 ms │ 200 │ 200
│ │ │ 12.71 Mitem/s │ 9.261 Mitem/s │ 10.98 Mitem/s │ 10.97 Mitem/s │ │
│ │ ╰─ 6 24.23 ms │ 30.68 ms │ 28.07 ms │ 27.52 ms │ 200 │ 200
│ │ 12.37 Mitem/s │ 9.777 Mitem/s │ 10.68 Mitem/s │ 10.89 Mitem/s │ │
│ ├─ parking_rwlock_btreemap_batched_reads │ │ │ │ │
│ │ ├─ 1 4.278 ms │ 6.527 ms │ 4.363 ms │ 4.503 ms │ 200 │ 200
│ │ │ 11.68 Mitem/s │ 7.659 Mitem/s │ 11.45 Mitem/s │ 11.1 Mitem/s │ │
│ │ ├─ 2 10.82 ms │ 18.07 ms │ 13.11 ms │ 13.47 ms │ 200 │ 200
│ │ │ 9.237 Mitem/s │ 5.531 Mitem/s │ 7.623 Mitem/s │ 7.422 Mitem/s │ │
│ │ ├─ 3 19.41 ms │ 29.09 ms │ 21.95 ms │ 22.23 ms │ 200 │ 200
│ │ │ 7.724 Mitem/s │ 5.155 Mitem/s │ 6.833 Mitem/s │ 6.745 Mitem/s │ │
│ │ ├─ 4 28.44 ms │ 41.08 ms │ 32.72 ms │ 33.18 ms │ 200 │ 200
│ │ │ 7.03 Mitem/s │ 4.867 Mitem/s │ 6.111 Mitem/s │ 6.026 Mitem/s │ │
│ │ ├─ 5 36.19 ms │ 54.42 ms │ 43.69 ms │ 43.87 ms │ 200 │ 200
│ │ │ 6.906 Mitem/s │ 4.593 Mitem/s │ 5.721 Mitem/s │ 5.697 Mitem/s │ │
│ │ ╰─ 6 45.3 ms │ 67.74 ms │ 49.97 ms │ 50.95 ms │ 200 │ 200
│ │ 6.621 Mitem/s │ 4.428 Mitem/s │ 6.002 Mitem/s │ 5.887 Mitem/s │ │
│ ├─ std_rwlock_btreemap │ │ │ │ │
│ │ ├─ 1 4.354 ms │ 9.043 ms │ 4.507 ms │ 4.613 ms │ 200 │ 200
│ │ │ 11.48 Mitem/s │ 5.529 Mitem/s │ 11.09 Mitem/s │ 10.83 Mitem/s │ │
│ │ ├─ 2 9.921 ms │ 21.73 ms │ 17.18 ms │ 16.38 ms │ 200 │ 200
│ │ │ 10.07 Mitem/s │ 4.6 Mitem/s │ 5.817 Mitem/s │ 6.101 Mitem/s │ │
│ │ ├─ 3 15.52 ms │ 27.17 ms │ 20.99 ms │ 21.61 ms │ 200 │ 200
│ │ │ 9.658 Mitem/s │ 5.519 Mitem/s │ 7.143 Mitem/s │ 6.939 Mitem/s │ │
│ │ ├─ 4 22.67 ms │ 39.43 ms │ 30.5 ms │ 30.58 ms │ 200 │ 200
│ │ │ 8.82 Mitem/s │ 5.071 Mitem/s │ 6.555 Mitem/s │ 6.54 Mitem/s │ │
│ │ ├─ 5 30.77 ms │ 47.94 ms │ 37.77 ms │ 37.92 ms │ 200 │ 200
│ │ │ 8.122 Mitem/s │ 5.213 Mitem/s │ 6.617 Mitem/s │ 6.591 Mitem/s │ │
│ │ ╰─ 6 33.43 ms │ 57.91 ms │ 44.37 ms │ 44.77 ms │ 200 │ 200
│ │ 8.973 Mitem/s │ 5.18 Mitem/s │ 6.76 Mitem/s │ 6.699 Mitem/s │ │
│ ╰─ std_rwlock_btreemap_batched_reads │ │ │ │ │
│ ├─ 1 4.254 ms │ 6.354 ms │ 4.312 ms │ 4.401 ms │ 200 │ 200
│ │ 11.75 Mitem/s │ 7.868 Mitem/s │ 11.59 Mitem/s │ 11.36 Mitem/s │ │
│ ├─ 2 12.04 ms │ 19.87 ms │ 15.38 ms │ 15.05 ms │ 200 │ 200
│ │ 8.303 Mitem/s │ 5.032 Mitem/s │ 6.497 Mitem/s │ 6.641 Mitem/s │ │
│ ├─ 3 16.85 ms │ 27.77 ms │ 23.07 ms │ 23.26 ms │ 200 │ 200
│ │ 8.901 Mitem/s │ 5.399 Mitem/s │ 6.5 Mitem/s │ 6.447 Mitem/s │ │
│ ├─ 4 22.45 ms │ 36.7 ms │ 30.43 ms │ 30.56 ms │ 200 │ 200
│ │ 8.905 Mitem/s │ 5.448 Mitem/s │ 6.572 Mitem/s │ 6.542 Mitem/s │ │
│ ├─ 5 28.37 ms │ 48.25 ms │ 38.46 ms │ 38.57 ms │ 200 │ 200
│ │ 8.81 Mitem/s │ 5.18 Mitem/s │ 6.5 Mitem/s │ 6.481 Mitem/s │ │
│ ╰─ 6 35.44 ms │ 58.99 ms │ 46.56 ms │ 46.84 ms │ 200 │ 200
│ 8.462 Mitem/s │ 5.084 Mitem/s │ 6.442 Mitem/s │ 6.403 Mitem/s │ │
I really wasn't expecting this repo to get 108 stars this fast (!?). But thank you to everyone for the interest, I guess the complexity original implementation is well known among people working with data structures :'D
A RwLock<BTreeMap> requires an atomic write for any read operation (to acquire the read lock), so any concurrent map that avoids it can theoretically be faster.
I guess I should have made it clear that I was talking about concurrent ordered maps. I have only seen papaya (which is an unordered hashmap) beat RwLock, this implementation also uses papaya's memory reclamation crate. But as far as I know, no concurrent ordered maps are capable of beating RwLock for pure read cases.
Someone has brought to my attention that google's stupid AI overview lists this as one of the fastest concurrent ordered map available, I have not claimed this anywhere :')
Almost done with the project, the core API is there and most of the basic stuff + some specialized things one would expect from a Rust data structure. I would appreciate anyone taking a look and contributing or suggesting how/where SIMD can be leveraged. The most likely candidate probably is the suffix comparison algorithm for long keys. But to be honest, I have very little idea about this topic.
The implementation is already unusually fast, and beats the original C++ implementation in most of the benches, which makes me a bit suspicious. I couldn't break it with the stress tests I could think of, but It still needs further validation and testing.
As it somehow got an unexpected number of stars all of a sudden (close to 200 O.O), it could be an interesting first repo to contribute to if you are looking for contributing to open source projects Some areas that you can consider:
Running the benchmarks on a 16 or 32 physical core machine if you have access to it. My PC unfortunately only has 6 cores. I have noticed some performance degradation and bad scaling issues for 7 to 12 threads (SMT/Hyperthreading) and for greater than 12 threads (oversubscription)
Test cases and more rigorous benchmarks.
SIMD (Already described above)
loom and shuttle tests (this would probably be harder to work on)
Don't be ashamed of using AI to write code! A lot of users on here are rude and insulting about it but they will fade away if they reject this technology.
I am not ashamed, it's just that it often generates subtle inaccurate stuff in docs and tests that are very easy to miss when rechecking O.O The sorry was for the stuff that I missed.
If AI has been used to write the code, I think it's at least fair to give a visible warning, preferably at the top of the README.
I don't want to start a debate here, since I've already explained that more often than I should, but the reason of the warning is that LLMs are not an appropriate tool for writing code (even less for testing it), so it's a significant risk. I think it's good practice to make that visible to potential users. If it was used only for the documentation, though, it's not as problematic.
I agree, because I actually tried to write some parts of it in some of the older commits, and you will be able to see them if you search :'D , which looked alright at first but led to lots of transient bugs. When there was AI generated core logic, there was also an AI-Assist disclaimer in the README, but most of the AI generated code had to be removed apart from some boilerplate and copy pasted same module with some minor modifications for different variants of the same code. But I am working on fully rewriting the docs and tests too. The project itself is complex enough, that it should be quite obvious that it wasn't AI generated/vibecoded O.O
I can't claim that the implementation is completely sound though, even if the full project was hand written without any external tools, because it's an extremely complex concurrent data structure and I wouldn't be surprised if it takes months or years before I find some edge case that hasn't been addressed yet.
It will be funny when all the mayor companies like Microsoft, Google, OpenAI, SpaceX will print such warnings on their products
I agree that AI assistance should be labeled -- but more in a way to honor their contribution, similar to when your mom helped you by a homework task.
The final responsible for the quality of a product is by the human authors, and it makes no difference if there was AI assistance, or if it might have been created mostly by AI. Soon we will have no software products created fully without AI support -- companies trying to avoid AI will go bankrupt, and people trying to avoid using AI will lose their jobs fast. And AI support can be seen even as a quality indicator, if used correctly.
But at least I agree in one point: What is now often called "AI slop" can be a real pain when it is publicized, e.g. all the four sec videos on YouTube without AI indicator, and most importantly fake videos.
I agree, but I guess this an unpopular opinion in the rust community :'D but I am pretty sure that the expert engineers currently active in the industry are heavily using AI, even if they don't admit it directly. I understand the ideological position of being against it, but it's not a pragmatic position to take in such a competitive industry. You won't be able to keep up with your peers who have actual domain knowledge and are heavily using AI to speed up their work. The people making slop projects are not the problem, they are mostly just beginners. Senior devs on the other hand... they can literally do the work of several junior devs when they properly get accustomed to it. If you can't stop those in the top of the industry from using AI, it doesn't make much sense to discourage others O.O
EDIT: Also, I really don't have enough spare income to invest heavily in AI anyway, unlike the top companies and their engineers :'D
Look, I am quite ideologically against it myself and it's an interesting paper.
The study was done in early 2025, when agentic coding wasn't even a thing... O.O And I don't see a point in your bet either, literally all top companies are heavily invested in AI, and their employees are given access to cutting edge models with basically unlimited amount of resources.
Also, It unfortunately proves my point... Experienced devs will always go with using AI, and perceive it as something productive, because it makes their work easier, instead of making them pessimistic about AI. The models used were claude 3.5 and 3.7... these can't really be compared to current frontier models that excel in agentic coding. Be prepared to be thoroughly disappointed when/if they update this study this year.
Core Result
When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.
Below, we show the raw average developer forecasted times, and the observed implementation times—we can clearly see that developers take substantially longer when they are allowed to use AI tools.
I think the reason that some "expert software developers" fail to use AI is the same why they often fail to lead a team of developers, e.g. delegating (simpler) sub-tasks to team members. Many AI experts and companies like Microsoft already admits that they use AI internally a lot -- the job marked confirms this, and internal AI use might explain the currently fast progress in AI development itself. Some might hesitate to admit the use of AI yet. Note, the software industry has only very few experts and project leaders -- the majority of software devs are doing quite trivial plumbing work, which an AI can already do fine.
I guess I'm wasting my time arguing here, but I can't help but reply to this:
You know why this is? Because they are mandating it:
Sure lets them publish big numbers for AI adoption, but they stop standing for people wanting to use it at that point. At most, the number of employees who still refuse to use it has meaning now.
I mean, I agree with your points and want less AI adoption myself, so I don't see what you are trying to argue here :'D My $20 claude subscription is basically because I am afraid of falling behind other devs and have an up to date working knowledge of how to use this tool if needed :'D
This forced use of AI is pretty dystopian, I read that they have some pretty big rust projects planned, considering how buggy windows 11 has been based on recent reports, those repos would be quite interesting to go though :'D
Please, again: this isn't the place for a debate on AI; there are already other threads about it, and it's definitely not my intention to derail this one (sorry about that @consistent-milk12).
I think the fact the topic is constantly debated (even here) should be enough to suggest general transparency about using an LLM to write the code of an open-source project, which others might decide to depend on. Particularly with a language like Rust that's chosen for its safety.
Anyway, the OP had already replied, so the point for this project was moot.
Some areas that you can consider:
