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.
