Our great sponsors
-
candy
🍭 A sweet, functional programming language that is robust, minimalistic, and expressive. (by candy-lang)
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
We're using some unstable features (hence nightly), and I just updated our Rust version on Thursday (https://github.com/candy-lang/candy/pull/948) because the previous one (nightly-2023-07-21) was too old for a dependency. So we're not usually using this recent Rust versions.
Thanks for letting us know about the binary size! We previously enabled debug info in release builds to use flamegraphs, but actually don't need it for most builds. I just disabled it (https://github.com/candy-lang/candy/pull/950), and the binary size went down from 177.4 MB to 14.2 MB for me!
The CLI should work, or at least we're using it regularly when working on Candy. Can you please share your OS and the command and output, maybe in a GitHub issue? We definitely need to improve our documentation and the CLI's error handling. Does running `cargo run --release -- run ./packages/Examples/helloWorld.candy` from the repository root work for you?
The VS Code extension also uses the CLI internally since that exposes a language server, so it basically runs `cargo run --release -- lsp`. But we also have to improve the stability here.
That's completely feasible and there are languages that do this. It doesn't really eliminate the need to run your program unless the inputs to your program are also completely restricted types like One, Two, Three. In which case yeah, you don't need to run it and the type system can just tell you the answer.
I believe you can do that sort of thing in loads of type systems, e.g. Typescript, but there are languages that intentionally support it. I use a niche DSL that has fancy types like this called Sail. https://github.com/rems-project/sail
In my experience the downsides of these fancy "first class type systems" are
1. More incomprehensible error messages.
2. The type checker moves from a deterministic process that either succeeds or fails in an understandable way, to SMT solvers which can just say "yep it's ok" or "nope, couldn't prove it", semi-randomly, and there's little you can do about it.
Still my experience of Sail is that it's very comfortable to go a little bit further into SMT land, and my experience of Dafny is that it's very unpleasant to go full formal-verification at the moment.
I've done a fair bit of hardware formal verification too and that's a different story - very easy and very powerful. I'm hoping one day that software formal verification is like that.