* Strings: Codon currently uses ASCII strings unlike Python's unicode strings.
Judas priest, after all the effin' grief we went through to learn how to handle Unicode strings in Python 3, and to finally begin to realize their value, you take this step backward? Forget the i64 limits, the lack of native Unicode strings is a flat deal-breaker. (For example, will Codon warn if it sees an "open(encoding='UTF8')" call? Or a normal open(mode='rt') if the default local encoding is UTF8?)
It doesn't help that the same doc also mentions that
* Dictionaries: Codon's dictionary type is not sorted internally, unlike Python's
Current Python dicts are not "sorted"; rather they "preserve insertion order, meaning that keys will be produced in the same order they were added sequentially over the dictionary."[2]
This is new functionality added only recently (3.7) so its lack would not inconvenience a lot of existing code. OTOH, why did they not plan to reproduce this useful feature from the start?
Possibly they were thinking of the pypi package SortedContainers[3]?
[1] https://docs.exaloop.io/codon/general/differences
[2] https://docs.python.org/3/reference/datamodel.html#index-30
Makes me very suspect about the rest of this project when they try to glide past all of these issues with nary a mention.
I don't feel they are trying to glide past anything. It's the first post in the series about a product in 0.x state, it's gotta start somewhere other than perfection and they seem to know that.
Looks like you can use bigger integers and they're very explicit about it not being a drop-in replacement for Python
If I recall it really wasn't that much faster than CPython given the overhead, but it's been a long time; if it was faster I assume it wouldn't have been abandoned.
The blog post here mentions they do their own optimization passes, before handing over to LLVM. I imagine that's pretty important.
Don’t think of it as a Python compiler, it is its own language. (Esp. re choice of int == i64, this saves SO MUCH computation for the CPU.)
I will say though that I’m not sure where to use it yet, since it’s too immature for important projects and also aims at the “we need a nuclear bomb” level performance.
> Please reach out to... to inquire about about a production-use license.
Having "contact us" pricing with several incompatibilities makes this pretty hard to consider in a commercial environment. I wish they had a public pricing structure.
From their faq: https://docs.exaloop.io/codon/general/faq.
You can be efficient without sacrificing correctness; using LLVM shouldn’t mean “throw out arbitrary-precision semantics”.
"While Codon does offer a JIT decorator similar to Numba's, Codon is in general an ahead-of-time compiler that compiles end-to-end programs to native code. It also supports compilation of a much broader set of Python constructs and libraries."
