The official aws cli used to talk to the soap interface and used regex instead of actually doing correct error handling and that was used by so many tools. Even though it used to break horrible.

It's quite a niche you are talking about, not big enough to debug open source code but still big enough to require SLA for SDK and not being able to talk Amazon into creating it. It's generated code, it's not rocket science.

What I have experienced is that software licence, where you are sending data to, where you are hosting it and having access to audit the code has usually been a bigger concern.

But then again big organisations often have really specific concerns. So I'm not doubting your statement it's just that I have never heard it before.

https://hex.pm/packages/ex_aws https://hex.pm/packages/ex_aws_s3

I've usually not seen more than 3 or so official SDK for most services and there are a lot more programming languages than that. For example Microsoft's Graph API doesn't have an official Ruby client, they have one that sort of works.

We currently have a problem where we can't have thousands of cores because, even today, so much code is designed to be fast on one core.

We really have to move the asynchronous programming because synchronizing async hardware is both complex and inefficient.

RISC V is probably going to help since it allows for a lot of experimentation.

I just love that you can create robust ML services. Which for me, isn't as easy to do in Python, even though I've created async service with core Tornado before asyncio was a thing.

Sorry to be so snarky. It probably depends on people's time working on it and their familiarity with async processes. This is an inherent problem with any media like that. With sound, it's primarily that it can't come before the image but can lag behind the image. Stuff like this.

I don't think any programming language is going help with that because it's how we perceive things, not just how correct your code is.

There are also multiple other translation projects:

https://dockyard.com/blog/2021/08/10/what-if-coboltoelixir

https://www.microfocus.com/en-us/products/visual-cobol/overv...

[1] https://www.ibm.com/docs/en/zos-basic-skills?topic=zos-cobol... [2] https://gnucobol.sourceforge.io/

We started using it because we knew it could be embedded into any other framework, we are using two others in the company. But are starting to use it for SPA also. Glad to see it growing quickly.

Thinking about possibly reworking our SPA to use Phoenix LiveView most of the abstractions are there already.

Looks really cheap and if I understand the technology correctly would only have a small area that you can see correctly through.

Regarding the my browser isn't supported they are just trying to have it optimized and in the manner that they see as the way forward. You should still be able to send this as data with webrtc. If there was no way of implementing it without this api then it would be different.