Looking at generated assembly code for a Julia function is a pretty normal thing to do. I am an old C/C++ developer and find myself very much at home with Julia.
Sure I have used Python and Ruby before but those always make decisions around memory layout and code generation inaccessible.
Thinking about Julia as yet another Python, R, Ruby or a JavaScript is just wrong. It doesn’t really fit existing categories well.
Mathworks: the company that I wouldn't pay paying money to, if it wasn't such a ridiculously large sum. I don't have any issue paying for Jetbrains IDEs, but it's an order of magnitude smaller than Mathwork's yearly take.
[1]: https://www.youtube.com/watch?v=gQ1y5NUD_RI
Concretely, I joined the Julia slack and ran into a very welcoming community of people who helped me learn. Julia's like that so far.
Yes, I agree many data science people don't dive into internals - but for some reason these low-level details keep fascinating me so I don't mind some of the pain.
There is a lot of people wanting to use things like JuMP and handle numeric types where a single value is things like probability curves, and you want to use regular libraries with them, without having to rewrite those libraries.
Julia is really it's own beast, way way beyond R / Python.
It is friendly towards R dev's but, people who normally had to hack stuff in Fortran, C++, etc love it.
That's definitely a valid approach, but it's far from the only one employed in HPC.
Also another wannabe replacement, Chapel is relatively smart, trying to mix Fortran productivity for HPC code with Rust like memory management.
So love the idea, but regret the execution.