Hacker News Reader

Comment by mark242 | Hacker News Reader

This will be huge for getting Scala running on AWS Lambda. The cold-start times for JVM apps is just ridiculous and makes Lambda/API gateway essentially unusable for anything written on the JVM.

View on HN

Actually, there are people using Scala.js to run Scala on AWS lambda, precisely for that reason.

* https://github.com/tptodorov/aws-lambda-scalajs

* http://underscore.io/blog/posts/2016/03/21/serverless-scale-...

^ From the creator of Scala.js :)

I am excited that now there will be an option for getting both quick startup and fastest execution time!

Sure, but it'd be nice not to have everything in the known universe depend on JavaScript.

Absolutely! I'm just pointing out that this need is so strong that people have reached for the slow throughput of Scala.js just to get its fast startup time. If we can have both, that's even better!

No intention of arguing with Scala.js' creator :-) But, I do not think it has a "slow throughput" at all. In my experience, it's had pretty good performance.

Oh it does have pretty good performance, on par with hand-written JavaScript. But that's still 3x slower than Scala/JVM on our benchmarks, and those benchmarks are ported from the Octane benchmark suite used by V8 (so supposedly that's where V8 shines).

Everything is relative. Scala.js remains significantly slower than Scala/JVM in terms of throughput.

I disagree. Having a common language in many places has led to huge improvements over the board in the JS ecosystem, it's become the "C" of the modern era, and you can build a lot of stuff on the foundations that others have laid.

I still hate JS though.

Which is anything but positive, as it also shares C's style of unsafety due to its semantics.

Javascript performs unchecked memory accesses? Or are you alluding to their both being weakly typed?

No,but implicit conversions, including from operators into numeric values isn't much better.

The amount of page differences between "JavaScript the good parts" and the actual language reference speaks for itself.

One might argue the same point based on the fact that there even exists a book called "JavaScript: The Good Parts".

That book was created before many alternatives came out; now if you are working in a team project you should look at JavaScript the same way you look at assembler, you know it will be the final thing but you shouldn't be creating it directly, but instead "compiling" from TypeScript, ELM, etc. (langs with no implicit conversions, strong typing, etc)

Those alternatives are nice in startup land, in enterprise consulting land, we get to use what the customer IT department sanctions as allowed programming languages and tools installed on computers for external consultants.

Which is ultimately irrelevant here. Consider, C is rock solid safe compared to machine/assembly.

(Though, I tend to share the annoyance of javascript...)

C is just as unsafe as Assembly, as the weekly CVE entries prove.

The only differences between C and a powerful macro assembler like MASM, is that C is portable across CPU architectures and exposes less internals.

Rock solid?

With all the UB that Assembly actually doesn't have, and the types of memory corruption issues shared with Assembly programming, not really.

My point is that safety or otherwise of the target language is just not relevant. Even C has compile errors if you use the wrong type for an operation. Assembly largely does not.

Taken to the extreme, any language ultimately goes down to machine code. So if it was a relevant fact, it would be relevant for all languages.

> Even C has compile errors if you use the wrong type for an operation. Assembly largely does not.

There are strong typed assemblers, e.g. IBM i.

Also Assemblers don't remove code under your feet, like optimizing C compilers with their UB tricks happen to do, introducing security bugs.

Saw the same for clojure. People used clojurescript/plank for live dev.

> This will be huge for getting Scala running on AWS Lambda.

Do you mean it might convince Amazon to add Scala as a supported language? You don't get access to run native code on AWS, just Python, Java, C#, or JS.

And, even with a robust, mature native implementation, I'm not sure that Scala would be the top priority for the next language.

You can run native code on AWS Lambda. It just isn't officially supported. See Apex for an example of how to get it working..

https://github.com/apex/apex

Go on Lambda https://github.com/eawsy/aws-lambda-go Rust on Lambda http://julienblanchard.com/2015/rust-on-aws-lambda/

etc. etc.

I don't understand. How does the ability to generate native code help getting something running on AWS Lambda? By using asm.js?

You can achieve this by executing the native program in a child process. Apex is doing something similar to support golang in AWS Lambda, here is more info http://apex.run/#understanding-the-shim

Reply on news.ycombinator.com