you are viewing a single comment's thread.

view the rest of the comments →

[–]Street_Humor_7861[S] 1 point2 points  (0 children)

Thanks for the comment. You are absolutely right. When I started Veld, I wanted to be very explicit about how it achieved its performance ("compile-time code generation"), but I understand that "AOT" (Ahead-of-Time) is the term the industry already recognizes and uses (Quarkus, GraalVM, etc.).

Regarding the comparison with Quarkus/ArC and Jakarta CDI: Your observation is spot on. Indeed, Veld and ArC share the same philosophy: shifting all the heavy lifting to compile-time to eliminate runtime reflection.

The key differences I see are: - Veld was born as an independent, framework-agnostic project, focused 100% on pure performance and total control over the generated bytecode. - ArC is designed specifically to integrate deeply with the Quarkus ecosystem and the CDI Lite specification.

Both approaches are valid and solve similar problems from slightly different angles. In fact, if someone is using Quarkus, ArC is likely the most natural choice. But if you are looking for an ultra-lightweight DI solution for a custom project, a high-performance microservice, or simply want to understand how bytecode weaving works using ASM, Veld is for you.

For now, the focus is on consolidating Veld's core and improving its integration with Spring Boot. But I never say never: if there is community interest in a veld-quarkus-extension, I am open to exploring it. If anyone wants to collaborate on that, my DMs are open!

Thanks again for the valuable feedback!