I have to imagine there is a business reason for the slow adoption of languages/runtimes in Lambda. They're still only supporting Node v6.10 as well, which is far outdated. They should at least be keeping up with LTS for security sake.

Before releasing Go support, it felt like they're simply creating arbitrary friction to keep people on their platform. By expecting your code to export a handler, rather than listen on a port, that has a specific signature, you end up coupling yourself more to the AWS platform. But it also causes a ton of friction for adoption, since testing is more difficult than it should be.

Now with the release of Go, it feels even more that they're putting up these arbitrary gates without a rhyme or reason. How come Go can listen on a port, but other runtimes need to export a handler function? Why did they choose to rely on a Go-specific protocol instead of a common one?

It's frustrating, because I really want to use it (from an ops perspective), but I think my team is going to ditch the proof of concepts we've done because of the friction we've experienced. I'm sure there are valid engineering reasons for these choices, I just don't see them.

If your career consists of Ruby->Node.js->Go then static binaries are radical new technology.

> If your career consists of Ruby->Node.js->Go then static binaries are radical new technology.

Rather than offer what amounts to nothing more than an ad hominem, perhaps you’d care to explain why whatever you’re using is superior.

Your preference may be containers or bytecode bundles, but you’d be hard pressed to justify a major advantage and add a lot of complexity overhead for the privilege of using them.

> Rather than offer what amounts to nothing more than an ad hominem

Is this ad hominem? Why?

We can both agree to this and agree that Go's compile speed makes very large code bases possible (and that its cross-compile story is very compelling when your entire world revolves around writing on OSX machines and running in a linux docker container.

Lots of languages can deliver big static binaries. Hell, once upon a time this was considered a disadvantage and languages like Common Lisp and Smalltalk were totally raked over the coals for having an image & executable model!

> but you’d be hard pressed to justify a major advantage and add a lot of complexity overhead for the privilege of using them.

Why then is Go given this?

Because I could name 3 languages equally deserving right off the bat and one of them would be way less work: Kotlin, Swift and Haskell.

I disagree. Go's binaries are a 'radical new concept' in making them both the default and easy to use. Sure you can do it in C, sometimes, with the right libraries. But many won't even work statically.

You can do it in any programming language that has compilers to native code, it was the default linking model in OSes until the mid-90's and still is on the embedded space.

The special case of glibc, is the exception of majority of C compilers.

I'm well aware. But keep in mind probably the majority of us were not writing software in the early 90s(no offense intended). We grew up in a world with Java, Python, and Perl...none of which weren't even capable of doing so. Sure C and C++ were around too, but of course not as 'hot', neither encouraged static linking, and as mentioned, sometimes weren't even capable of doing so depending on library.

The static libraries are only popular right now because people who don't need static cross-compiled binaries are convinced they need a computer that is exactly like the computer people who make websites need.

It's a very odd state of affairs. In an age of docker, nix uberjars, ever more sophisticated user and system space filesystems it's really questionable what value they bring.

People say, "Simplicity" then they bling out their docker containers with multiple layers of processes and initialization anyways.

Go's tooling would have been great in a pre-Docker era. Now... I don't see the appeal.

Well, keep in mind that Go also predates Docker by a bit. Docker really did solve the whole dependency issue of dynamic languages/runtimes, but Go still has a possible advantage here - it can be built in a much smaller container..even SCRATCH. A minor convenience at best, but something.

Exactly. Given that they are clearly already doing this with Go (as it is literally native code that can do anything in that process), they should just release an official SDK for language vendors to integrate that handles the core binding of requests into the process, and then suddenly everything can support Lambda. (I hope and expect someone just does this using Go as a shim, but that is of course weirdly unofficial.)

Which is exactly what others have done before with Node when official Go support wasn't available: Use Node as a shim to launch a Go process in Lambda.

I haven't seen a language that didn't have a cycle of "everyone should use it for X" articles. Golang is just having its moment.

Let alone being amazed by compilation speeds that Turbo Pascal was already doing in MS-DOS, with a more feature rich language.

I think the go team does deserve credit for making compilation speed a priority when other languages of the same generation have tended not to.

Sure, but lets not pretend that is something they came up with, unique to Go toolchain.

Lots of languages have fantastic compile speed, they've just decided to have their compilers do a lot more work.

You can argue that fast compilation IS a feature and that new language options should be evaluated, but it's unfair to say it's "not a priority" even for languages like Scala.

> they've just decided to have their compilers do a lot more work

This. Compiling C++ would be a lot faster if you made the developer manually expand all the templates into tedious boilerplate before starting the compiler, but it's not a good tradeoff to make.

Why are we forgetting the amount of money spent developing fast JITs for Javascript here?

... with a richer type system, no less!!