function julia_blues(bummers...)

The stupidest, (stupidest in the sense that I really wish they didn't bother me, because they're silly things!), things that bother me are:

1. The 'end' keyword. It's everywhere! Loops, if-else statements, function bodies. I mean I understand why it's helpful for parsing and providing more info to the compiler, but honestly, I would've rather we just stuck with curly braces '{}'! At least it's fewer characters to type and it just feels less crowded on screen while reading. It feels like such a petty complaint, but honestly, it feels like I'm writing Pascal or Matlab all over again. Which leads me to my second point.

2. The default choice of 1 based indexing. I'm not going to go into it, because plenty of people before me have beat this dead horse already[1][2][3], but I can't help but be saddened by this choice and its implications. It's important to acknowledge the fact that Julia started as a competitor to Matlab and Octav, so it makes sense from that perspective. However, it could have been a much more general purpose language, with huge performance benefits over popular interpreted languages like Python, JS, and Ruby. It could have been a unifying force in the scientific computing community, bridging the gap between R and Python users with a greenfield approach that would have been a force to be reckoned with. Instead, rightly or not, it's viewed largely as 'just' a matlab replacement.

Now, regardless of whether 1 or 0 based indexing is truly 'better' or the 'end' keyword is no big deal, the reality is that there's a huge demographic of potential users that won't buy into Julia, because it doesn't quite feel as ergonomic as Python/JS/Ruby and won't take it seriously as a general purpose language, because it looks/feels like Matlab and they only use 'real' programming languages. Again, I'm not saying this is right, but it is the reality we're faced with and it just feels like a huge missed opportunity and bums me out.

  end

Julia claims to be the future of numerical computing, but they seem to put more effort into coming up with fancy abstractions that no engineer or scientist will ever understand than working on basic numerics. For example, the array implementation is very hit or miss and much much slower than and has much more complicated semantics than arrays in Fortran. I think this is due to the fact that arrays are not first class objects in the language, and probably because the authors don't do much multidimensional high performance work.

Everything else - even much of the type system - is extremely interesting. However the inability to subtype concrete types means you are essentially stuck with the unfortunately common inability to trivially specify how the heck your program is modeling your problem.

I just want the ability to specify an Apple_Count is not an Orange_Count without having to define my own damn operators. Why do so many languages make this so hard?

And Julia was so close, until one little sentence moved it so far away.

I think of Julia as statically duck-typed, which sounds cursed but is incredibly useful IMO. like if you have `foo(x,y,z)=x+ycow(z)`, foo() will work for any x and y with compatible `+` operators, if there's a `cow()` that will accept whatever type `z` is. But it's still static - your code will throw a compile error* if x and y can't be added, or if cow() won't take your z. And unlike Python, Julia can dispatch on types, so you can implement cow() for whatever you want. the type system is, in fact, absurdly powerful. the downside seems to be that it's formally undecidable sometimes, and that you fundamentally can't enforce output types for functions passed as arguments.

the speed is a drag, but it feels like getting a train up to speed - it's slow getting ready to do absurdly heavy lifting.

I think that Union types do more harm than good (why would you want a function to return Union of int and float instead of compile error? It totally slows down the program)

Array{Number} is totally different from Array{:<Number}, and shouldn’t be allowed, as it is inefficient.

1-based indexing was a mistake, and I have seen it emitting inefficient code in the PTX compiler.

But the worst and hardest part is the rule/heuristic for multiple dispatch: it’s so complex, that it isn’t even documented. It should probably throw more errors and be predictable instead of trying to be so smart.

You need deep understanding of the compiler to know what constructs will mess up performance. Especially how typeinfo is propagated.

In seriousness I have been enjoying it a lot over Python, but I'd kill for static typing.

It's highly expressive (comprehensions, functional-style all-statements-are-expressions, anonymous named tuples, and heaps more) and these features seem to be usable without sacrificing performance, in a way that I've not yet seen in any other language.

I took a dip in to Julia recently, and found it to be a mishmash of Lisp, Haskell, Matlab and Fortran ideas, wrapped in Python-like syntax.

I guess that can be appealing for people coming from those worlds, and for those for whom speed trumps everything else.

For me the loss of a Lispy syntax and the price of working with a relatively immature language wasn't worth it for me. I'd just rather use something with reasonable performance that's more Lispy.

- First, code that is intentionally (or out of neglect) opaque to the compiler. For example, someone may simply forget to write type stable code, or someone might intentionally create a function barrier to specialize some code

- Second, Julia has no standard way of encoding constrains on types. That's good, because someone else can make up a new type you never thought about, and throw it into your functions, and if it has implemented all the right methods, it will work. But it also means you can never guarantee your code will work for any type.

- Third, Julia encodes less information in the type system - e.g. the use of result types is not common.

Multiple dispatch is such a great way not to have to write boilerplate code for every method, somehow java seems very awkward in comparison.

Julia feels like a thoughtfully designed and carefully constructed language. I don’t havd the training to understand why exactly.

I'm not particularly convinced that Julia's object model leads to inefficient memory access either.