5 ms·
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 so
by googleisevil6 7y ago
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 Scala.js interop with JS is very seamless.
Do check out ScalablyTyped repo on Github, a Scala.js analogue of DefinitelyTyped.
Being typed- one of the best things I like about Scala is that I can do something like this (provided by a couple of frameworks- Laminar, Scalatags et al)
<pre>
div(
Seq( div( "div 1" ) ),
div( "div 2" ),
b(
"bold stuff",
i( "italic inside bold" )
)
)
</pre>
No more mismatching tags, wrongly spelled tags, unclosed tags. Typechecked HTML in some sense.
This would also be a good place to mention some alternatives where a mainstream language can also compile to JS so hopefully people can comment with their experience:
1) F#- Fable
2) OCaml- Bloomberg's BuckleScript
3) Go- Gopher
4) Haskell- GHCJS
Other non-mainstream but compile-to-JS languages
1) PureScript
2) ELM
3) Clojure script (child comment)
... and of course... TypeScript! :)
It should be noted that while Scala.js isn't as popular as some of it's alternatives in "popular" programmer culture, the author is very focussed on correctness and I don't know of anybody who has ever used Scala.js for a project but dropped it. (Happy to be corrected)
- LandR 7y agoClojureScript too, if you don't mind dynamic typing.
- mateuszf 7y agoYeah, ClojureScript is amazing.
- flowerlad 7y ago> 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.
- krcz 7y agoSpark 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.
- bad_user 7y ago> 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.
- merb 7y agowell 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<T> is way too awesume than just value types.
- bad_user 7y agoSpeaking 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.
- sesm 7y agoA more complete list of languages compiled to JS can be found here: https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffeescript/wiki/List-of-langu...
- spir 7y agoI 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.
- Nullabillity 7y agoIn general I'd advise against using Scala.js for libraries. The Scala.js runtime is pretty heavy, and Scala's and TypeScript's type systems are different enough that it tends to be difficult to design an API that feels native in both. Have you considered ScalaJS-React[0] or Outwatch[1] instead? [0]: https://github.com/japgolly/scalajs-react https://github.com/japgolly/scalajs-react [1]: https://outwatch.github.io/?lang=scala https://outwatch.github.io/?lang=scala
- brillout 7y agoWhy GraphQL? Why not simply RPC? E.g. for JS there is https://github.com/reframejs/wildcard-api https://github.com/reframejs/wildcard-api. Is there something like that in Scala?
- atc 7y ago> 1) Very well designed 2) Lots of "functional" constructs in accompanying libraries 3) Good typechecking 4) Fun language to use. ... Just use Typescript.
- vips7L 7y agoWhy not scala native or substrateVM if you want lower memory requirements?
- virtualwhys 7y agoScala 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 https://github.com/scala-native/scala-native
- vips7L 7y agoYeah I figured that was the case. There is a lot of steam behind native-image with graal/substrate though.
- kjsingh 7y agoYes the user community seems to think that GraalVM can do whatever Scala Native can.
- ekrich 7y agoThe 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-with-scala-native https://pragprog.com/book/rwscala/modern-systems-programming... and I am hoping it will continue to grow and evolve.
- apta 7y ago> has dropped Scala on the backend What did you replace it with out of curiosity?