|
|
|
|
|
|
by 102030485868
3961 days ago
|
|
|
Well, in terms of maintenance it's a little bit more work. Sure, it has the features and reliability. But does that really justify having to maintain a completely new environment? Maybe it does, maybe it doesn't; it depends. No you may not be embedding it in your app, but it's now a part of your stack. You'll need to keep an eye on updates, etc for a completely different environment. Plus there are other factors, like approved languages. Certain companies only allow using languages X and Y. Don't even think about language Z. I had to re-write an 80loc Python script to a much larger Perl one because I just didn't grok Perl all too well at the time. It didn't matter that Python was installed on the system. All that mattered was that Perl was approved and Python was not. |
|
|
I'd like to address the "completely new environment" issue though. That should only be considered if you're thinking of owning and modifying the component. There are many software packages that you're going to use as-is, and interact with only via an API or CLI. In those cases the depth of the API/CLI, the quality of its documentation and the strength of its community matter way more than implementation language. (For example - who cares if nginx is written in C although your entire stack is Python or Java?)
If you're thinking of continually making changes in a package however - that's a different matter.