I agree; I can't find any rules around what should/shouldn't be nominated, so it ends up being whatever everyone else is doing (which can easily become a race to the bottom).
I'm wondering why some developers want to completely ban LLM generated code. LLMs just create code which someone else has produced and released in the web, like github. Everyone can look into this code and copy-paste it by hand. The LLM automates this. The reason for hand writing code is to implement new ideas and not spend hundreds of hours to hand write straight forward code, which has been already implemented by thousands of other developers. LLMs save us so much time , so that banning them is not the right way, IMHO.
To categorize the crates which are partly or fully LLM generated would be a way which I endorse.
So for the crate of the week in future there could be 3 kinds of categorization:
- fully hand written
- partly hand written
- fully LLM coded
For me, personally, the priority for the crate of the week is how useful it is for my needs. Whether it contains LLM code, doesn't matter for me.
The last crate I released, fastlogging-rs, is for example:
- Core and Python wrapper are fully hand coded
- Wrappers for other languages, which is straight forward code, are more than 50% hand coded
- Documentation is around 50% hand written
Is this already too much LLM code to ban it?
I can't say about banning, but for me personally this is a strong signal of not using this crate regardless of the publisher's claims about it's usefulness. Furthermore, if possible I would prefer not to see those publishing and discussions around them in my personal information space.
I still don't mind if someone would like to publish and discuss these things somewhere, but I would prefer if it would happend fully outside of my circles.
Well, once again the LLM related issue...
When talking about this issue anyway, I am always worried by the problem that, by trying to ban LLM in anyway, we are coming to the conclusion that it is not a tool---which we definitely do not want anyway, both in the ontology perspective and in law (as that would mean the human who are using the tool get no rights but all responsibility, which would be a disaster for jurisprudence).
So it might be more appreciate to not treat LLMs too specially, and just get some rules like community impact (downloads/stars/community engagement or anything else) to avoid spams.
I believe the rule stay with us long before vibe-coding became a thing: we expect that the shared project should be published in form of source code written in Rust.
This rule is in fact already self-sustainable. The fundamental part here is that the shared project should be a source artifact rather than a generated one. From this prospective we don't discourage other in using any tools, including LLMs, to produce generated artifacts from sources. But sharing these generated artifacts is not allowed, because there is no point for the community of programmers.
Now, let me explain this by example.
Can one publish a compiled binary?
No, a compiled binary may be useful, but it is not a source artifact. It is an output of the compiler, and therefore is a generated artifact produced from the source code using compiler as a tool. Instead, one should publish the source code from which it was compiled. Or, alternatively, the source code of the compiler written in Rust, if the purpose was to demonstrate a compiler.
Can one publish a safe FFI crate generated from machine-readable configuration files?
No. The code produced by your generator is a Rust code, but it is not a source code. It is a generated artifact. You should publish the generator itself, written in Rust. So, one can run it on their local machine and get the expected FFI crate locally.
Can one share an output of the artificial neural-network (e.g. LLM)?
No. The output is a generated artifact. However, if the purpose was to demonstrate the capabilities of the ANN/LLM, you can share the source code of the LLM written in Rust, it's training data, and the prompts that you use to get particular vibe-coding samples, as a demonstration of the ANN workflow.
First a bit of reply:
So the bigger issue here is, if we ban LLM specially then we come to the dilemma; if we ban generated content... Then the new dilemma include:
- the rustc bootstrap issue: if we do not distribute any compiled artifact then we cannot build our compiler; and rustup by default download complied toolchain;
- "you can share the source code of the LLM written in Rust, it's training data, and the prompts", in the current ANN approach, even sharing these won't get the exact output;
- When using proof assistant like Coq/Lean, we rely on generated artifact to prove correctness;
- When using Protobuf/gRPC/Django migrations/Bison or Yacc parser we often share generated content for convenience as other developer may not have Bison;
- To define what is generated is sometimes hard, the LLVM project also include many generated ir files, dichotomy is not stable to execute;
- And generated in many case do not = not edited by hand, and there is the Möbius ship paradox which could make the community get into witch hunting which breaks more trust;
- Anyway this is a philosophy issue which is under debate; and another issue is, especially for tools instead of libs, tools is for use and not for source code, and almost everyone somehow uses some non-source available tools in your life;
- 'sharing these generated artifacts is not allowed, because there is no point for the community of programmers' is not well discussed in the community also, and requires a separate discussion.
And back to the main thread (we are not generally talking about ethics anyway, I do not want to debate too much on philosophy): No matter what philosophy stands we are for, the true issue is, you cannot define what is 'quality', what is 'generated' clearly without met the Möbius ship paradox and without breaking trust, just technologically speaking there is no clear way to do it.
If we use ANN tools (like GPTZero) to detect, then we are sharing a generated result or an untrusted result. And technologically (let us avoid talking too much on philosophy) there is no way to ensure it is correct and no way to define the clear standard---which then makes the community doubts every newcomer. So for the Crate of the Week issue, maybe it's better for some more actionable rules.
Anyway...
I think you are changing the subject. We didn't discuss philosophy or ethics. The statement that I mentioned above exists on the forum from the beginning, and is very well on topic of the discussed subject. Whereas your last reply seem to me as a general thoughts around the subject, and is much irrelevant to the problem we discussed initially in the thread.
The forum's statement is about posting and discussing with others--not that much wide essentially.
Let's stop talking about in this thread this anyway, on the forum we have decide not to over discuss this in May.
And anyway this seems to have not mention Crate of the week. But I think we have both moved a little far.
I honestly don't understand why are you trying to wrap-up this discussion or to re-frame my ideas as off-topic. The OP raised a very specific meta discussion about the Crate of the Week and it's overflowing with LLM-generated content. And my comment was very well addressing this problem. It's not a philosophy, it is a very concrete rule. Your attempt to re-frame it or to push the discussion into general discussion about LLMs is in my opinion is an exact example of what @steffahn asked us not to do.
And that's exactly the problem OP is raising. Your comment above, in my opinion does not address it very well.
I think you should have that discussion in another thread; @Eliah-Lakhin was indeed trying to get you back on topic.
Your main argument is one I've already mentioned before; you're trying to push LLMs as a valid tool as if it were granted, but it's a very debatable opinion—you actually prove that point. So yes, that makes it something to treat specially and with caution.
Anyway, even without considering the validity of the output of such tools, there are concerns that are similar to other areas, as mentioned before.
That's why a rule similar to the one related to LLMs in the Rust project is worth considering, in my opinion, along with other solutions. It doesn't reject LLMs as a "tool" for those who need that, but it allows everyone to keep abuses in check.
I am discussing how can the rule that @Eliah-Lakhin has provide ('forbidding generated contents') be applied and whether it will cause paradox or any other trouble, and I have said about the CotW issue. But I understand now what @Eliah-Lakhin mean by this anyway, maybe I have misunderstand this a bit as I think it was too general.
I was discussing the ontology paradox, jurisprudence paradox and real world issue around this CotW problem, to reflect whether a strict ban or any kind of separate treatment may cause paradox or harm, and to propose plans. By no mean refer to the general LLM issue, not saying LLMs as a valid tool as if it were granted, and anyone who are looking at my words and seeing it as a political stand might himself be too sensitive or political. Although I understand and admit my wording might be a little too casual and apologize for the possible misunderstanding.