-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite in a real programming language #161
Comments
This seems relevant here: http://mypy-lang.org/. |
I agree that we don't want to wait very long, but we also need to have a high level discussion about this project in general and develop a strategy for it. Right now there hasn't really been any design and it's all been tactical. We need to |
There is a discussion happening at 17:30 UTC today that may help with the high level design a bit. |
FWIW, I favor Python because it's more expressive, and it's much easier to integrate into other systems (as many of them are written in Python today). |
I have some (brief and stale) experience with mypy. I liked it a lot for small codebase, but I realized it can't replace a real static type system because pervasive use of deply-nested-collections quickly results in unwieldy annotations or useless Looking at CL SDK, it contains ~8k of bash and ~1k of python (LoC) as of now. If we expect to have external contributors and reach similar size, I'd be happier to have a compiler in a CI step to catch silly mistakes instead of runtime errors in the pipeline. Regarding integration, I think the scope here is similar to mantle and the primary mean of consumption is via containerized CLI execution, not as a library importing. |
@lucab Are we assuming that we're working with Python 2? Because with the latest versions of Python 3, there's the ability to have the interpreter and bytecode compilation steps enforce the type checking. |
@Conan-Kudo No, just a language-agnostic comment with my view on scope and wishlist. I'd assume that we are speaking about py3 (barring any legacy lib). And you have a good point, I think that #174 is basically that. |
Deduping with #163 (mantle is Go) |
We started talking about this in #84, and it seems like we should decide on this soon-ish since the assembler is constantly growing and the longer we wait, the harder the rewrite will be.
To summarize, it seemed like the two likely candidates left were Python and Go. One point brought up in favour of Python was verbose error handling in Go, and another in favour of Go was static type checking.
The text was updated successfully, but these errors were encountered: