3 ms·
Go seems like a great fit for this application. Would love to see stats comparing cold start times etc. for go vs. java/python/js. One would guess that it wou
by dhbradshaw 9y ago
Go seems like a great fit for this application.
Would love to see stats comparing cold start times etc. for go vs. java/python/js. One would guess that it would be faster, but measurement trumps guessing.
- Cthulhu_ 9y agoI think it mostly depends on whether it's always executed from source, or whether it's compiled and stored in fast access storage. If the latter, binary size becomes the main limiting factor (for pretty much all of those applications). Java is generally kinda slow to start up, but that may be due to all the frameworks. Python / JS IIRC are interpreted as scripts, not compiled. Mind you the go compiler is also pretty damn fast, almost script language speed.
- mattherman 9y agoI created one yesterday when this announcement was made. I had to upload my compiled binary, not source.
- mathw 9y agoAbsolutely. I've done some work with Lambda, and the cold start times for Java and C# were horrendous. Node and Python were pretty fast. I would expect Go to be more the latter than the former, with the added advantage of running really fast as well (and not being JavaScript), so my advice to my former colleagues on implementation language for a Lambda-based solution would be different if that pans out...
- chronid 9y agoIn my case when I gave Java a bigger allocation of RAM I got far better result (and it usually got even faster than the equivalent Python/NodeJS code). At the time at least (I don't know right now, it's been a long while since I touched a lambda function) it seemed that the bigger RAM share == the more CPU you get, which was not written anywhere in the documetation. And JVM startup times with crappy CPUs are indeed horrible. :)