I still use a few RHEL5 machines but nobody would ever dream of pushing new software to them.
To my mind, it's usually a good idea not to use system Python, both packages and the interpreter, if you're not also controlling them. This makes building your deployables more involved, but makes the actual deployment more painless.
Telling customers that they are doing things wrong isn't really a great way to win customers.
Why everyone is relying on python that's installed there for RedHat's needs (e.g. yum).
Unlike other languages, Python is probably the best one that can have multiple versions coexist together.
RHEL 5 is really common.
Environments where the build of your server is strictly controlled and conservative...banks, mission critical apps, that kinda thing where stability from upstream is hugely important.
How did the switch to Lua not break this in the same way?
Sorry for the naive question, I'm just not following how it can be possible to change languages, but impossible to change versions. At first glance, the latter seems like a special case of the former.
(EDIT: LUA->Lua)
2) Deployments with the new agent were noticeably faster, (like 1 second deployments that used to take 20+ seconds). However, this speed up was largely due to the Python codes design which had a "continuation" loop which was polling based, but the Lua code used coroutines and simply continued the threads when the steps were complete.
Overall, I think the choice to use Lua (or more specifically luvi) was a great decision. Note that it did take a few iterations in order to come up with the optimal way of using Lua + libuv. Originally I was taking the Node.JS approach of using callbacks, but that approach has two problems:
[a] It is difficult to properly implement "back pressure" so that all queues between producer and consumer are bounded.
[b] It is difficult to handle errors properly.
Lua coroutines allowed me to write a simple "green thread" library that encapsulated these challenges.
That was your problem, you just made a huge mistake and depending on how big your python code base was, you have now alienated most of your developers by moving to a language they are not already comfortable with.
Do your customers already have lua installed on their servers or are you bundling it now? You could have just a easily bundled a newer python interpreter. Lua is a nice scripting language, if you want to embed it into another app or to create a plugin system. It's not a nice general purpose scripting language, mostly because of the vast pypi repo.
The same thing could have been achieved within Python, but from an end user perspective I'm guessing this is an improvement for most of their customers.
The cost of effort their developers will have to put in to be as effective as a LUA developer as they were as a python developer is really not worth this move. There are more to moving to a different platform/language than just the end users.
Being as the size of the team is so dependent on a small number of high performers, I don't think it's unusual that they picked a language one of the main people in the company is extremely fluent in.
I've worked with Brian before and he is a beast. I don't know if 10x engineers exist, but if they do I would certainly consider him one.
I don't think what you say is completely true. People who are more experienced tend to be able to produce features much more quickly than those who are junior, just because they've already run into issues before so can anticipate them or solve them more quickly. If anything I would argue people like that actually write code more quickly that is more maintainable.
I don't know if he can ship 10x as many features; I didn't think term 10x engineer was used literally. I just know I've worked with quite a number of people and he is one of the best developers I know.
But then, we'd need to know how good your assessment skill/method is. Maybe you misjudge all the developers you work with? What feedback do you get?
@Chris2048 - Distelli is hiring. If you want to make your own assessment of my skill, then join us :).
Are you in a position to speak for Distelli developers?
"The cost of effort their developers will have to put in to be as effective as a LUA developer as they were as a python developer is really not worth this move."
I suppose this could be true in a poisonous environment where scheduling does not accommodate the need to learn a new skillset.
Unless you are familiar with the employer this is an incredibly hostile presumption. I.E. I would not work for such an employer nor would I want to be their customer
There will still be a minimum effort (e.g. in hours) that cannot be reduced by the nature of the employer. A dev will still have to put in the hours to learn a new language.
It seems the cost being described here is cost to the employer, not to the developer.
I also need to mention that Lua is the easiest language I've ever encountered, so any competent developer can learn it quickly, it's not alienating anyone.
Given that, I agree that LuaRocks isn't so vast as other languages' repositories and this can be a drawback of using Lua. But why again are you judging a language by it's package manager? If it's a good language wouldn't it be better to suggest more people to write packages instead of suggesting people not to use it?