# Julia vs Pyccel: a Python-to-X transpiler for scientific high-performance computing

**URL:** https://discourse.julialang.org/t/julia-vs-pyccel-a-python-to-x-transpiler-for-scientific-high-performance-computing/110904
**Category:** Offtopic
**Created:** [February 28, 2024, 3:45pm UTC](https://discourse.julialang.org/t/julia-vs-pyccel-a-python-to-x-transpiler-for-scientific-high-performance-computing/110904 "2024-02-28T15:45:39Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [February 28, 2024, 3:45pm UTC](https://discourse.julialang.org/t/julia-vs-pyccel-a-python-to-x-transpiler-for-scientific-high-performance-computing/110904/1 "2024-02-28T15:45:39Z")

</div>

I noticed Pyccel has a this still open discussion from long ago, recently added to:

> **[Implement multiple dispatch · pyccel/pyccel · Discussion #1334](https://github.com/pyccel/pyccel/discussions/1334)**
>
> Describe the bug Sometimes we want different functions to run different methods depending on the type. In python this is often handled with the isinstance decorator, however in pyccel this would be...

And while it may get that feature, or not, Python already has in a package:

> **[multipledispatch](https://pypi.org/project/multipledispatch/)**
>
> Multiple dispatch

I don’t think Python will get inherently get better than Julia (with tools and/or Mojo), but I note it’s a dynamic language like Julia (Python even more dynamic), compiling (subsets of Python, I think no tool handles all) to static languages Fortran and C, for speed.

I’m thinking Julia could actually do that compile to another language, to get e.g. C code (like Pyccel, human readable), and static binaries from e.g. Julia language library code… or for full apps.

I’m thinking is there a subset of Julia that we could, and should, standardize as a static language subset (or if not strictly a static language subset, then something that can compile to such a language)? I don’t think code working for StaticCompiler.jl is it, i.e. it’s too restrictive, see need something that supports way more already working Julia code. One of its downsides is not allowing GC, and it’s a blocker for much else, and code in Julia Base, that would otherwise work.

Julia wouldn’t be the first language to have a subset, e.g. D has a betterC subset, but it also means much of D’s standard library is unusable. We could have such a subset (already do), one with GC (a superset of it) and full.

> **[Pyccel: a Python-to-X transpiler for scientific high-performance computing](https://joss.theoj.org/papers/10.21105/joss.04991)**
>
> Bourne et al., (2023). Pyccel: a Python-to-X transpiler for scientific high-performance computing. Journal of Open Source Software, 8(83), 4991, https://doi.org/10.21105/joss.04991

> <https://github.com/pyccel/pyccel/pull/886>
>
> Add internal libraries to facilitate the definition of the wrapper file. 
> Fixes… #758 
> Fixes #806 
> This branch sometimes leads to a small slowdown, but it is not clear why that is the case. We suspect that the slowdown only occurs when translating simple files containing 1 function, but that a speedup should be seen when translating a module containing many functions
> 
> \*\*Commit Summary\*\*
> \- \[CODACY\] Remove unused imports
> \- Split \`ast.cwrapper\` into 2 modules. The new module \`ast.numpy\_wrapper\` contains all the functions which interact with the numpy library
> \- Make the compiler dependencies an ordered dictionary
> \- Ensure that \`.h\` files include as few other \`.h\` files as possible (speeds up compiling)
> \- Add docstrings to \`CWrapperCodePrinter\`
> \- Create \`cwrapper/cwrapper.c\` and \`cwrapper/cwrapper\_ndarrays.c\` to store all functions useful for converting between python and C
> \- Use functions to simplify \`CWrapperCodePrinter\`
> \- Put \`numpy\_version\` into its own file to allow it to be imported by \`cwrapper.c\`, be adaptable to the user's system, and be defined somewhere where \`NPY\_1\_19\_API\_VERSION\` is defined
> \- Add \`cwrapper/cwrapper.c\` and \`cwrapper/cwrapper\_ndarrays.c\` to the shared library creation step
