3 ms·

Extreme compatibility has a cost. If you're willing to give up some compatibility, you could get faster code that can be checked statically by transpiling to o

Extreme compatibility has a cost. If you're willing to give up some compatibility, you could get faster code that can be checked statically by transpiling to one of the many great choices from a set of statically typed languages. This is the approach taken by py14, pyrs and their successor py2many, on which I've been working for some months.

nextaccountic 5y ago
But it was the lack of 100% compatibility that hampered pypy's adoption. Anyway what are your incompatibilities?
- int_19h 5y ago
  It seems to be fully statically typed, for starters: https://github.com/adsharma/py2many/blob/main/doc/langspec.md https://github.com/adsharma/py2many/blob/main/doc/langspec.m... But, given LuaJIT and V8, it's obviously possible to generate high-performance code without such restrictions. As for PyPy adoption, it's hindered more by the lack of API compatibility with CPython native extensions.
  - adsharma 5y ago
    Yes - Julia also has a pretty good JIT too, but doesn't have a great story on AOT compiled binaries. If you're finding it easy to write a quick command line tool in python, but end up rewriting it in another language for size/performance/self contained deployment, this may be a good fit.
- adsharma 5y ago
  Doesn't use python's C API or runtime. So no metaclasses, monkey patching, eval(). All types must be known at compile time or it should be possible to infer them. There are several challenges to solve - translating stdlib of one language to another (see plugins.py) and bridge semantic gaps (rust doesn't like mutable global state, python has them).
  - nextaccountic 5y ago
    Does this mean that existing Python code - like dependencies on pypi won't be generally compatible? Without metaclasses and dynamic types I think it's better to call the language something else, and say it's Python-inspired (like Elm is Haskell-inspired)
    - adsharma 5y ago
      Renaming the language in the future is still a possibility. For now, all the tests here: https://github.com/adsharma/py2many/tree/main/tests/cases https://github.com/adsharma/py2many/tree/main/tests/cases are run with cpython interpreter and verified for compatibility. Even when there is a desire to innovate (design by contract or pattern matching as an expression), hope to do so without breaking cpython (as long as you stick to the subset).

nextaccountic 5y ago

But it was the lack of 100% compatibility that hampered pypy's adoption. Anyway what are your incompatibilities?

int_19h 5y ago
It seems to be fully statically typed, for starters: https://github.com/adsharma/py2many/blob/main/doc/langspec.md https://github.com/adsharma/py2many/blob/main/doc/langspec.m... But, given LuaJIT and V8, it's obviously possible to generate high-performance code without such restrictions. As for PyPy adoption, it's hindered more by the lack of API compatibility with CPython native extensions.
- adsharma 5y ago
  Yes - Julia also has a pretty good JIT too, but doesn't have a great story on AOT compiled binaries. If you're finding it easy to write a quick command line tool in python, but end up rewriting it in another language for size/performance/self contained deployment, this may be a good fit.
adsharma 5y ago
Doesn't use python's C API or runtime. So no metaclasses, monkey patching, eval(). All types must be known at compile time or it should be possible to infer them. There are several challenges to solve - translating stdlib of one language to another (see plugins.py) and bridge semantic gaps (rust doesn't like mutable global state, python has them).
- nextaccountic 5y ago
  Does this mean that existing Python code - like dependencies on pypi won't be generally compatible? Without metaclasses and dynamic types I think it's better to call the language something else, and say it's Python-inspired (like Elm is Haskell-inspired)
  - adsharma 5y ago
    Renaming the language in the future is still a possibility. For now, all the tests here: https://github.com/adsharma/py2many/tree/main/tests/cases https://github.com/adsharma/py2many/tree/main/tests/cases are run with cpython interpreter and verified for compatibility. Even when there is a desire to innovate (design by contract or pattern matching as an expression), hope to do so without breaking cpython (as long as you stick to the subset).