prometeo VS StaticCompiler.jl

Not impossible but I guess you might end up with an extra runtime layer and some more dynamic operations will not be very fast. Or you restrict it to a subset of Python like this project does: https://github.com/zanellia/prometeo

You could of course write a bytecode VM in Golang but I guess that defeats the purpose.

Honest question: How does pycom compare to similar tools like Nuitka, prometeo, or mypyc?

If you don't mind switching to a little different syntax of Python, then you also might want to take a look at prometeo - an embedded domain specific language based on Python, specifically aimed at scientific computing. Prometeo programs transpile to pure C code and its performance can be comparable with hand-written C code.

This is awesome! The direction of using a subset of python, while leveraging the user base and static typing to accomplish some other everyday task in a different language is very legit IMO.

I took a cursory look at:

https://github.com/zanellia/prometeo/blob/master/prometeo/cg...

It seems quite similar in spirit to

https://github.com/adsharma/py2many/blob/main/pyrs/transpile...

I'm not spending much time on py2many last few months (started a new job). Let me know if any of it sounds useful - especially the ability to transpile to 7-8 languages including Julia, C++ and Rust.

Yes, julia can be called from other languages rather easily, Julia functions can be exposed and called with a C-like ABI [1], and then there's also various packages for languages like Python [2] or R [3] to call Julia code.

With PackageCompiler.jl [4] you can even make AOT compiled standalone binaries, though these are rather large. They've shrunk a fair amount in recent releases, but they're still a lot of low hanging fruit to make the compiled binaries smaller, and some manual work you can do like removing LLVM and filtering stdlibs when they're not needed.

Work is also happening on a more stable / mature system that acts like StaticCompiler.jl [5] except provided by the base language and people who are more experienced in the compiler (i.e. not a janky prototype)

[1] https://docs.julialang.org/en/v1/manual/embedding/

[2] https://pypi.org/project/juliacall/

[3] https://www.rdocumentation.org/packages/JuliaCall/

[4] https://github.com/JuliaLang/PackageCompiler.jl

[5] https://github.com/tshort/StaticCompiler.jl

PackageCompiler, but it' s a fat runtime and not cross compile. A thin runtime is currently not possible without sacrifices for feature as https://github.com/tshort/StaticCompiler.jl.

https://github.com/tshort/StaticCompiler.jl/issues/59 Would working on this feasible?

I just read the project's documentation at https://github.com/tshort/StaticCompiler.jl. It does produce a "hello world" application that is only 8.4k in size 👍. I do like that it can work on Mac OS. Hopefully Windows support will come soon.

See https://github.com/tshort/StaticCompiler.jl

You're probably dancing around the edges of what [PackageCompiler.jl](https://github.com/JuliaLang/PackageCompiler.jl) is capable of targeting. There are a few new capabilities coming online, namely [separating codegen from runtime](https://github.com/JuliaLang/julia/pull/41936) and [compiling small static binaries](https://github.com/tshort/StaticCompiler.jl), but you're likely to hit some snags on the bleeding edge.

using StaticCompiler # `] add https://github.com/tshort/StaticCompiler.jl` to get latest master