4 ms·

I’ve always hated this style of argument in tech where someone says X can do what Y does as an argument against using Y (or for using X) because it always misse

I’ve always hated this style of argument in tech where someone says X can do what Y does as an argument against using Y (or for using X) because it always missed *why* people use Y in the first place. See for example you can write safe code in C therefore rust is pointless (yes but rust makes it much easier to write safe code) Or you can do machine learning in JavaScript so python is useless (you can but it’s a much smaller ecosystem) Etc etc. You can pick whatever tools you want for whatever reason but please give me a better reason than it *can* be done.

worksonmine 3y ago
> See for example you can write safe code in C therefore rust is pointless (yes but rust makes it much easier to write safe code) Isn't it usually the other way around? "This would be safer if written in rust". > Or you can do machine learning in JavaScript so python is useless Said no one ever. The author also elaborates why (according to him) X is preferable over Y (mainly simplicity), and even if he didn't there's value in comparing tools if one is on the fence of switching but afraid of loosing compatibility. Entire websites exist with that sole purpose.
- edude03 3y ago
  >> Or you can do machine learning in JavaScript so python is useless > Said no one ever. I want to reply to this point because I have some relevant & interesting experience here. I've done a fair amount of consulting for companies who have a scenario that goes like this: - founder starts business in their free time, in a language they know well, as a monolith. - founder gets a few customers and decides to scale the business - founder decides they need to use "AI" to solve some business problem - founder hires a person who is great at solving that particular problem. - that person wants to use python (of course they do) but the monolith is not in python so various tensions ensue. - the founder (or someone else on the engineer team) inevitably says "you can do ML in $LANGUAGE_WE_CHOSE, why use python? We didn't chose python because $REASONS_PYTHON_SUCKS. You'd be surprised how often the language they chose is javascript and how often the reason not to use python is that they can't share code between the client and server. So unfortunately that example wasn't pulled out of nowhere
sharts 3y ago
To be fair, it seems a great number of folks use K8s because they can and/or because Google. And if that criteria is good enough to justify its use then surely it's enough to justify the use of an alternative. Frankly, the majority of software houses running K8s really don't need to.
- pseudocomposer 3y ago
  I use K8s because if I don’t like what my deployment costs or how my cluster is supported, I can easily pick it up and take it to another provider or even host it myself (though I don’t really want to self-host).
  - chrisandchris 3y ago
    I can do the same with my Ansible and docker-compose scripts. Moving to another provider feels like the selling point of ORMs (moving to a different db engine), whereas most often it will never happen. It's fine that you use k8s and it looks like it's the perfect fit for your case, but tech often thinks "my solution" equals "everyones solution".
    - pseudocomposer 3y ago
      Very much agreed on us not all needing the same solution. I’d argue Ansible makes more sense for apps written in scripting languages (particularly Python, obviously), while Kubernetes makes more sense for deploying statically-typed/compiled images where devs shouldn’t really need to deal with the whole Python ecosystem in addition to their compilers, linkers, etc. But of course there’s plenty of room for crossover! To your point about this being like ORMs, though: I would argue building apps to deploy with Kubernetes or Ansible is less like using an ORM, and more like building them to compile for any OS rather than depending on Windows/Linux/macOS libraries. DB engines generally have much more similar costs than server hosting companies do (you could pay 2x as much to host an app on one vs the other depending on what you need), so it makes less sense to switch. (Also, back in the days when ORMs were created, Oracle was much more dominant than today so DB cost differentials were a bigger issue, but that’s not really today’s market. These days many engines just offer wire compatibility with Postgres/MySQL libraries anyway, so that aspect of ORMs is really not the selling point anymore, it’s the mapping of DB type systems to language type systems.)

worksonmine 3y ago

> See for example you can write safe code in C therefore rust is pointless (yes but rust makes it much easier to write safe code) Isn't it usually the other way around? "This would be safer if written in rust". > Or you can do machine learning in JavaScript so python is useless Said no one ever. The author also elaborates why (according to him) X is preferable over Y (mainly simplicity), and even if he didn't there's value in comparing tools if one is on the fence of switching but afraid of loosing compatibility. Entire websites exist with that sole purpose.

edude03 3y ago
>> Or you can do machine learning in JavaScript so python is useless > Said no one ever. I want to reply to this point because I have some relevant & interesting experience here. I've done a fair amount of consulting for companies who have a scenario that goes like this: - founder starts business in their free time, in a language they know well, as a monolith. - founder gets a few customers and decides to scale the business - founder decides they need to use "AI" to solve some business problem - founder hires a person who is great at solving that particular problem. - that person wants to use python (of course they do) but the monolith is not in python so various tensions ensue. - the founder (or someone else on the engineer team) inevitably says "you can do ML in $LANGUAGE_WE_CHOSE, why use python? We didn't chose python because $REASONS_PYTHON_SUCKS. You'd be surprised how often the language they chose is javascript and how often the reason not to use python is that they can't share code between the client and server. So unfortunately that example wasn't pulled out of nowhere

sharts 3y ago

To be fair, it seems a great number of folks use K8s because they can and/or because Google. And if that criteria is good enough to justify its use then surely it's enough to justify the use of an alternative. Frankly, the majority of software houses running K8s really don't need to.

pseudocomposer 3y ago
I use K8s because if I don’t like what my deployment costs or how my cluster is supported, I can easily pick it up and take it to another provider or even host it myself (though I don’t really want to self-host).
- chrisandchris 3y ago
  I can do the same with my Ansible and docker-compose scripts. Moving to another provider feels like the selling point of ORMs (moving to a different db engine), whereas most often it will never happen. It's fine that you use k8s and it looks like it's the perfect fit for your case, but tech often thinks "my solution" equals "everyones solution".
  - pseudocomposer 3y ago
    Very much agreed on us not all needing the same solution. I’d argue Ansible makes more sense for apps written in scripting languages (particularly Python, obviously), while Kubernetes makes more sense for deploying statically-typed/compiled images where devs shouldn’t really need to deal with the whole Python ecosystem in addition to their compilers, linkers, etc. But of course there’s plenty of room for crossover! To your point about this being like ORMs, though: I would argue building apps to deploy with Kubernetes or Ansible is less like using an ORM, and more like building them to compile for any OS rather than depending on Windows/Linux/macOS libraries. DB engines generally have much more similar costs than server hosting companies do (you could pay 2x as much to host an app on one vs the other depending on what you need), so it makes less sense to switch. (Also, back in the days when ORMs were created, Oracle was much more dominant than today so DB cost differentials were a bigger issue, but that’s not really today’s market. These days many engines just offer wire compatibility with Postgres/MySQL libraries anyway, so that aspect of ORMs is really not the selling point anymore, it’s the mapping of DB type systems to language type systems.)