3 ms·

Even esoteric languages have a relative complete ecosystem of frameworks. I use Haskell in my day job and I never had issues finding a library.

AstralStorm 4y ago
Haskell is not particularly esoteric, but heavily opinionated. Libraries cannot change that basic fact - there are just problems it will be extremely unsuited for. Java has some of the same problem by the way in reverse. (Package handling, forced garbage collection and unknown real time and memory usage characteristics.) The difference being that Java's core has much less important opinions about algorithms, while Haskell tries to make everything functional or it is awkward. So, while Haskell will be hard to use for problems best described in an imperative way (in addition to other issues say Java has), Java will only have serious problems where memory and runtime determinism are paramount. It so happens that a lot of the programming is done in imperative way. Including the libraries.
scarface74 4y ago
Say I’m developing an application that needs to interact with cloud services. The last time the third party Haskell SDK for AWS was updated was in 2014. I do see a third party GCP SDK. But if GCP and Azure works like AWS, as soon as a new API is released by a service team, all of the officially supported SDKs automatically get updated. I am sure there are other service providers that have SDKs and code samples for popular languages.
- rowanG077 4y ago
  I would assume it's just a REST service which has an openapi spec. Then you can just generate the client.
  - scarface74 4y ago
    How much more “productive” do you think they would be just by being able to import a module in any of the supported languages? https://aws.amazon.com/developer/tools/ https://aws.amazon.com/developer/tools/ I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? What are the chances that any new developer could ramp up faster or already knows Boto3 (the AWS SDK for Python)? If they have an issue, they can go to StackOverflow or raise a ticket with their TAM. Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better” AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
    - rowanG077 4y ago
      > How much more “productive” do you think they would be just by being able to import a module in any of the supported languages? The same language? Maybe a few % considering a client is a small part of what you need to create. A different language? Depends on the comparison. I would be tens to hundreds % more efficient in Haskell then in Go or Python. > I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws. > Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better” > AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc. Did you ever try openapi generated clients? They can handle retries and exponential backoffs as well. There is no design to be done here. It just exposes the API as designed.
      - scarface74 4y ago
        None of the cloud providers provide the internal specifications used to autogenerate the SDKs for the languages I listed. In the case of Boto3 (the Python AWS SDK), while there are one to one generated mappings from the spec, there are also higher level constructs for the most popular services like S3 and DynamoDB and also helper functions like Waiters for asynchronous operations where you need to poll for an operation to be complete and Pagers that handle get request where the requests are being polled. Sure you could do all of this yourself. But again, “does it make the beer taste better”? This isn’t meant to be a rah rah AWS is the bees knees. It’s just the cloud provider I know the best (and the one I work for), I’m sure knowing MS, the developer experience is just as good as AWS. I just don’t have experience with it. > Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws. What’s the old saying about it’s a poor craftsman that blames his tools? If you can’t be productive in any of the nine languages that are popular enough to be supported by the major cloud providers, does that say more about the tools or the craftsmen?
- jose_zap 4y ago
  The latest update to Amazonka (the Haskell library for AWS) was 3 hours ago. https://github.com/brendanhay/amazonka https://github.com/brendanhay/amazonka I use the package directly from GitHub in my project.

AstralStorm 4y ago

Haskell is not particularly esoteric, but heavily opinionated. Libraries cannot change that basic fact - there are just problems it will be extremely unsuited for. Java has some of the same problem by the way in reverse. (Package handling, forced garbage collection and unknown real time and memory usage characteristics.) The difference being that Java's core has much less important opinions about algorithms, while Haskell tries to make everything functional or it is awkward. So, while Haskell will be hard to use for problems best described in an imperative way (in addition to other issues say Java has), Java will only have serious problems where memory and runtime determinism are paramount. It so happens that a lot of the programming is done in imperative way. Including the libraries.

scarface74 4y ago

Say I’m developing an application that needs to interact with cloud services. The last time the third party Haskell SDK for AWS was updated was in 2014. I do see a third party GCP SDK. But if GCP and Azure works like AWS, as soon as a new API is released by a service team, all of the officially supported SDKs automatically get updated. I am sure there are other service providers that have SDKs and code samples for popular languages.

rowanG077 4y ago
I would assume it's just a REST service which has an openapi spec. Then you can just generate the client.
- scarface74 4y ago
  How much more “productive” do you think they would be just by being able to import a module in any of the supported languages? https://aws.amazon.com/developer/tools/ https://aws.amazon.com/developer/tools/ I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? What are the chances that any new developer could ramp up faster or already knows Boto3 (the AWS SDK for Python)? If they have an issue, they can go to StackOverflow or raise a ticket with their TAM. Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better” AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.
  - rowanG077 4y ago
    > How much more “productive” do you think they would be just by being able to import a module in any of the supported languages? The same language? Maybe a few % considering a client is a small part of what you need to create. A different language? Depends on the comparison. I would be tens to hundreds % more efficient in Haskell then in Go or Python. > I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws. > Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better” > AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc. Did you ever try openapi generated clients? They can handle retries and exponential backoffs as well. There is no design to be done here. It just exposes the API as designed.
    - scarface74 4y ago
      None of the cloud providers provide the internal specifications used to autogenerate the SDKs for the languages I listed. In the case of Boto3 (the Python AWS SDK), while there are one to one generated mappings from the spec, there are also higher level constructs for the most popular services like S3 and DynamoDB and also helper functions like Waiters for asynchronous operations where you need to poll for an operation to be complete and Pagers that handle get request where the requests are being polled. Sure you could do all of this yourself. But again, “does it make the beer taste better”? This isn’t meant to be a rah rah AWS is the bees knees. It’s just the cloud provider I know the best (and the one I work for), I’m sure knowing MS, the developer experience is just as good as AWS. I just don’t have experience with it. > Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws. What’s the old saying about it’s a poor craftsman that blames his tools? If you can’t be productive in any of the nine languages that are popular enough to be supported by the major cloud providers, does that say more about the tools or the craftsmen?
jose_zap 4y ago
The latest update to Amazonka (the Haskell library for AWS) was 3 hours ago. https://github.com/brendanhay/amazonka https://github.com/brendanhay/amazonka I use the package directly from GitHub in my project.