This is partially fixed in Julia 0.5 (or available now as BaseTestNext.jl in Julia 0.4). Its basically a backwards-compatible rewrite of the former Base.Test that adds the notion of test sets - enabling counting tests by default, but also not immediately failing out on the first bad test and even logging.
StaffJoy (https://www.staffjoy.com/) are using Julia for staff schedule optimization, and a large multinational is using it for train schedule optimization. Its also in use (at least on a trial basis) in the financial sector.
It'd still be a fairly large risk to develop something built-to-last on Julia at this point, so not really the best time for most companies to jump in unless something about Julia really solves a problem they are having.
There are definitely some scope issues with the distributed computing functionality, see e.g. https://github.com/JuliaLang/julia/issues/13649 for a general tracking issue (also, that is the 0.3 version of the manual).
Source? One of the best arguments, that is personally relevant to the work I do, is that indexing in math often starts at 1 (e.g. the indexing of rows and columns of a matrix). Translating this to code results in a mental overhead of mapping the math-index to the code-index, a cost I don't pay in Julia.
The problem is that you may have to stray outside that vectorized bubble, and at that point you enter into a two-language situation if you are using R (e.g. RCpp) or Python (Cython?) - which was one of the motivations for the whole Julia language, to avoid needing to do that.
Varies wildly depending on field even within an institution, and is still only for 9 months of the year (pay for the summer either with grants, consulting, or by teaching summer school classes [if there are any]).
As someone who almost exclusively uses Julia for their day-to-day work (and side projects), I think most of the author's thoughts about Julia are correct. I think the language is great, and using it makes my life better. There are some packages that are actually better than any of their equivalents in other languages, in my opinion.
On the other hand, I've also got a higher tolerance for things not being perfect, I can figure things out for myself (and luckily have the time do so), and I'm willing to code it up if it doesn't already exist (to a point). Naturally, that is not true for most people, and thats fine.
The author isn't willing to take the risk that Julia won't "survive", which is fair. Its definitely not complete yet, but its getting there. I am confident that it will survive (and thrive) though, and continue growing the not-insubstantial community. I have a feeling the author will find their way to Julia-land eventually, in a couple of years or so.
I also interned there, and my team was working 50ish hour weeks on a relatively flexible schedule (e.g. come in 7am-11am, leave 3pm-7pm). Search-related team. I know some teams might be working far more, but that wasn't common as far as I could tell.
I was really impressed that the author included this caveat:
> A word on procedure: In this section, we've smoothly moved from single hidden-layer shallow networks to many-layer convolutional networks. It's all seemed so easy! We make a change and, for the most part, we get an improvement. If you start experimenting, I can guarantee things won't always be so smooth. The reason is that I've presented a cleaned-up narrative, omitting many experiments - including many failed experiments. This cleaned-up narrative will hopefully help you get clear on the basic ideas. But it also runs the risk of conveying an incomplete impression. Getting a good, working network can involve a lot of trial and error, and occasional frustration. In practice, you should expect to engage in quite a bit of experimentation.
There is a lot of "magical thinking" amongst people not actively doing research in the area (and maybe a bit within that community too), and I think it at least partly stems from mainly seeing very successful nets, and never seeing the many failed ideas before those network structures and hyperparameters were hit upon - a sampling bias type thing, where you only read about the things that work.
Oh for sure, precomputation is essential. Hell, on a 100-1000 node sparse graph you can store all pairs shortest path info in a really small amount of data (like, PC game feasible for sure). For a game situation I'd be willing to burn a lot of time to crunch down pathing times, but memory pressure is real - so there is a "pareto"/nondominated set of algorithms that explore the tradeoff between memory consumption and run time, and the question is not whether you are 100x faster than another algorithm, but whether you are improving that "efficient frontier" of algorithms by using the same memory as another algorithm but running faster, or running as fast as another but using less memory.
Thats an explicit constraint, not an implicit constraint: The first person has an explicit constraint of "Lets consider only proposals that use existing technology". Thats exactly my point! Except in this case the implicit constraint was "must fit in memory for gaming applications", and I'm saying it should be made explicit. Its not that constraints are bad, just that they need to be shared along with the idea for it to be actionable.
Implicit constraints are the enemy of doing things better, as they allow people to claim basically whatever they want with hidden caveats, which makes it harder for the non-expert to figure out what they need to actually get things done.
Implicit constraints kind of suck for the purposes of creating and sharing knowledge though, don't you think? Even constrained to the domain, there are a wide variety of devices people play games on, so I still think its misleading to say this is 1000x faster than an alternative without the huge caveat that benchmarking is multidimensional.