[Fellshard]

I just picked up Java (via Kotlin) for the first time in four years, during which I've been doing Rails dev. I needed an AWS Lambda for zipping files into and out of S3. I banged my head against broken/unsuitable Node packages for doing so before finally giving up, since it is the lingua franca of Lambda.

I was able to rewrite and deploy the function in Kotlin in two days' time. It was easy to set up and run, and worked literally first compile and run - a benefit of static types.

Now, would I recommend it to anyone who is unfamiliar with the JVM ecosystem? That's a harder sell. But the stability of the ecosystem and a modern set of saner tools and libraries have made it much better to work in; I'd even call it pleasant.

[gabereiser]

AWS Lambda is the once place where you should never use Java. You have specific thresholds for how fast your function responds, jvm prevents that and requires more memory.

AWS Lambda’s documentation shows how to accept a Request and send a response. You don’t need a package for that. For making zips from s3, again, AWS’s sdk. It’s one of the most commonly asked questions on SO. Here’s one implementation for you that could have saved you days:

https://stackoverflow.com/questions/38633577/create-a-zip-fi...

[Fellshard]

Trust me, I looked up dozens of references. All would mysteriously halt after several files - known issues with how the Archiver library works, and none with any kind of fix, basically a data race within the library itself. Node's streams and promises are far too complex for far too little added benefit, and leads to broken concurrency in a multitude of libraries, and I'd had enough.

As for startup time - the latency isn't that important and would be an order of magnitude less than the ZIP construction, so the JVM warmup delay is actually just fine. The cost will be slightly higher, but it's not an operation I expect to run with high regularity - it's only on-demand for a reasonably small userbase.

As for complexity - which I am able to weigh due to the above constraints - Java's streams are not only simpler in design, but vastly more stable, and far more straightforward to glue together, and with highly stable implementations of ZIP stream wrappers and output-input pipes. A couple of additional stream wrappers for chunking into multipart upload segments and forwarding streams (introduced in JVM 9 when I'm on 8), and I was ready to go.

All that to say: don't create universal rules, though I agree that all of what you mention are good rules of thumb for certain. My given constraints work just fine with Java, here.

[kaba0]

A minimal Java app can easily start up in 0.1 seconds, which might just as well be good enough, but if not, there is also GraalVM that can output a native binary.