[srparish]

* lack of threads: they do support multiple processes which can be useful for splitting up work for large computation, but not a substitute for threads

* module compilation is not cached, so if you use very many modules your start-up times can be slow

* error messages sometimes require some head scratching. For example, it's not uncommon to get an error that there's no available function convert(::SomeType, (Some, Args)) when there's no obvious convert() to be seen in the code in question. Occasionally the stack trace will be missing from errors, or there won't be a line number. Obviously this is improving quickly, but can be frustrating.

[simonster]

The first two are both WIP. Threading is https://github.com/JuliaLang/julia/tree/threads (although it hasn't been updated in a little while) and static compilation of modules is https://github.com/JuliaLang/julia/pull/8745

[srparish]

That's great to see. It's sometimes hard to keep up with everything that's going on. Incidentally I really got a kick out of the recent s/Uint/UInt/ rename (https://github.com/JuliaLang/julia/issues/8905). It took a day or so to propose and do it. To compare, java will probably never fix it's spelling oddities (for example int and Integer). Very refreshing to see fundamental things like that be fixed and so quickly!

[StefanKarpinski]

Just to play devil's advocate about the Java capitalization, I suspect the difference between `int` and `Integer` is quite intentional: `int` is a "primitive", immutable value type, while `Integer` is a class. Since by convention, Java's classes are capitalized, while its primitives are spelled the way they are in C, there's some sense here.

[ViralBShah]

Our error messages do require a fair amount of work and so do line numbers in stack traces. Keno's debugger is almost ready though, and will greatly help.