Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala.js 1.0.0-RC1

scala-js.org

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Scala.js 1.0.0-RC1

#21

Post by bad_user »

googleisevil6 wrote: post #4

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Sc…

> just not happy with the JVM memory reqs

I'm curious if you did any measurements and what you prefer instead.

The managed heap is very efficient. I have a web server (built in Scala) configured on my own VPS to run with a 10-100 MB heap. To this you add the JVM's memory used for managing OS threads, opened sockets, JNI, GC overhead and I end up with a process using 190 MB (RES), which is reasonable for a server-side process, because you can actually do a lot in it, Java processes being able to be fat.

In my experience a well grown Java process will be much more efficient and predictable in terms of memory used than Node.js, PHP, Ruby, Python, at the very least.

The only problem I've experienced is the startup time, plus depending on use case I might prefer native binaries. GraalVM looks promising.

Scala.js is useful on the sever for example if you need to work with "serverless" tech, e.g. AWS Lambda, for which startup time is important.

Re: Scala.js 1.0.0-RC1

#22

Post by krcz »

flowerlad wrote: post #13
googleisevil6 wrote: post #4

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Sc…

> just not happy with the JVM memory reqs Are you not happy with JVM in general or not happy with how Scala uses the JVM? Things like Spark were written in Scala so I am curious what didn’t work for you.

Spark uses off heap memory via JNI in order to avoid JVM memory management drawbacks. It hides it behind a heavy abstraction, which makes it plausible to use such solution for data processing pipelines, for the smaller applications not so much.

But for most things that is not that much a problem - I'm not saying that JVM memory model makes Scala unusable, just that Spark is not a great example here.

Re: Scala.js 1.0.0-RC1

#23

Post by fnordsensei »

googleisevil6 wrote: post #11
sjrd wrote: post #9

Earlier quoted context omitted.

The bare minimum for a hello world is 6 KB (before gzip). But of course as soon as you start using Scala collections, it's getting bigger. The minimum for a realistic application is 90 KB (before gzip). That's less than your typical JavaScript framework, so for any realistic application it shouldn't be a concern.

For refernce- Jquery unzipped is similar size- 87K and while it adds much more functionality, Scala collections easily trump jquery's in usability and power. SJRD, Would you also add a bit more info about how this size increases? I haven't cared much but it seems from your comments that the slope should be much less once you reach 90kb.

ClojureScript ends up somewhere around the same size. Maybe it's some magic number that a full-featured environment converges to.

Since Scala.js (like CLJS) is backed by Google Closure Compiler, I bet you'll also reach for the Closure Library for a lot of stuff where one might reach for JQuery or equivalent otherwise. The stuff in there is of course optimized for Closure Compiler, and slims down quite well.

Re: Scala.js 1.0.0-RC1

#24

Post by sesm »

googleisevil6 wrote: post #4

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Sc…

A more complete list of languages compiled to JS can be found here: https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

Re: Scala.js 1.0.0-RC1

#25

Post by merb »

bad_user wrote: post #21
googleisevil6 wrote: post #4

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Sc…

> just not happy with the JVM memory reqs I'm curious if you did any measurements and what you prefer instead. The managed heap is very efficient. I have a web server (built in Scala) configured on my own VPS to run with a 10-100 MB heap. To this you add the JVM's memory used for managing OS threads, opened sockets, JNI, GC overhead and I end up with a process using 190 MB (RES), which is reasonable for a server-side…

well compared to dotnet core 3 the java memory management is really really bad. in java memory is not more efficient than in node.js/php/ruby or python it's worse. what is better is the performance, especially when you have a lot of stuff on the heap the performance is predictable even with a memory size of > 16gb where the other languages lack of. GraalVM still misses a lot of stuff and is slower.

so I think the biggest buck for the bang actual is dotnet (maybe go is as good as well, but does not really play in the same league). I think once valhalla hits the tables might change, but even than ReadOnlySpan is way too awesume than just value types.

Re: Scala.js 1.0.0-RC1

#26

Post by sjrd »

fnordsensei wrote: post #23
googleisevil6 wrote: post #11

Earlier quoted context omitted.

For refernce- Jquery unzipped is similar size- 87K and while it adds much more functionality, Scala collections easily trump jquery's in usability and power. SJRD, Would you also add a bit more info about how this size increases? I haven't cared much but it seems from your comments that the slope should be much less once you reach 90kb.

ClojureScript ends up somewhere around the same size. Maybe it's some magic number that a full-featured environment converges to. Since Scala.js (like CLJS) is backed by Google Closure Compiler, I bet you'll also reach for the Closure Library for a lot of stuff where one might reach for JQuery or equivalent otherwise. The stuff in there is of course optimized for Closure Compiler, and slims down quite well.

There is a significant difference between CLJS and Scala.js regarding their use of GCC (Google Closure Compiler).

In ClojureScript, GCC is a user-visible feature of the toolchain, so users are encouraged to use GCC-compatible libraries and the Closure Library in particular.

In Scala.js, GCC is really an implementation detail of the toolchain, and its constraints are completely abstracted away from the user. This does not really encourage using GCC-oriented libraries like the Closure Library.

The two approaches each have pros and cons:

* CLJS' approach allows tree shaking across the CLJS code and the GCC-compatible libraries that are used. However, it makes it more difficult to use libraries that do not comply with GCC's Advanced Optimizations requirements, as one needs to declare the proper `externs` files.

* Scala.js' approach means that you can use any JavaScript library out of the box, whether or not it was designed for GCC, and without having to declare any `externs` file. However, it means that GCC's tree shaking will not be applied across the Scala.js code and the JS libraries. It only applies to Scala.js' own code.

Re: Scala.js 1.0.0-RC1

#27

Post by virtualwhys »

utkarshkukreti wrote: post #2

Anyone know what's the minimum size of the compiled JS now? Is there any way Scala.js can produce code as compact as BuckleScript/ReasonML in the future? I like Scala's syntax but the last time I tried Scala.js, the output was several hundred kb for something slightly more than a Hello World -- it used some List and Seq functions. I'd bet the comparable ReasonML output would likely be in tens of kb (including List an…

> the output was several hundred kb for something slightly more than a Hello World -- it used some List and Seq functions

That's just nonsense, maybe 6 or 7 years ago that could have been the case. There's an approximate 100KB "tax" for pulling in Scala collections (i.e. as soon as you depend on List, Map, Seq, etc.), which is the price to pay for being able to use the power of Scala in the browser.

> Is there any way Scala.js can produce code as compact as BuckleScript/ReasonML in the future?

No, iirc, not without a redeisgn.

There's a longstanding issue wrt lazy loading, which is slated to be worked on at some point post-1.0 -- I'd say that's probably the biggest missing feature, the ability to break out one's app into dynamic chunks, so for example a lightweight frontend/public facing area of an app can be isolated from the backend where all the heavy lifting is done.

Perhaps with Dotty (AKA Scala 3) next year there will be further reductions in Scala.js code size, but no, nothing like BuckleScript.

Re: Scala.js 1.0.0-RC1

#28

Post by spir »

googleisevil6 wrote: post #4

As someone who has dropped Scala on the backend (not doing FUD, just not happy with the JVM memory reqs)- what keeps me still using scala is Scala.js. While some argue that there is more readable code with Bloomberg's OCaml.js, I like Scala.js because of Scala itself, which is 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. and because Sc…

I recently learned that Scala.js doesn't yet support generating TypeScript *.d.ts type definitions. I intend to open a Gitcoin bounty to get this work done.

Have you had any success using Scala.js-generated JavaScript in TypeScript projects?

I'm quite interested in a full stack of create-react-app + TypeScript + graphQL + front end libraries written in Scala + back end services written in Scala.

Re: Scala.js 1.0.0-RC1

#29

Post by bad_user »

merb wrote: post #25
bad_user wrote: post #21

Earlier quoted context omitted.

> just not happy with the JVM memory reqs I'm curious if you did any measurements and what you prefer instead. The managed heap is very efficient. I have a web server (built in Scala) configured on my own VPS to run with a 10-100 MB heap. To this you add the JVM's memory used for managing OS threads, opened sockets, JNI, GC overhead and I end up with a process using 190 MB (RES), which is reasonable for a server-side…

well compared to dotnet core 3 the java memory management is really really bad. in java memory is not more efficient than in node.js/php/ruby or python it's worse. what is better is the performance, especially when you have a lot of stuff on the heap the performance is predictable even with a memory size of > 16gb where the other languages lack of. GraalVM still misses a lot of stuff and is slower. so I think the big…

Speaking of the mainstream scripting languages ...

Python often leaks memory, the GC being built on top of reference counting to solve cycles, isn't compacting and can also be left disabled for performance, which is a trap. This is made worse by native libraries that also leak. It has gotten better, Python apps being one of the most deployed. But I haven't seen a Python app that's memory efficient yet, except for short lived shell scripts.

PHP uses tens of MB per request, which due to its "shared nothing" policy means you need several GBs of RAM for serving a Wordpress website that can withstand traffic spikes.

Many companies actually deploy their Ruby apps on top of the JVM, via JRuby, due to better memory usage.

Node.js is the only one that's more efficient out of this bunch, the GCs have similar implementations to the JVM and optimized for devices that are memory constrained, the problem being that Node.js processes are single threaded, so to distribute the load, you end up with multiple processes, plus due to JavaScript you also get more garbage.

> the biggest buck for the bang actual is dotnet

Not in my experience, but granted I haven't tested .NET Core yet.

Re: Scala.js 1.0.0-RC1

#30

Post by rb808 »

merb wrote: post #25
bad_user wrote: post #21

Earlier quoted context omitted.

> just not happy with the JVM memory reqs I'm curious if you did any measurements and what you prefer instead. The managed heap is very efficient. I have a web server (built in Scala) configured on my own VPS to run with a 10-100 MB heap. To this you add the JVM's memory used for managing OS threads, opened sockets, JNI, GC overhead and I end up with a process using 190 MB (RES), which is reasonable for a server-side…

well compared to dotnet core 3 the java memory management is really really bad. in java memory is not more efficient than in node.js/php/ruby or python it's worse. what is better is the performance, especially when you have a lot of stuff on the heap the performance is predictable even with a memory size of > 16gb where the other languages lack of. GraalVM still misses a lot of stuff and is slower. so I think the big…

I agree dotnet is great technically but it'll never be fashionable, SV just doesn't do MS.
Post reply on HN