7 ms·

Go seems like one of the worst languages you could choose for functional programming. Why paddle upstream when you could either write idiomatic Go or switch to

Go seems like one of the worst languages you could choose for functional programming. Why paddle upstream when you could either write idiomatic Go or switch to a language properly designed for FP?

eru 5y ago
Some people are stuck with Go for their current projects, perhaps?
- minkzilla 5y ago
  Mixing in generics to an already existing code base sounds like a bad idea.
pjmlp 5y ago
Anyone that has DevOps on their daily tasks is now bound to deal with Go code, due its relation to Docker, Kubernetes and cloud infrastructure, just like we need to deal with C on UNIX clones or JavaScript on the browser.
- okamiueru 5y ago
  What relation does golang have with docker for devops use? I'm also wondering the same about k8s, other than the go templating language used by helm charts. And if it's the development of docker itself which is written in go, I wouldn't consider that devops (same as I wouldn't say editing images in photoshop is C++ development). I'm curious, because I've used k8s and docker extensively for devops, and aside from templating, which is arguably not so much golang as, well, just a templating engine. And I've thankfully not have had to use golang for anything serious.
  - pjmlp 5y ago
    Plugins and other software that one might feel like customising. https://landscape.cncf.io/ https://landscape.cncf.io/ As always, using the platform language is the best road to avoid additional development costs dealing with interoperability and tier 2 compatibility issues. Although some stuff is now happening in Rust as well, https://deislabs.io/ https://deislabs.io/
    - okamiueru 5y ago
      I see. I think what confused me was the statement "Anyone that has DevOps on their daily tasks is now bound to deal with Go code", since I've not found it to be true. And, I've yet to find a single need to customize any plugin/tool. The bar to do something like that is also exceedingly high, as the added maintenance cost is immense, since you now have to build and maintain your changes towards a living project. So, I think we might just have different interpretation of what DevOps entails. In addition, even if writing infrastructure plugins were to considered necessary as part of DevOps (though I consider this a stretch), writing golang is again not a requirement. The CNFC isn't exclusively filled with golang plugins either. I'd argue most are something else C/C++/Java/web-langs though I haven't made the effort to check. I'd venture a guess at one in four being golang, at most. I agree however that language evangelism benefits no one, and especially agree on the sentiment of using the platform language to avoid additional development cost. That said, and this is probably a bit more subjective, this does not follow from/to the original statement I took issue with.

Go seems like one of the worst languages you could choose for functional programming. Why paddle upstream when you could either write idiomatic Go or switch to a language properly designed for FP?

eru 5y ago

Some people are stuck with Go for their current projects, perhaps?

minkzilla 5y ago
Mixing in generics to an already existing code base sounds like a bad idea.

pjmlp 5y ago

Anyone that has DevOps on their daily tasks is now bound to deal with Go code, due its relation to Docker, Kubernetes and cloud infrastructure, just like we need to deal with C on UNIX clones or JavaScript on the browser.

okamiueru 5y ago
What relation does golang have with docker for devops use? I'm also wondering the same about k8s, other than the go templating language used by helm charts. And if it's the development of docker itself which is written in go, I wouldn't consider that devops (same as I wouldn't say editing images in photoshop is C++ development). I'm curious, because I've used k8s and docker extensively for devops, and aside from templating, which is arguably not so much golang as, well, just a templating engine. And I've thankfully not have had to use golang for anything serious.
- pjmlp 5y ago
  Plugins and other software that one might feel like customising. https://landscape.cncf.io/ https://landscape.cncf.io/ As always, using the platform language is the best road to avoid additional development costs dealing with interoperability and tier 2 compatibility issues. Although some stuff is now happening in Rust as well, https://deislabs.io/ https://deislabs.io/
  - okamiueru 5y ago
    I see. I think what confused me was the statement "Anyone that has DevOps on their daily tasks is now bound to deal with Go code", since I've not found it to be true. And, I've yet to find a single need to customize any plugin/tool. The bar to do something like that is also exceedingly high, as the added maintenance cost is immense, since you now have to build and maintain your changes towards a living project. So, I think we might just have different interpretation of what DevOps entails. In addition, even if writing infrastructure plugins were to considered necessary as part of DevOps (though I consider this a stretch), writing golang is again not a requirement. The CNFC isn't exclusively filled with golang plugins either. I'd argue most are something else C/C++/Java/web-langs though I haven't made the effort to check. I'd venture a guess at one in four being golang, at most. I agree however that language evangelism benefits no one, and especially agree on the sentiment of using the platform language to avoid additional development cost. That said, and this is probably a bit more subjective, this does not follow from/to the original statement I took issue with.