Am I using Julia right?

I think this topic is closely in a line with a discussion that was already going on the Julia-users group Does Julia really solve the two-language problem? and I would like to cite here one paragraph from that discussion:

@Stefan Karpinski:

There are different styles and levels of writing code in every language. There's highly abstract C++ and there's low-level pointer-chasing C++ that's basically C. Even in C there's the void*-style of programming which is effectively dynamically typed without the safety. Given this fact, I'm not sure what solving the two language problem would look like from the perspective this post is posing. Enforcing only one style of programming sounds like a problem to me, not a solution. On the contrary, I think one of Julia's greatest strengths is its ability to accommodate a very broad range of programming styles and levels.

My own experience in Julia programming, shows that it can fill the blank box of a modern programming language that could bring high level features like parallel processing, socket server and ... in the hand of scientists, engineers and all computation gurus and pragmatic programmers that want to do their work in an efficient, maintainable and readable manner, using an all-in-one programming language.
In my opinion you are using Julia in the right way, Julia like other languages represents different styles of programming for different situations, you can optimize bottlenecks for speed, and keep the other parts more readable. also you could use tools like Devectorize.jl to avoid rewriting issue.

This is a difficult question to answer satisfactorily. Therefore I'll try to make a short contribution in the hope that a "pot" of different opinions might be good enough. So here are 3 opinions going through my mind currently:

1. A programming language may be likened to an object with momentum. The user-base being its mass and their styles exerting force on it. The initial users/developers can pull a language in a certain direction because it still has low mass. A language can still evolve even if extremely popular (e.g. C/C++), but it's harder. The future of Julia is still unwritten, but its promise is in the initial direction imbued by its creators and early users.

2. Optimization is best delayed until correctness is well tested. "Premature optimization is the root of all evil" (D. Knuth). It never hurts to remember this, again. So, keeping the code readable and correct is better until the optimization stage which may obfuscate bounded areas of the code.

3. The expression sum([x*y ...]) may require the compiler to be too clever, and it might be better to simply define a sumprod(x,y). This would allow sumprod to harness the generic function multiple dispatch framework of Julia and stay optimized for x and y and possibly later even more optimized for specifically typed x and y.

That's it, for now. Opinions are many. So let the discussion continue.