# Discussion on "Why I no longer recommend Julia" by Yuri Vishnevsky

**URL:** <https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151>\
**Category:** Community\
**Tags:** discussion\
**Created:** [May 16, 2022, 2:33pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151 "2022-05-16T14:33:38Z")\
**Posts on this page:** 1\
**Showing post:** 250

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [June 16, 2022, 7:35pm UTC](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151/250 "2022-06-16T19:35:08Z")

</div>

> [@Bruno\_Amorim](#):
>
> Numba is an a posteriori solution, while Julia is designed from the ground to be compiled and interactive from the beginning.

Hit the nail on the head. Numba is designed to recompile the compiled bytecode of Python functions that use a subset of NumPy, so you must write valid Python. To deviate from Python syntax, you need something like Cython where the source files are compiled differently from the start. Considering that Numba has an LLVM-based just-ahead-of-time compiler, if implementing non-Python/NumPy features wouldn’t sacrifice the important aspect of Python compatibility, I’ll bet that the developers would overhaul their multiple dispatch, implement syntax for type parameters, introduce named structu- oh this is Julia.

---

_[View the full topic](https://discourse.julialang.org/t/discussion-on-why-i-no-longer-recommend-julia-by-yuri-vishnevsky/81151)._