Author here. I am a relative beginner to Julia, having only used it seriously for a few months. For those familiar with Common Lisp, I will try to answer any questions you may have in this thread, that weren't addressed in the article.
2. Can you elaborate more on "they are very awkward to work with and only offer a subset of the abilities of the Emacs plugin" for vim? What did you find lacking about either slimv or vlime that you absolutely couldn't stand such that you forced yourself to use emacs? I'm most familiar with slimv and am aware of some quirks (and one bad still-open issue related to errors in threads which is annoying to deal with when it bites) and some limitations, but I'm fortunate to be mostly unbothered by them or in one case so far submitting a patch to fix one annoyance. At least, I'm not bothered to the level of abandoning vim -- I'll probably try the VS Code plugin before trying emacs again, or shell out for a LW license. Specifically it's things I see emacs users do like clicking a printed object's memory address to open the thing in the inspector, or having a slightly less ghetto code stepper. I'd rather have other things I miss from my Java life that as far as I know aren't even in emacs for CL.
3. Did you seek out any downer takes when evaluating Julia? What did you think of any of them? Some specific examples include https://yuri.is/not-julia/ or http://danluu.com/julialang/ where Yuri's post is linked at the bottom as a sort of update. If you read anything like that, have you been concerned? Any good "excuse" articles you found that address any downer points?
Anyway, thanks for your work in Lisp Land, both in code and IRC messages.
2) The Vim plugins only support SLIME, not Sly, which offers many more features I simply can't live without, such as stickers. Additionally, indentation in Vim cannot be made dynamic. That is, for every macro you write, you are forced to edit a flat file that describes the proper indentation rules. I have a couple thousand lines of my Vim configuration dedicated to working in CL, and it still isn't good enough, compared to the experience in Emacs. And yes, there are countless bugs that don't exist in Emacs/Sly.
3) Yes, I read that post and some others. Bugs like the AbstractArray usage are programmer errors, nothing to do with the language. Julia is 1-indexed by default, but with libraries such as OffsetArrays.jl and CircularArrays.jl an AbstractArray can be indexed at 0. I shrugged most of this post off, because I don't see them as correctness bugs in the language proper. As for the TTFX (time to first plot/execution) as noted in the other article, that is a problem that is actively being worked on currently by Tim Holy, and it's not really an issue if you build your own image anyway, only when you are compiling the code each time you start up your fresh image.
I’m also curious to understand the reasoning, for either choice.
This is a hypothetical future choice, and in that case I would absolutely choose the former (and I hope we get there).
But the current choice is more like "composability that often isn't tested as generically as it should be, with no interfaces at the language level, even the abstract types used for the composition often not having clear specifications, all of it holding together only because of people fixing things organically as problems arise". Then the choice isn't as clear cut - choosing to go with the more limiting option where things are known to work together well with each other is a respectable, sane choice. If we're going to claim composability as a strength of the language, it shouldn't come with hidden traps, caveats like "composability but really only if the hidden assumptions on both sides happen to be satisfied".
Do you think interfaces might be a silver bullet? If so, what’s holding back the language from prioritizing this in the medium term? (For v2.0, say)
Or maybe the most useful improvements are anticipated to come from somewhere else?
* more formal specifications for Abstract types your package defines
--- including in the language itself; I understand there's recently efforts to define what an `AbstractString` is, exactly, and there needs to be a lot more of that
* tests that test the limits of this specification by defining new types that are very different from existing ones, but conform to the specification (rather than the current usual practice of just testing with already existing types only)
* More integration of things like OffsetArrays, DimensionalData, AxisArrays, etc. in test suites
* An explicit "Scope and Limitations" page in package docs (like Revise.jl's Limitations page [1]) that mention what has been tested and what hasn't/isn't meant to be supported
I'm sure there's many other low hanging fruits that the community could address by itself - it's pretty late here and these are what my brain could come up with right now. But I see this largely as a community best practices and culture problem, that language features can help with to some extent, but needs to be solved at the social level.