Hacker News new | past | comments | ask | show | jobs | submit login

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.




The latest update to Amazonka (the Haskell library for AWS) was 3 hours ago.

https://github.com/brendanhay/amazonka

I use the package directly from GitHub in my project.


I would assume it's just a REST service which has an openapi spec. Then you can just generate the client.


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/

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.


> 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.


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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: