I learned seven programming languages
&gt; I like named parameters for self-documenting code. Julia allows named parameters but naming them doesn&#x27;t provide any flexibility with regard to their position when calling the function.<p>I don&#x27;t understand this complaint? &quot;Named parameters&quot; i.e. keyword arguments in functions work great in Julia!<p><pre><code>    julia&gt; foo(;x = 1, y = 2, z = 3) = x + y + z
    foo (generic function with 1 method)

    julia&gt; foo(; z = 4, y = 0)
    5
</code></pre>
Perhaps the author meant default arguments?<p><pre><code>    julia&gt; foo(x = 1, y = 2, z = 3) = x + y + z
    foo (generic function with 3 methods)

    julia&gt; foo(3)
    8

    julia&gt; foo(0, 0, 0)
    0
</code></pre>
&gt; this flexibility does tend to cause bugs working with other people&#x27;s code. This is compounded by Julia&#x27;s pursuit of composability. If you cram your custom data value into someone else&#x27;s function, and if it seems to be the right shape, it will probably work! Unless it doesn&#x27;t. In that case you just get silently wrong answers. This is a deal-breaker for a lot of scientific computing people where Julia would otherwise shine.<p>This is almost entirely mitigated by most people using `eachindex` or `axes` or other functions that make the array related code index agnostic. The only reason I say <i>almost</i> entirely is because there&#x27;s probably some really old code that doesn&#x27;t work the right way and would silently fail or do the wrong thing if you changed the indexing convention. That said, calling this a &quot;deal-breaker for scientific computing&quot; seems extreme.<p>&gt; I also find Julia&#x27;s errors to be fairly obtuse. And I see a lot of them because dynamic typing means the tools can&#x27;t catch most errors before run-time.<p>I 100% agree. Julia errors are my biggest gripe with the language at the moment.<p>&gt; But the big dealbreaker with Julia is it only complies on the fly. That means you can&#x27;t just hand a compiled executable to someone. You must give them instructions to install Julia and all your dependencies first. That&#x27;s no good for anything you want to ship like a desktop app or a game. You also don&#x27;t want Julia on your server recompiling with every web request.<p>There are packages like PackageCompiler that work pretty well. And I&#x27;m positive in the near future (3 years?) we&#x27;ll have a version of Julia where PackageCompiler will produce small binaries. That said, the convenience of writing in Julia and shipping a precompiled app is pretty awesome, and I personally don&#x27;t mind it taking more space on disk.<p>&gt; Like all compiled languages, the development cycle involves a lot of recompiling as you go. For small programs it doesn&#x27;t matter, but this creeps up as the program grows -- or when you add a heavy dependency, like a plotting library. Julia suffers from this compiled-language drawback, but without the normal advantage of getting a compiled executable you could distribute.<p>This used to be one of my biggest gripes, but things have gotten a lot better with every version of Julia.<p>----<p>My first order approximation when picking a language is this:<p>1) if I think it&#x27;ll be easy to write in Python, I should write it in Julia. 
2) If I want to ship a precompiled binary that exposes a command line interface, I&#x27;ll think about using Julia first, and if the size of the binaries are an issue, I might pick Rust.<p>wrt to Nim, I&#x27;m waiting to see how the ORC story shakes out + better documentation about ORC to appear on the scene and for more packages to adopt it. I think Nim currently has too small a community. I&#x27;ve found packages that are commonplace in Rust or Julia are just not even available in Nim. Sometimes a package is 5 years old and hasn&#x27;t been updated. Yes, it is easy to write interfaces but that requires a lot of work. If it is a project where I&#x27;m writing code just by myself, Nim might be a good choice but if I&#x27;m working with someone else, having them learn Nim is much harder. The error messages in Nim also need to get better in my opinion.<p>&gt; You don&#x27;t have to decide between snake_case or camelCase. You can define your variable either way and both references will work. Ditto for most cases of capitalization. I thought this might be problematic, but in practice it&#x27;s brilliant. I think that sentiment applies to many of Nim&#x27;s unexpected design choices.<p>I personally don&#x27;t like this at all. Every time I search a nim codebase, I have to use `nimgrep` instead of using `ripgrep`. I have SO many aliases built on top of things like `ripgrep` and `fzf` and none of them are certain to work in `Nim`. It&#x27;s frustrating that the community is so divided on this, because even though I can see there are benefits to this approach, the benefits pale in comparison to getting user adoption and buy in to use the language.<p>One of my senior developers on my team agreed to learn Nim in their spare time as a favor to me, to evaluate it for a project at work, and as soon as they came across this &quot;feature&quot; they were so turned off, they wrote the language off as being too weird.<p>There&#x27;s a LOT of average programmers out there, and a lot more analysts and data scientists that just want to get shit done, and from personal experience I think it&#x27;s extremely hard to get adoption for Nim in the scientific community. If 7 out of 10 people have used Python, 4 out of 10 people may have heard of Julia and heard that it&#x27;s new and modern, but 0 people have even heard of Nim. I&#x27;ve gotten SO many quizzical looks over the years, it is not even funny.