Skip to content
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

Closed
jlebon opened this issue Oct 10, 2018 · 8 comments
Closed

Rewrite in a real programming language #161

jlebon opened this issue Oct 10, 2018 · 8 comments

Comments

@jlebon
Copy link
Member

jlebon commented Oct 10, 2018

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.

@jlebon
Copy link
Member Author

jlebon commented Oct 10, 2018

This seems relevant here: http://mypy-lang.org/.
Anyone has experience with this?

@dustymabe
Copy link
Member

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 udevadm settle the tactical changes (i.e. get in what we need for now so it can be useful in the short term) and then kinda freeze on that while we rewrite with toplevel design in mind.

@dustymabe
Copy link
Member

There is a discussion happening at 17:30 UTC today that may help with the high level design a bit.

@Conan-Kudo
Copy link

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).

@lucab
Copy link
Contributor

lucab commented Oct 18, 2018

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 Any everywhere.

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.

@Conan-Kudo
Copy link

@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.

@lucab
Copy link
Contributor

lucab commented Oct 18, 2018

@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.

@cgwalters
Copy link
Member

Deduping with #163 (mantle is Go)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants