I have learned to ignore the inconsistencies in the languages that I have to use, especially if it's for a paying gig. Otherwise I would go crazy! Every single language has them, I'm not kidding.
UpperCamelCase: modules & types
snake_case: variables and functions
This convention is shared, for example, with elixir (also FP Lang)
Also bang_functions! By convention, not enforced, indicate that the function may mutate one of its passed parameters. (Taken from Ruby's "be careful with this member function" idiom)
@at_sigil: macros (enforced by the language)
What is Y%#$?
I'm happily getting my work done ~50x faster than python/numpy could offer (cython would be a massive headache for the fiddly numerical work I'm doing). Don't get me wrong I often still use Python + numpy for prototyping and non-scientific work but I switch to Julia for bigger numerical projects.
Python was around for a long time before Scipy took off. MATLAB is expensive, proprietary and I do not enjoy coding in it. C, C++ and Fortran are all fantastic for some kinds of numerical work but for what I do, the speed of development and readability are far superior in Julia whilst still yielding excellent execution speed.
edit: Regarding API stability mentioned in other comments, I'm not sure I agree as we are only just coming up to v1.0. However, even if the criticism is valid I'll still be developing numerical code faster in Julia with API changes than in C/C++/Fortran.
Also, there nothing really special about code that used to be in base, but is now in stdlib other than historical accident. It so happened that we used to ship a git client as part of the language, but the HTTP client was a separate package, despite the latter probably being a lot more useful to users. Packages can and do have their own stability guarantees. With the language itself maturing, I imagine package authors will start taking advantage of this more.
On the other hand, as far as I understand, 1.0 means that the API is stable but not that all 'luxury' features (debugger, Atom/VSC code integration, etc) are perfectly working and/or even ready. This will come in future (it needs a stable API).
