4 ms·

> They weren't talking about rewriting every tool in your preferred language otherwise how far down the stack do you go (Terraform in Rust today, Linux in rust

by zeveb 7y ago

> They weren't talking about rewriting every tool in your preferred language otherwise how far down the stack do you go (Terraform in Rust today, Linux in rust tomorrow, etc)? Well, I'd say that one must start at the highest level and work one's way down. Clearly there're neither time nor resources to write an amd64 OS in Lisp when one is trying to get one's AirBnB-for-pools app out the door. But maybe one can give a little love to Hunchentoot. Maybe one can spend some time replacing Makefiles with ASDF. Maybe at some point one might even replace some uses of the shell itself. Maybe someday one might spend some time on SBCL. And sure, someday, if one's firm really lucks out and achieves Google scale then maybe one will have the resources to build a new compiler or even a new OS. So I guess I am somewhere between the two positions, at least if I wear the hat of the original article's author. I think it could make sense to write everything in one language, and I think maybe someday it might make sense to go a level deeper — and maybe someday further still a level yet deeper. Because it would be nice, someday, to get something better than Unix-like OSes! Also, I am a man, not a group: 'he,' not 'they' please grin

laumars 7y ago
As I posted elsewhere, unless you plan to raise PRs, fork or take any other maintenance ownership of a project -- be that an orchestration tool or an operating system -- then it shouldn't matter what language it was written in. At least with your Makefile example, you'd need to edit and maintain those Makefiles, so there is logic in rewriting them in $LANG_PREFERENCE. But if you're rewriting services you wouldn't otherwise need to maintain just for the sake of language purity then you have to ask yourself if what you're doing is a smart use of your time or if you're actually just "shaving a yak". > Also, I am a man, not a group: 'he,' not 'they' please grin It's often impossible to know the gender of someone, let alone their preferred pronoun, from their post alone. So you're going to run into a lot of people saying "they" when referring to you. edit: getting a lot of downvotes on this so it's clearly an unpopular opinion. I probably should point out I've ran several development teams over the years and it's very easy to go down the rabbit hole of NIH. There's a saying about "standing on the shoulders of giants" which I think applies here; and there's no shame in sacrificing language purity if it gives you increase productivity without any side effects (aside selling off a little of your soul). The key is being able to balance need from want. eg does that orchestration tool need to be written in $LANG_PREFERENCE or does this one on Go actually work pretty well? The ironic thing is as we get more accustomed to using cloud tools, we're becoming more reliant on stuff written which we have no visibility of. So in a way, the language purity war has already been lost.

by zeveb 7y ago

laumars 7y ago

As I posted elsewhere, unless you plan to raise PRs, fork or take any other maintenance ownership of a project -- be that an orchestration tool or an operating system -- then it shouldn't matter what language it was written in. At least with your Makefile example, you'd need to edit and maintain those Makefiles, so there is logic in rewriting them in $LANG_PREFERENCE. But if you're rewriting services you wouldn't otherwise need to maintain just for the sake of language purity then you have to ask yourself if what you're doing is a smart use of your time or if you're actually just "shaving a yak". > Also, I am a man, not a group: 'he,' not 'they' please grin It's often impossible to know the gender of someone, let alone their preferred pronoun, from their post alone. So you're going to run into a lot of people saying "they" when referring to you. edit: getting a lot of downvotes on this so it's clearly an unpopular opinion. I probably should point out I've ran several development teams over the years and it's very easy to go down the rabbit hole of NIH. There's a saying about "standing on the shoulders of giants" which I think applies here; and there's no shame in sacrificing language purity if it gives you increase productivity without any side effects (aside selling off a little of your soul). The key is being able to balance need from want. eg does that orchestration tool need to be written in $LANG_PREFERENCE or does this one on Go actually work pretty well? The ironic thing is as we get more accustomed to using cloud tools, we're becoming more reliant on stuff written which we have no visibility of. So in a way, the language purity war has already been lost.