The obvious counterpoint is that then you'd have to rewrite every single tool in every language people used.
I don't care about extending most of my tooling, I just want it to work. I'm not going to spend years rewriting Terraform in Rust just because I don't use Go in my company.
I don't think that follows. I think the idea was that you should write all of your in-house tools in your main programming language, not necessarily third-party tools.
Unless you're planning on submitting PRs for that tool, I don't see what different it makes what language the tool is written in. What should matter is if the tool solves more problems than it creates.
Language purity is great as an intellectual pursuit but it shouldn't distract you from picking the best tool for the job.
Most importantly: You can debug it and it probably provides an API in your main language. Bonuses: It integrates with your other tools. You can fork it if necessary. You talk the language of their support forums. And you don't know in advance whether you will need to submit patches.
Some interesting points there. Some I agree with and some I don't.
> You can debug it
That's your strongest counterargument and I agree it is easier if it's written in a language (or at least ecosystem) that you're already skilled in. But you have to be careful not to overstate the importance of this feature ie is it a tool that likely needs to be debugged using your preferred language tools (eg is it a simple tool, or stable and mature. Does it already have a suite of debugging tools available thus not requiring engineers to debug the executable itself? Are other tools like strace better suited for debugging instead of language-specific tools, etc).
There's very few tools I use daily that I've needed to debug. Even fewer that I've needed to resort to source code and language debugging tools.
> and it probably provides an API in your main language
That's a huge assumption to make. However if it does and it's an API you're likely to use then that is a differentiating feature which makes it the best choice tool and plus the tool is no longer something you're not using to develop in house.
So your point actually aligns with the point I was making.
> Bonuses: It integrates with your other tools
Again, that becomes a feature and thus you're not picking a tool for language purity reasons thus not violating the point I was making.
> You can fork it if necessary.
It's almost never necessary to fork a tool your using outside of your development framework (and if it is part of your development framework then it's something you are expecting to maintain so that point was covered in my previous post).
Or to put things another way, how many people here have forked Terraform to run their own distinct version of it?
If it's a tool you think you might like to fork or maintain then again, that's not violating my previous post since you picked that tool with the plan to maintain.
> You talk the language of their support forums
This is your weakest argument. :)
I've never typed a line of TypeScript in my life yet can talk in depth about it with the TS developers when issues arise. Why? Because I've programmed in well over a dozen other languages and the way we communicate different concepts doesn't generally change that radically from one language to another.
> And you don't know in advance whether you will need to submit patches.
You can make a reasoned guess though. A bug in the Linux kernel: I think I'll raise a bug report and leave that to others to fix. A bug in Terraform: then maybe I might submit a PR but odds are I wouldn't have the time to learn the code, devise a fix, write tests, etc. Again, I'd probably end up raising an issue on Github and working around the problem at work. Anything higher level than that then perhaps I'd raise a PR but choices often get more diverse and the impact of picking "the wrong tool" becomes less significant.
Of course, if only the foreign tool has the required functionality, it wins (no purity here).
API: Like patches, you might not need it now, or the API might not even exist yet.
Fork: Agreed, that was not a realistic scenario. Maybe a better argument would have been the ability to write plugins or extensions (even if you do not need them now).
Forum: Yeah not really important.
Patches: Agreed, who has time for patches. Like forking, probably not going to happen.
Additional (weak) argument: Better paradigm / metaphor match between tool and your system.
But yes, other factors are probably even more important, like will the tool still be actively maintained in 10 years? How big and active is the company / community behind the tool. How mature is it. How big is the existing user base. Cost, support options...
I agree. But also it doesn't make sense to pick a tool that doesn't quite fulfil your requirements, is buggy or has other problems over a battle tested tool that does solve all of your requirements bar the language it's compiled in.
I have no issue with people picking tools written in their preferred language if that is the differentiator between two competing solutions. However picking the wrong tool because it's written in the right language is a fools move. Which is the point I'm making. Language purity is great just so long as it doesn't lure you into using shit tools.
Ah hmm. For most in-house tools I usually start by taking something that already exists and configuring it to do what I need, there's little tooling I usually need to create from scratch.
I don't think that's a fair interpretation of the previous post. 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)?
Their point is software you actually develop in house. So that might be HCL code used by Terraform (in which case you might still need to use another tool or SDK in place of Terraform) but it wouldn't be Terraform itself (ie the Go code used to compile the Terraform executable).
> 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
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.
I don't care about extending most of my tooling, I just want it to work. I'm not going to spend years rewriting Terraform in Rust just because I don't use Go in my company.