AWS Lambda Releases Go Support
github.com
github.com
Your post about Go on Lambda is certainly helpful, but feels like it's aimed towards at a difference audience than Jeff (Barr, not Bezos).
Given that you have to compile the binary before pushing it up, it seems weird to announce "golang support" and not "support for any binary that talks $insert_serialization_scheme" over stdin/stdout or a network socket or some such, unless they're doing fancier magic.
The code: https://github.com/aws/aws-lambda-go/blob/master/lambda/entr...
Is Go one of the top 3 languages with Java and JavaScript, or is Python or something else more significant.
TL;DR: Discusses how Google engineers replaced the download server written in C++ with one written in Go, and analyzes the reasons why. It's pretty cool.
I would agree that some problems solved by scripting could/should be replaced with something more precise. But golang wouldn't be a great fill in for true scripting needs.
if it's a "json" like data that is sent to you (i.e a structure made out of only primitive types and list/dict) it may be not that hard, but I think it will be a work with very few value outside of this very specific use case.
Have you head or Apex [0], from what I understand it just creates a node.js shim to call your binary, it's what I was planning to use.
Still really hoping we get direct Rust support at some point though.
Bonus Question: What kind of things are you using Lambda for now?
The CLI tools work, but they're frequently more of an annoyance then running a single process app. The logical layout and composition falls entirely on the team. Composing related functions seems to be more troublesome than it's worth.
Is Go on lambdas exciting because people use Go for cross cutting devops operations? Is there demand for writing serverless Go?
I see containers and the single process model as much easier to test, lay out and run. Honestly, I probably just do "get" serverless. What am I missing?
isn't that the point?
https://github.com/serverless/serverless
has allayed a lot of my gripes with lambda.
Initially it was a bit disconcerting that I could not ssh into a machine and inspect anything. However, our mindset changed after a while. Instead of thinking of Lambda as a server, view a Lambda application as equivalent to a Gunicorn process in a production server. No one is going to ssh into the process or set breakpoints.
In my mind, serverless functions are akin to database triggers: they do one thing and one thing only, in response to an event.
If one tries to make a serverless function do too much, it tends to get somewhat difficult to debug.
If one stays within complexity boundaries analogous to that of a database trigger, things may be more manageable.
Just as you would not abuse a database trigger to do wacky things, it may be a good idea to not overextend serverless functions.
Exposing Google's language in the main competitor cloud feels like a major slap in a face.
Only after Microsoft had a better Android emulator experience and C++ support for Android development on VS, did they care to actually improve their own tools.
This just looks like a pretty basic Git repo.
https://aws.amazon.com/blogs/compute/announcing-go-support-f...