[cultofmetatron]

maybe its just me but serverless seems ill suited for these heavy garbage collected languages. Since you're just spinning up a process shutting it down once it does its job, you're really wasting a lot of cpu cycles on building up the garbage collector. A lot of the overhead is fine when you're using a persistent instance where you can "warm the cache" so to speak. nodejs would be the edge of what I consider good for serverless. go is probably ok if you turned off the GC and rust would be ideal.

Then again, I've managed to completely avoid serverless as I find it to be a pita when you want to do anything more complex than a trivial crud app.

[6figurelenins]

> you're really wasting a lot of cpu cycles on building up the garbage collector.

Are you sure you aren't thinking of JIT compiling? The context where I think of "warmup" is (say) Java, where the runtime profiles hot paths to emit optimized machine code.

What would it even mean to "build up" a GC?

[meekins]

Serverless runtimes don't shut down the instance immediately after the invocation is complete but keep it up for an undetermined time depending on many factors (usually ~15 minutes) in order to process a possible new event without the start-up overhead (cold start). This means that in a system with constant traffic some instances may have a surprisingly long uptime. The instance gets destroyed when it throws an error though so a function with a disabled GC would clean the state when it runs out of memory. Slower processing done by memory-starved instances would probably eliminate any minimal performance gain you could get by disabling the GC though. (EDIT: I just realized that with no GC desperately spinning in place the starvation would not have much performance impact so this would actually be a very interesting approach if you can tolerate some invocations erroring out on out of memory errors, sorry!)

In regards to performance optimization of Lambdas, start-up time is the most important factor as cold starts happen also in cases of concurrent requests when no warm instances are available. This means that Go, Node and Python are pretty sweet for serverless. Thanks to recently released Lambda SnapStart feature that launches new instances from snapshots taken after application initialization Java (even with DI frameworks) is a plausible option if you're inclined that way. Previously you had to use a custom runtime and AOT compilation (that rules out any runtime DI stuff) to achieve tolerable performance with Java on Lambda.

[capableweb]

Couldn't you just disable the garbage collector in those languages? I know you can select a "none" GC in the JVM, you should be able to do the same with other runtimes too.

[emptysea]

Yeah Instagram has some blog posts outlining how they run their python web servers with the GC disabled

Easy enough to restart the processes every once in a while