# What steps should the Julia community take to bring Julia to the next level of popularity?

**URL:** https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389
**Category:** Community
**Created:** [July 9, 2023, 9:59am UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389 "2023-07-09T09:59:36Z")
**Posts on this page:** 1
**Showing post:** 637

<div class="post-metadata">

### Author: ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [September 4, 2023, 8:32pm UTC](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389/637 "2023-09-04T20:32:45Z")

</div>

> [@ParadaCarleton](#):
>
> Other examples of poor defaults that are easy to miss when you’re learning Julia:
> 
> 1. FMA (not default because it could confuse devs if someone ran a computation on a pre-2008 computer)
> 2. The inability to use positional arguments with keywords (because then, developers wouldn’t be able to change the names of positional arguments without breaking user code)
> 3. Defaulting to single-threading instead of threads=n\_cores (held up by complaints this would be a bad default for large-scale computing)
> 4. Extremely long stacktraces filled with nested type declarations (implementation held up by complaints that it could result in users not posting the full stacktrace in Github issues)
> 5. Performance footguns like type instabilities and eager functional [primitives](https://viralinstruction.com/posts/badjulia/#functional_programming_primitives_are_not_well_designed) (maybe 80% of the mistakes I find in PRs by newer users)
> 6. No compile-time errors when static analysis catches likely mistakes, like method ambiguities.

100% agreed on all of those, though that’s not a surprise since I might be the one who has opened each of those issues in Base 😅, or at least brings them up in #gripes when they aren’t fixed.

The philosophy should be: **whatever is best for the inexperienced user for the 90% use case**

HPC users have to figure something extra out to get a bit more performance? Whatever. That’s the kind of user that comes from C++/Fortran that knows how to read intense API docs. Why should an undergrad get 1 threaded runs and not know why Julia is slow in order to preference the PhD in computer science doing the 1000 core HPC runs not having to add `-t 1` to their build script? Why give a giant stacktrace just in case a dev might want the full thing in the future? Just ask for more when you need it (and honestly, what’s chopped off is essentially never useful… at least the `{...}` new stuff).

> [@Naming positional arguments at call site](https://discourse.julialang.org/t/naming-positional-arguments-at-call-site/103526/27):
>
> Not particularly. People liked PyTorch because eager mode was more intuitive and produced readable error messages, and also because it was more readable than TensorFlow. These are the main reasons any ML developer will give if you ask them why they switched.

We look so much at Jax because it’s faster, when in reality PyTorch has almost all of the mindshare because it’s easier to use.

---

_[View the full topic](https://discourse.julialang.org/t/what-steps-should-the-julia-community-take-to-bring-julia-to-the-next-level-of-popularity/101389)._