8 ms·

> In my opinion the best tool for basically all jobs is usually the main programming language of your project / team / company. I read a wonderful article some

• StavrosK 7y ago
  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.
  • wtetzner 7y ago
    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.
    • StavrosK 7y ago
      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. Fair point in that case, though.
    • rho4 7y ago
      Indeed. But have a very strong preference for tools written in your main language.
      • laumars 7y ago
        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.
        • abathologist 7y ago
          Plans change :) If/when you find you do need to change something, having preferred suitable tools in your main language will make this easier.
          • laumars 7y ago
            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.
        • rho4 7y ago
          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.
          • laumars 7y ago
            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.
  • laumars 7y ago
    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).
    • 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.
• _jal 7y ago
  I get where that is going, and agree with the sentiment. But this assumes that companies, engineering teams and problem domains all perfectly overlap. I'm a systems guy in a Java shop. Ignoring obvious nonstarters like trying to shove Java into early Linux boot, this still implies I should be hiring Java programmers for systems engineers. Which, no, not only don't I care, doing that would select for a very small subset of available candidates. A nice thought experiment, but not practical.
  • rho4 7y ago
    I would try to use Java to manage / generate necessary Linux boot scripts. Use Java to manage Linux servers etc.
    • _jal 7y ago
      Feel free. We won't. There are multiple reasons, but the big one is there is almost no overlap between the engineering team's reason for existing (writing and maintaining line-of-business applications) and ours (keep systems up, compliant, performant and safe). But if it makes you happier, one tool we use is Puppet. That runs in JRuby in a JVM to execute their own weird DSL. So to use it in a nontrivial environment, you need to be able to tune Java and write both Ruby and Puppetese.