13 ms·
Go Is a Great Fit for Lambda
- tuananh 9y agoit seems the same things can be said about .net core as well.
- jrs95 9y agoWouldn’t that suffer from most of the issues Java currently does in a serverless environment? Or do you mean .NET Core with native compilation? I thought that wasn’t really used outside of UWP stuff.
- sudhirj 9y agoNative compilation would count as a binary, and Lambda doesn't support arbitrary binaries yet. There are arguments on this thread that they should have supported arbitrary binaries by using a generic RPC format, instead of th Go specific RPC format.
- pjmlp 9y agoAll Xamarin apps are natively compiled on iDevices, and Unity uses their own AOT compiler, IL2CPP. There is ongoing work on CoreRT, the UNIX version of .NET Native.
- Thaxll 9y agoHmm .net core is not stable since a long time, and there is a lot of work to be done tbh.
- pjmlp 9y ago.NET Framework has been pretty stable. You can easily compile or run, any .NET 1.1 on .NET 4.7.1, that is 16 years of stability.
- tedunangst 9y ago.NET 1.1? But muh generics!
- pjmlp 9y agoJust pretend it is Go.
- Thaxll 9y ago.net core not net framework.
- ealexhudson 9y ago6 years is "unheard of" for language stability?? I struggle to think of a language where that hasn't been true..
- TheDong 9y agoI wonder what they'd think of ANSI C
- tonyarkles 9y ago> I struggle to think of a language where that hasn't been true.. If you're ok extending that to "language + stdlib": Node.
- brandur 9y agoThere's a pretty similar discussion happening downthread: https://news.ycombinator.com/item?id=16169803 https://news.ycombinator.com/item?id=16169803 The short version is that I don't think it's fair to compare Go's stability to that of a "barebones" language with an infinitesimal stdlib (e.g., C), because that's where most of the change is likely to happen. Go's already proven to be far more stable than most "batteries included" languages: think Python 2 vs. 3, Ruby's fairly considerable churn over the years, PHP 4 to 5, etc. Obviously my designation on Go here is subjective, but it seems to me that it compares favorable to any other platform that comes to mind.
- klodolph 9y agoI would say that Java is the only similar platform in terms of API stability. Even Java had some breaking changes, but they were relatively minor and relatively early (e.g. assert). Before .NET core, C# was a bit of a mess, I remember switching an app to PCL and it broke damn near everything. That was only four years ago.
- fnl 9y agoPython 3 is older than Go, and PHP 5 is even older than either, at least as for Go version 1. C++ is fully backwards compatible, as is Java. I don't see this point. And, we'd first need to see if a hypothetical Go 2 will be backwards compatible, anyways.
- pcwalton 9y agoSix years for language stability is nothing compared to, for example, C89.
- skybrian 9y agoBut for a fair comparison you'd need to include a lot of C libraries to match Go's standard library. How much have those libraries changed over the years?
- brandur 9y ago(I wrote TFA.) > But for a fair comparison you'd need to include a lot of C libraries to match Go's standard library. How much have those libraries changed over the years? Yes, exactly. Something like C isn't a fair comparison because there's so little included in the core language. Think about everything that you get with Go's standard library: concurrency, HTTP (even HTTP2), TLS, JSON, XML, Zip encoding, Regexp, etc., and then consider C's APIs along with all the APIs of all the libraries you'd need in C to accomplish those tasks — all of that together would be a more fair comparison. That might seem like apples and oranges, but for most real-world programs, people generally need a considerable subset of that functionality. C's stability is nothing to scoff at, but it's nowhere near as impressive of an achievement.
- slaymaker1907 9y agoA fairer comparison might be python3. Even if you assume python has only been stable since python3, it is still older than Golang since Go came out in 2009 and python 3.0 was released in 2008.
- TheDong 9y agoThe "Go is one of the most actively developed projects in the world" line is also complete bullshit; almost every other popular project (from rust to openstack to k8s to docker to chromium to linux .. etc) has an order of magnitude more development effort happening by most metrics, including commit rate. This reads like someone who hasn't looked outside the walled garden of Go very often.
- Xeoncross 9y agoCan someone provide good examples of why you would use a Lambda to respond to traffic instead of regular VPS? Is it just to save transfer costs inside the AWS network? Go can serve hundreds of thousands of connections a second on a $20/m DigialOcean/Linode/Scaleway/Volr server.
- benmanns 9y agoI like that Lambda can scale down to 0 and up to infinity without changing your architecture. However, a $20 droplet is probably a better value as I've spent many hours banging my head against AWS Lambda docs, Serverless framework incantations, alternative state storage, etc.
- bpicolo 9y agoYou can do similar with e.g. elastic beanstalk. You still need a metric for autoscalers, but overall the scaling works well. Probably worse for high-burst sorts of traffic though.
- lev99 9y agoElastic Beanstalk requires more devops type stuff then lambda.
- tnolet 9y agoThe Serverless framework is one of the most baffling and over engineered things I’ve seen in a long time. Instead of making thing easy it just a jungle of options and weird configs. No idea why it is so popular.
- quotheth 9y agoYour post lacks substance so it's hard to respond to (you criticize it as 'over engineered', not rally something I know how to respond to). One obvious concrete benefit of serverless is not managing infrastructure.
- 9y ago
- dominotw 9y agoCan somone tell me how are we supposed to deal with things like "postgres connection pools" in a serverless world. Do we need to open a new connection to the DB on every call?
- cnowacek 9y agoSounds like this person explains what you're asking for: http://blog.rowanudell.com/database-connections-in-lambda/ http://blog.rowanudell.com/database-connections-in-lambda/
- phamilton 9y agoLambdas are persistent so long as there is activity (ie it's "warm"). You can maintain a connection in a lambda and reuse it for subsequent calls. This isn't exactly the same as a connection pool, as you won't have multiplexing of any sort, but in practice you'll end up with 1 connection per concurrent request, which isn't too terrible, and if you keep the lambda warm there won't be any additional latency from having to connect.
- Xeoncross 9y agoI found this reply from Amazon helpful. TL;DR don't use a connection pool in Lambda > Now I see that you mentioned in one of the github posts: "The Lambda does seem to use the pool, but if I make maybe 3 / 4 quick requests to the lambda, new connections are opened up despite there being all of those connections already." > 3/4 quick requests would mean concurrent invocations, and concurrent invocations will execute in new containers. Containers are not aware of each other and cannot share state information so if an execution occurs in new container, it will open a new connection if there are none in this new container, despite there being existing connections from different containers. This can also cause your RDS instance to have too many open connections, because another container may have all the connections saturated, and if a new container is required to handle the load it may not be able to create the new RDS connection it needs to do it's work. - https://github.com/sequelize/sequelize/issues/4938#issuecomment-245211042 https://github.com/sequelize/sequelize/issues/4938#issuecomm...
- 9y ago
- seniorsassycat 9y agoI don't understand why AWS released Go support instead of binary support and I don't understand why they chose to rely on go's net/rpc. The Go 1.x runtime will happily execute any binary, go, rust, c++. Events are sent over a TCP stream. That stream uses Go's net/rpc which encodes objects using Go's special [gobs] binary format. If they had chosen a more common exchange format it would be much easier to support new runtimes. I haven't found any implementation of gobs outside of go. If you write one for a language you could use that language to write a native Lambdas. [gobs]: https://golang.org/pkg/encoding/gob/ https://golang.org/pkg/encoding/gob/
- sreque 9y agopart of the "magic" of Lambda is making it easy to use from your programming language of choice. If they made a lower-level model, like, for example, "we start up your binary, and it needs to bind to port X, then we'll send HTTP requests to it and it should respond appropriately using the following JSON specification," it would take a lot more work to set up your Lambda function and get it working correctly than it does now. It's certainly possible for them to do it, but I don't think it fits in with their style. Worst case, you can implement this interface yourself now easier than ever. Since golang is statically linked and has super fast startup times, you can build an interface where Lambda launches your golang process, and that process binds to a port and spawns a sub-process that implements the actual Lambda function. The golang process would implement the "socket" based interface for you. People have been doing the above already, but all the existing runtimes, including Node.js, Java, Python, and .NET, have non-trivial startup times and memory usage compared to a golang binary, which should be able to start up in 10s of milliseconds and use less than 1 MB of memory while acting as a proxy.
- aaronblohowiak 9y ago...or they could support FastCGI or CGI which would then have the "low barrier to entry" and "broad support" already handled..
- xienze 9y ago
- acangiano 9y agoThis is the stack Apex uses: https://apex.sh/#products https://apex.sh/#products
- skybrian 9y agoYou might want to compare how Go works on App Engine. You deploy your Go app to App Engine by uploading its source code, and the minor version is specified in app.yaml. It has taken some time for Google to support new versions of Go on App Engine, though they're promising to get better at it.
- spyspy 9y agoDespite their claimed improvements I believe they're still only supporting every other Go version. Fingers crossed for go1.10
- sidlls 9y ago6 years stability is all but unheard of? Maybe in the webdev world. Even there, really?
- deleted 9y ago[deleted]
- zebrainga 9y agoSmall business financing https://www.cityfinances.lv/jaunumi/ https://www.cityfinances.lv/jaunumi/
- fnl 9y agoJava and C++ are virtually fully backwards compatible. Java 1.6, 10 years old, is still commercially supported. C++ compiler support depends, but can go back far, too. Golang only seems to support the latest two [minor] versions, however (so, 2 years, maybe). I don't see how Go's long-term support is in any way outstanding. And, we still need to see what happens when Go moves to version 2...
- cratermoon 9y agoSee The Go 1 Compatibility Promise[1]. Something programmed in Go 1.5 still works in Go 1.10 1. https://golang.org/doc/go1compat https://golang.org/doc/go1compat
- fnl 9y agoWhat part of my statement makes you think I said anything to the contrary of that?
- cratermoon 9y ago> Golang only seems to support the latest two [minor] versions, however (so, 2 years, maybe). Go 1.0 was released 28 Mar 28 2012. Go is on a six-month release cycle[1]. Focusing on the number of minor versions is not only the wrong thing to do (because different languages release updates at different rates) but it's also factually incorrect, because by schedule, 2 minor releases happen in a year. 1 https://github.com/golang/go/wiki/Go-Release-Cycle https://github.com/golang/go/wiki/Go-Release-Cycle
- w8rbt 9y agoThe other nice thing about C++ is that you can specify which standard you want to use -std=c++11, etc. when compiling. I hope AWS Lambda supports C++ someday too. Anyway, I like Go too and agree it's very stable and while it's not as formal as C++ (ISO standards) it's been very stable. Give it 10 years to know for certain.
- barsonme 9y agoGo's lack of commercial support for previous versions is a non-issue. There's generally little reason why you can't just bump to the next minor version number. Go's 1.x promise means any code written for 1.1 will work on 1.9 and so on.
- KirinDave 9y agoI'm tired of Golang proponents suggesting that benefits every compiled, native language gets are unique to go in comparison to non-compiled or VM-targeted languages. I wish lambda would do more to support more executable contexts instead of blessing individual languages.
- saurik 9y agoExactly. 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.)
- moonlighter 9y agoWhich 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.
- rainbowmverse 9y agoI 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.
- pjmlp 9y agoLet alone being amazed by compilation speeds that Turbo Pascal was already doing in MS-DOS, with a more feature rich language.
- _ek94 9y agoI think the go team does deserve credit for making compilation speed a priority when other languages of the same generation have tended not to.
- 9y ago
- nzoschke 9y agoI'm also finding Lambda is a very nice runtime for using the Golang toolchain. There's a packaging challenge, but Go is also easier to install than most languages (unzip the linux build and set GOROOT correctly). Then running `go lint && go vet && go build && go test` inside Lambda is fast and cheap compared to other options. No more time spent in a queue, downloading Docker images, initializing containers, etc. I made a GitHub app if anyone wants to quickly try out building their Golang project on every build in a Lambda function. https://www.mixable.net/docs/bios/ https://www.mixable.net/docs/bios/