We're not using column generation in the current algorithms (but Leanform is just launching with column generation on top of CBC - https://angel.co/leanframe ).
We're not using Dantzig-Wolfe decomposition, but our original scheduling algorithm used a dynamic programming approach that was quite similar.
We're currently amid rewriting the Chomp decomposition algorithm to be a more specialized branch and bound variant.
Yes do do have a column generation algorithm that leverage my expertise I gained working at ad-opt (airline pilot rostering).
We also migrated from julia to python. Another vote for the MIT teams that worked on the project! It really helped us at the beginning!
We are also playing with the google glop solver that gives pretty good results so far.
The main drawback of python for column generation (and as far as I understand, the same flaw exists in juliaopt/JuMP) is twofold. 1) most libraries are "math formulation oriented" which makes implementation hard to maintain/debug 2) biggest issue: the wrappers around the underlying solver (cbc, glpk, etc) keeps all references (to variables and coefficients) and do not offer a clean add/remove interface (only add/set bounds). Even playing with coefficients isn't always straigthforward.
So we had to build our own wrapper on top of the LP wrappers out there (Pulp, pyomo, cylp etc). When solving large scale problems with column generation, you generate hundreds of thousands of different variables even if only a fraction of them are "active" at a time leading to memory and runtime leaks in the usual wrappers. We had cases where the LP library was spending about 85% of the time just writing and reading files for CBC. The or-tools library wraps the C library itself via SWIG and is our best horse as of writing this.
For sure we will think of rolling our own binder too. Last year I was hoping to do it is scheme :) We might get "stuck" with python for the time being though.
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).
