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

51–59 of 59 posts

Re: Scala.js 1.0.0-RC1

#51

Post by imtringued »

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…

I have some very simple lua processes that consume 2MB. They basically do nothing but listen to a websocket and run some shell comands. Lets say I have 3 of those. With the JVM I would have blown away more than half a gigabyte. Even with micronaut you're looking at 100MB per process. This just isn't sustainable. I personally think the JVM is a piece of crap because of this.

There is GraalVM but compilation takes a relatively long time even compared to a C++ project and as soon as you use features that it doesn't support it will fail to work which means you are stuck with Java because you don't want to risk using a language that doesn't officially support GraalVM (groovy kotlin etc).

Re: Scala.js 1.0.0-RC1

#52

Post by ramnivasl »

sjrd wrote: post #45
AzzieElbab wrote: post #44

Earlier quoted context omitted.

fine, but what tooling/workflow would one use for the type of development javascripters are accustomed to? Like make a change and immediately observe result on the page?

Workbench [1], for example :) [1] https://github.com/lihaoyi/workbench

Also, if you use webpack (directly or through scalajs-bundler), the use of webpack-dev-server makes live loading automatic.

Re: Scala.js 1.0.0-RC1

#53

Post by ramnivasl »

sjrd wrote: post #12
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.

Yes once you're at 90 KB the slope will be much less. It will simply grow with the actual code of your app.

Indeed, once you end up pulling in most common Scala classes (collections, futures, etc.), adding new functionality to your app increases app size by very little. Our app has ~600KB gzipped js (attributable to Scala.js compiled code) + ~200KB of React and other libraries. The overall size has barely moved beyond +-100KB in last few years despite adding new functionality all the time.

Once Scala.js supports lazy loading of modules (hopefully soon after 1.0), the size issue will have significantly less practical impact.

Re: Scala.js 1.0.0-RC1

#54

Post by kjsingh »

virtualwhys wrote: post #35
vips7L wrote: post #34

Earlier quoted context omitted.

Why not scala native or substrateVM if you want lower memory requirements?

Scala Native [1] has been really quiet of late (last commit July 29), not sure what's going on. There was a lot of excitement when the project kicked off, hopefully it continues to evolve. [1] https://github.com/scala-native/scala-native

Yes the user community seems to think that GraalVM can do whatever Scala Native can.

Re: Scala.js 1.0.0-RC1

#55

Post by ekrich »

virtualwhys wrote: post #35
vips7L wrote: post #34

Earlier quoted context omitted.

Why not scala native or substrateVM if you want lower memory requirements?

Scala Native [1] has been really quiet of late (last commit July 29), not sure what's going on. There was a lot of excitement when the project kicked off, hopefully it continues to evolve. [1] https://github.com/scala-native/scala-native

The creator and lead contributor has been finishing up his school but I am not sure of his plans for the future. There is a book coming out on the subject, https://pragprog.com/book/rwscala/modern-systems-programming... and I am hoping it will continue to grow and evolve.

Re: Scala.js 1.0.0-RC1

#57

Post by MaxBarraclough »

imtringued wrote: post #51
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…

I have some very simple lua processes that consume 2MB. They basically do nothing but listen to a websocket and run some shell comands. Lets say I have 3 of those. With the JVM I would have blown away more than half a gigabyte. Even with micronaut you're looking at 100MB per process. This just isn't sustainable. I personally think the JVM is a piece of crap because of this. There is GraalVM but compilation takes a re…

True, but in the same way that a 747 is terrible for delivering pizza.

You may be right that Java doesn't scale down well, but that's not normally the sort of work it's intended for. (Let's ignore the applets mistake.) It's a terrible solution for scripting, yes, but for heavyweight server roles I'd be surprised to see it significantly outperformed by .Net, and there's really no way Lua or Python would be able to compete.

OpenJDK has a very impressive (and heavyweight) JIT, for instance, and very impressive GCs of almost no use for short-lived applications.

With all that said, it'd be great if OpenJDK's new developments mature to the point that Java can become practical for 'lightweight work'.

Re: Scala.js 1.0.0-RC1

#58

Post by brillout »

spir wrote: post #28
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.

Why GraphQL? Why not simply RPC?

E.g. for JS there is https://github.com/reframejs/wildcard-api. Is there something like that in Scala?

Re: Scala.js 1.0.0-RC1

#59

Post by merb »

vips7L wrote: post #33
merb wrote: post #25

Earlier quoted context omitted.

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…

>GraalVM still misses a lot of stuff and is slower. Are there benchmarks for this?

well he talked about the AOT stuff. which is not on par as dotnet core's aot approach in 3.0, however default graalvm is quite fast (but still memory hungry)
Post reply on HN