No. I gave up on Golang long time ago, it is neither memory safe nor high level enough to be used for business code. On the top of that GC is a problem in high performance use cases. It literally does not give us anything that we need.
For your python problem, I suppose you are not using CI to package your lambda, why so?
Sorry but it is not my intention to waste time on a shortcoming of a language to make it barely work. Python is a deep rabbit hole that we do not have time to go down in. I am using Python on a daily basis for other projects and it is not even comparable how much more efficient it is to work in F#. Basically if the compiler happy we have a really high chance of successful operation, while with Python it is always testing in production even if we do all the checks possible on our end. Again, I use both languages on a daily basis and I do not want my next project happen in Python at all. If you do not understand why ML family languages are superior to C family languages than maybe you should look at why Rust, F# and Haskell exists and how do they rank in terms of security, performance, expressiveness and reliability comparing to other languages. I have spent enough time on languages where most of the time is spent on "how the hell am i supposed to do this in X" instead of "what business features should I implement / improve on today". With F# we (on purpose) write simple, junior friendly code and refrain from using things that are hard to explain to newcomers. We have confidence in our software that it does what it supposed to because of the basic fundamental principles backing everything in this language. (discriminated unions, currying, immutability, referential transparency, idempotency, options, railway oriented programming, null safety (you have to work on it when working with C# code) and so on) It is really painful to switch back to Python where function signatures mean nothing, you have no idea if a function returns a new object of mutates an object to pass in (often silently). Python feels like a hockey stick when i need a precision drill.
I actually agree on Python being a nightmare to debug, and testing at runtime only by design. Thanks for your detailed answer. I don't know much about F# so I guess I'll take a look.
I personally use TypeScript for most of my work now (but you want to get rid of numerous dependencies so it doesn't seem a good choice for you, still for lambdas it is a great fit as you can use webpack post compilation and get really small packages in the end with quick cold starts). It seems a middleground choice, but it can communicate with basically anything, runs everywhere, many people know nodejs as a basis and it is "good enough" for me.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
No. I gave up on Golang long time ago, it is neither memory safe nor high level enough to be used for business code. On the top of that GC is a problem in high performance use cases. It literally does not give us anything that we need.
Sorry but it is not my intention to waste time on a shortcoming of a language to make it barely work. Python is a deep rabbit hole that we do not have time to go down in. I am using Python on a daily basis for other projects and it is not even comparable how much more efficient it is to work in F#. Basically if the compiler happy we have a really high chance of successful operation, while with Python it is always testing in production even if we do all the checks possible on our end. Again, I use both languages on a daily basis and I do not want my next project happen in Python at all. If you do not understand why ML family languages are superior to C family languages than maybe you should look at why Rust, F# and Haskell exists and how do they rank in terms of security, performance, expressiveness and reliability comparing to other languages. I have spent enough time on languages where most of the time is spent on "how the hell am i supposed to do this in X" instead of "what business features should I implement / improve on today". With F# we (on purpose) write simple, junior friendly code and refrain from using things that are hard to explain to newcomers. We have confidence in our software that it does what it supposed to because of the basic fundamental principles backing everything in this language. (discriminated unions, currying, immutability, referential transparency, idempotency, options, railway oriented programming, null safety (you have to work on it when working with C# code) and so on) It is really painful to switch back to Python where function signatures mean nothing, you have no idea if a function returns a new object of mutates an object to pass in (often silently). Python feels like a hockey stick when i need a precision drill.
I actually agree on Python being a nightmare to debug, and testing at runtime only by design. Thanks for your detailed answer. I don't know much about F# so I guess I'll take a look.
I personally use TypeScript for most of my work now (but you want to get rid of numerous dependencies so it doesn't seem a good choice for you, still for lambdas it is a great fit as you can use webpack post compilation and get really small packages in the end with quick cold starts). It seems a middleground choice, but it can communicate with basically anything, runs everywhere, many people know nodejs as a basis and it is "good enough" for me.