# Analysis of largescale python vs largescale julia?
**URL:** https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942
**Category:** General Usage
**Created:** [February 21, 2023, 2:26am UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942 "2023-02-21T02:26:33Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@zeroexcuses](https://discourse.julialang.org/u/zeroexcuses)
#### Post date: [February 21, 2023, 2:26am UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942/1 "2023-02-21T02:26:33Z")
Does anyone have recommendation on article for largescale python codebase vs largescale julia codebase ?
I’m fairly convinced Julia unlikely to replace OCaml / Scala for me, but I’m curious on reading about managing largescale julia codebases vs largescale python codebases.
The main issue I have with largescale python codebases are (1) dynamic typing and (2) GIL.
For Julia, the two issues I’m curious about are:
1. I’m quite convinced JET.jl is not going t match OCaml / Scala typing any time soon. I’m curious if Julia is better than Python for managing large scale codebases.
2. I’m also curious how Julia’s multi-process / async compares to Python’s GIL.
Thanks!
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [February 21, 2023, 6:44pm UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942/2 "2023-02-21T18:44:31Z")
Julia has a number of advantages over python for large codebases.
1. The package manager. Good package management makes it a lot easier to use external dependencies and large projects can often be effectively organized as a set of independent packages
2. Lack of 2 language problem. Most big python codebases have to call out to C at some point if they want high speed. This adds a bunch of complexity.
3. Built in multithreading. There’s no GIL. Julia supports async, multithreaded, and multiprocess code.
4. A lot faster. If your programming language is (~50x faster than python is roughly correct), you often don’t need multithreading/multiprocessing at all.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [February 21, 2023, 7:04pm UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942/3 "2023-02-21T19:04:55Z")
> [@zeroexcuses](#):
>
> I’m curious if Julia is better than Python for managing large scale codebases.
Python has a static typing system and static checkers with huge corporate investment. Julia’s is new and marginal.
> [@zeroexcuses](#):
>
> I’m also curious how Julia’s multi-process / async compares to Python’s GIL.
- For IO-intensive work, Python’s async/await is fine.
- For process-based CPU-intensive parallelism, tools like Dask work well, similar to Dagger.jl.
- For thread-based parallelism in CPU-intensive code, Python libraries written in C/C++/Fortran work well; pure-Python code does not work well for CPU-intensive tasks, because of the GIL.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [February 21, 2023, 7:08pm UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942/4 "2023-02-21T19:08:13Z")
IMO process based parallelism is almost always a mistake unless you’re doing multi-computer HPC. Threads are a ton lighter weight, and sharing memory is a lot more efficient than copying data around.
---
### Author:  [@paulmelis](https://discourse.julialang.org/u/paulmelis)
#### Post date: [February 21, 2023, 7:53pm UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942/5 "2023-02-21T19:53:05Z")
> [@jar1](#):
>
> Python has a static typing system and static checkers with huge corporate investment.
Ehm, the Python language itself has only dynamic typing (and optional type annotations, but those are ignored by CPython)? Perhaps you mean the optional static type-checkers, like mypy?
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [February 21, 2023, 8:09pm UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942/6 "2023-02-21T20:09:27Z")
> [@Oscar\_Smith](#):
>
> IMO process based parallelism is almost always a mistake unless you’re doing multi-computer HPC. Threads are a ton lighter weight, and sharing memory is a lot more efficient than copying data around.
unless you’re GC limited 🙂 and Julia GC sucks in some edge cases and multi-process is a way to get free parallel GC
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [February 21, 2023, 8:12pm UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942/7 "2023-02-21T20:12:40Z")
> [@jar1](#):
>
> because of the GIL.
> **[The 2022 Python Language Summit: Python without the GIL](https://pyfound.blogspot.com/2022/05/the-2022-python-language-summit-python_11.html)**
>
> If you peruse the archives of language-summit blogs, you’ll find that one theme comes up again and again : the dream of Python without the...
I can imagine they removing it
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [February 21, 2023, 8:13pm UTC](https://discourse.julialang.org/t/analysis-of-largescale-python-vs-largescale-julia/94942/8 "2023-02-21T20:13:59Z")
Yes, static type checkers (Mypy, Pytype, Pyright, Pyre) are optional, but they are widely used and well supported.