> I like named parameters for self-documenting code. Julia allows named parameters but naming them doesn't provide any flexibility with regard to their position when calling the function.
I don't understand this complaint? "Named parameters" i.e. keyword arguments in functions work great in Julia!
julia> foo(;x = 1, y = 2, z = 3) = x + y + z
foo (generic function with 1 method)
julia> foo(; z = 4, y = 0)
5
Perhaps the author meant default arguments?
julia> foo(x = 1, y = 2, z = 3) = x + y + z
foo (generic function with 3 methods)
julia> foo(3)
8
julia> foo(0, 0, 0)
0
> this flexibility does tend to cause bugs working with other people's code. This is compounded by Julia's pursuit of composability. If you cram your custom data value into someone else's function, and if it seems to be the right shape, it will probably work! Unless it doesn'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.
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 almost entirely is because there's probably some really old code that doesn'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 "deal-breaker for scientific computing" seems extreme.
> I also find Julia's errors to be fairly obtuse. And I see a lot of them because dynamic typing means the tools can't catch most errors before run-time.
I 100% agree. Julia errors are my biggest gripe with the language at the moment.
> But the big dealbreaker with Julia is it only complies on the fly. That means you can't just hand a compiled executable to someone. You must give them instructions to install Julia and all your dependencies first. That's no good for anything you want to ship like a desktop app or a game. You also don't want Julia on your server recompiling with every web request.
There are packages like PackageCompiler that work pretty well. And I'm positive in the near future (3 years?) we'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't mind it taking more space on disk.
> Like all compiled languages, the development cycle involves a lot of recompiling as you go. For small programs it doesn'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.
This used to be one of my biggest gripes, but things have gotten a lot better with every version of Julia.
----
My first order approximation when picking a language is this:
1) if I think it'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'll think about using Julia first, and if the size of the binaries are an issue, I might pick Rust.
wrt to Nim, I'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'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't been updated. Yes, it is easy to write interfaces but that requires a lot of work. If it is a project where I'm writing code just by myself, Nim might be a good choice but if I'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.
> You don'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's brilliant. I think that sentiment applies to many of Nim's unexpected design choices.
I personally don'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'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.
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 "feature" they were so turned off, they wrote the language off as being too weird.
There'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'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's new and modern, but 0 people have even heard of Nim. I've gotten SO many quizzical looks over the years, it is not even funny.