Replies: 3 comments
-
I hope there is a future with this feature and do look forward to its continued existence! Moving this to another layer or a distinct phase sounds good to me
I would be terribly disappointed to lose the fantastic build system zetz has to offer, but I understand the sentiment. While cmake is popular, it isn't for everyone. I'd hope to see support for it without the loss of the current build system
I really do enjoy how |
Beta Was this translation helpful? Give feedback.
-
yeah i mean, not much reason to drop it beyond "cmake is more popular", which i dont care about in the first place. It works ok~ish (except macros are kind of unstable) and is reasonably easy to maintain.
this is probably the most difficult decision. I like it, but i'm not willing to invest the time it requires to make it good. |
Beta Was this translation helpful? Give feedback.
-
totally agree 🙃
yeah, that sounds like a good idea |
Beta Was this translation helpful? Give feedback.
-
long intro
Zetz has been a very interesting experiment in how far formal proving can help with true zero runtime cost. I created zetz because i needed higher confidence than raw C, while still targeting machines that only will ever support C, such as microcontrollers, bootloaders, and obscure vendor specific HPC clusters. It's a great tool that works well for the things we do at devguard.
However, it's always been clear that this is a tiny niche. Most developers are not business people and will prioritize peer approval over cost efficiency. There's no incentive for me or anyone else to make zetz any bigger. Creating a community like nodejs is a multi million dollar effort that only has a financial return if you focus on the broadest possible audience.
There's a mininum bar i still want to clear with zetz, simply because i don't like to build my own business on shaky foundations.
In order to declare zetz stable, we need to reduce the featureset to a point where it's actually confidently bug-free.
the relevant part
reducing the scope is a 2 part effort.
i'd apprechiate everyones input. I'll start with my ideas, but all of these are up for discussion.
smt proving
this was fun as we've proven it works! someome with more determination can likely integrate the learnings into a real product.
However, i do not have the time or passion to read the latest algorithmic papers.
i'm proposing to remove almost all of the solver, eventually adding it back as something on-top that only runs during a special proofing phase.
emitting language interfaces
emitting rust, go and nodejs turns out to be the greatest strength of zetz for commercial use. It's pretty easy to create very fast libraries that just work in nodejs. However, there is swig, and i think i should spend some time researching if this can be integrated instead.
build system
the simple build system is surprisingly good. i often find myself just creating a zetz project to compile some C. However, people like cmake alot, so i do wonder if we should just drop the build system.
high level language sugar
things like the new call are highly specific to the way zetz prefers stack allocation. I think thats fine and i intend to keep it although it clearly means zetz will stay in its niche.
Beta Was this translation helpful? Give feedback.
All reactions