A pretty hefty and common misconception implied in the OP is that because Julia is performant in fewer lines of code and extensible and etc. that Julia can simply replace other languages in all contexts. That’s just not true, Julia made fundamental design choices with tradeoffs like any other language. Julia’s advantages are demonstrated in particular contexts, and while those contexts aren’t as narrow as people tend to make it out to be (e.g. “it’s scientific computing, not general-purpose”), it also demonstrably does not cover everything. It should not be surprising that in contexts where dynamic allocation is all but disallowed, it’d be very helpful if the language plainly declared any allocations, not needing runtime profiling on a more powerful system. It’s very plausible that Julia can get the tooling to be competitive in more contexts, but it won’t necessarily resemble the workflow in other languages. And that’s fine.
Benny
45
Related topics
| Topic | Replies | Views | Activity | |
|---|---|---|---|---|
| Julia: a post-mortem | 69 | 10870 | March 10, 2021 | |
| Losing Science Marketshare to Non-Python Languages | 30 | 3309 | September 21, 2022 | |
| What steps should the Julia community take to bring Julia to the next level of popularity? | 574 | 34221 | September 5, 2023 | |
| What can we do to make Julia grow fast? | 114 | 13839 | November 16, 2018 | |
| Can juliac increase julia adoption? | 61 | 4003 | April 14, 2025 |