Announcing Scala.js v0.1(scala-lang.org)
scala-lang.org
Announcing Scala.js v0.1
http://www.scala-lang.org/news/2013/11/29/announcing-scala-js-v0.1.html
15 comments
This is a game changer. I've used it over the last few 3 or 4 months, and it is really stable and usable. I am betting an entire (although academic) project on it: http://proofpeer.net (note that Clojure is mentioned there as a language of choice, but I switched to Scala since then as Scala provides a similar level of conciseness with all the goodies of a powerful static type system with support for both Java and Javascript).
Wow! I started working on a very similar idea half a year ago -- with machine learning and everything (my domain was proofgraph.org). I had to suspend it since it is larger than a one mans freetime project. I am very glad that someone started with a similar idea!
Will it be open source? I would be happy to contribute (I work full-time with Scala).
Will it be open source? I would be happy to contribute (I work full-time with Scala).
It is open source. I am sure the committers would be happy to get additional help.
I like static typing, but do you ever get the feeling that we've collectively gone off the deep end with the whole backwards compatibility hacks that compile-to-javascript languages represent? Think about it...we have implementations of static languages on top of a dynamic runtime that translates it back to a static runtime. We have non-GC languages that have developed ways to compile to a GC language and avoid GC. It is absolutely amazing, and completely silly at the same time.
Indeed. It's almost as if the ECMA should just freeze all JavaScript development, and replace it with a standard, low level, high performance compiler target that all browsers can implement instead, and then just let the industry/community write competing compiled languages for it. That's essentially where browsers are heading anyway with asm.js and NACL.
For everyone who still loves JS and prefers it over Coffee/Type/Clojure/etc-scripts, just make a JS compiler and keep all its quirks and wtfs.
For everyone who still loves JS and prefers it over Coffee/Type/Clojure/etc-scripts, just make a JS compiler and keep all its quirks and wtfs.
Not at all, there is a great deal of precedence in computer science for building durable interfaces on top of unstable ones.
I also keep thinking of it as a game changer. Why ever bother with prototypes again when you have case classes, or callbacks when you have function shorthands. I fully expect Scala.js code to be more concise and maintainable than Javascript code, and will probably perform better too thanks to the Closure compiler.
I remember how years ago I complained about how Javascript was the only language aviable for the web.
Nowadays you can even run sliced bread on Javascript... though, wouldn't it be better to focus on developing languages on top of asm.js or PNacl so we wouldn't rely on JS?
Nowadays you can even run sliced bread on Javascript... though, wouldn't it be better to focus on developing languages on top of asm.js or PNacl so we wouldn't rely on JS?
I completely agree. While asm.js has its problems, its moving in the right direction. Honestly, it seems like this wouldn't be too hard to add a backend target for asm.js, if its implemented well.
Note that asm.js (and probably PNaCL as well) currently offers very little for languages like Scala that need good GC. Until that's addressed simply targeting JavaScript is going to be best approach for these languages.
I don't think running a garbage collected languages on asm.js will ever make any sense (since it would mean implementing and shipping your own GC as part of the application source). So, yeah, you're right. Scala (as-is) is not a good language to target any of the "native" targets like asm.js.
Remember to write the slidedbread.js in under 30 lines :)
Fun demos using Scala.js:
http://lihaoyi.github.io/scala-js-games/ http://lihaoyi.github.io/scala-js-game-2/
The second one has some performance issues, and bugs out initially when first opened in FF (need to refresh before it works properly) but otherwise it's pretty fun =)
http://lihaoyi.github.io/scala-js-games/ http://lihaoyi.github.io/scala-js-game-2/
The second one has some performance issues, and bugs out initially when first opened in FF (need to refresh before it works properly) but otherwise it's pretty fun =)
For those who haven't heard about it. The initial presentation:
http://www.parleys.com/play/51c380bfe4b0ed8770356866/
As someone who doesn't really know anything about scala, why is this a cool thing?
While such an early release is definitely aimed at scala enthusiast, I'd still like a sales pitch for the rest of us.
While such an early release is definitely aimed at scala enthusiast, I'd still like a sales pitch for the rest of us.
Mmmmm basically I think it's because Scala itself is in a really captivating position, so seeing these utilities emerge makes it that much more promising.
I've switched from RoR to Scala on Play framework and at this point it's one of those things where you use & say "this is sick" but are still discouraged because the community is so small in comparison.
But with Akka, with the Typesafe Console & other niceties you realize "hm.. well... maybe the community isn't as large but they are prepping the toolset to be immensely powerful". And here is one more tool on that belt. I'm sure the reason is different for others, but just note that Scala is a JVM language competing in the same space as Ruby/Python, as well as with some of the functional languages. That alone is huge and making it a great general purpose language.
I've switched from RoR to Scala on Play framework and at this point it's one of those things where you use & say "this is sick" but are still discouraged because the community is so small in comparison.
But with Akka, with the Typesafe Console & other niceties you realize "hm.. well... maybe the community isn't as large but they are prepping the toolset to be immensely powerful". And here is one more tool on that belt. I'm sure the reason is different for others, but just note that Scala is a JVM language competing in the same space as Ruby/Python, as well as with some of the functional languages. That alone is huge and making it a great general purpose language.
In my mind, Akka is the reason to use Scala right now. Actors are an incredibly powerful abstraction for building highly-concurrent, highly performant systems and the features Akka brings along—remoting, clustering and now event sourcing—make it a fantastic tool for these applications.
But then, I'm a backend developer and Akka is more useful in that realm.
Play still needs some work IMO. It's great if you need the real-time steaming or a very performant web app but otherwise the lack of scaffolding and other features will really slow you down. I love it but it's still early for most uses. If you come in expecting Rails, you'll be disappointed. For instance, you need to write your own authentication layer, Play doesn't provide one.
OTOH, I was able to write a real-time cluster monitor in Play for our Akka-based backend and the streaming component took less time to write than the setting up the app—it's that straightforward.
IMO, if you need them, Play's other features more than make up for its less polished aspects and I fully expect those to get fixed in time, especially now that Typesafe has brought Play under its wing.
But then, I'm a backend developer and Akka is more useful in that realm.
Play still needs some work IMO. It's great if you need the real-time steaming or a very performant web app but otherwise the lack of scaffolding and other features will really slow you down. I love it but it's still early for most uses. If you come in expecting Rails, you'll be disappointed. For instance, you need to write your own authentication layer, Play doesn't provide one.
OTOH, I was able to write a real-time cluster monitor in Play for our Akka-based backend and the streaming component took less time to write than the setting up the app—it's that straightforward.
IMO, if you need them, Play's other features more than make up for its less polished aspects and I fully expect those to get fixed in time, especially now that Typesafe has brought Play under its wing.
Have been using Play for a couple of years now.
In regard to missing components, the goal is not to provide the kitchen sink, but rather the tools to build your house.
This is where RoR, Django, etc. differ from Play. Play just provides the basic MVC stack along with essentials like, modular routing (AKA sub projects), excellent form generation and validation, http request wrappers (AKA action composition) for say, authentication ;-), an OK template layer (could be better, generics not supported), etc.
Agreed, Play will not give you the rapid fire dynamic language based framework development experience, not while getting your feet wet at any rate.
On the flipside, you've got the JVM ecosystem at your finger tips, a static type system backing your every (errant) move, blazing fast performance in production, and general zero-stress on deploy, the shit just works.
In regard to missing components, the goal is not to provide the kitchen sink, but rather the tools to build your house.
This is where RoR, Django, etc. differ from Play. Play just provides the basic MVC stack along with essentials like, modular routing (AKA sub projects), excellent form generation and validation, http request wrappers (AKA action composition) for say, authentication ;-), an OK template layer (could be better, generics not supported), etc.
Agreed, Play will not give you the rapid fire dynamic language based framework development experience, not while getting your feet wet at any rate.
On the flipside, you've got the JVM ecosystem at your finger tips, a static type system backing your every (errant) move, blazing fast performance in production, and general zero-stress on deploy, the shit just works.
I'm certainly not complaining. The toolkit Play offers today more than makes up for any deficiencies IMO.
And yes, action composition is how we handle authentication. ;)
And yes, action composition is how we handle authentication. ;)
yeah i agree it may not be ultra-streamlined for rapid application development yet, but i don't have any critical work i need to do with it. to me it's really just an excuse to learn Akka. When I read about Netflix's async Java libraries (RxJava I think its called) I realized how the Java world really has an edge in making advanced web apps.
The more polished frameworks are better for building apps quickly, sure, but as a technically-oriented developer (I am full-stack, usually above DSL) I'm more interested in making my mark by understanding some useful persistence/eventing/concurrency stuff. If we can master this, I believe it will be the thing that finally brings a unified model to web app development that simplifies the entire end-to-end flow without requiring redundant code or limited choices about persistence scopes.
It's strange that they don't have some scaffolding and authentication features, but as you said they'll come in time. It's just odd because they are on the more trivial end of the toolset.
But that doesn't turn me off and maybe that's the point. It's not really meant for someone trying to make a CRUD app. Sure it should and will be able to do this well, but to me the JVM is the place where people are really trying to dig past CRUD and get to some novel data-and-event-driven apps.
Lucky for me this is something I'm learning as a hobby so I don't have to support production-level apps with it anyway. But yeah to me it feels like they've taken a lot of the attractive features of Django/RoR and backed them with some more serious language features. This may be a bit delusional since I guess Ruby & Python are legitimate in their own right, but.... well, as you can tell, I'm more excited for a JVM language to try to introduce stronger modern design patterns into the framework world. MVC on it's own is dead & done (er... solved), it's the extra unifying logic layers that are more important now.
The more polished frameworks are better for building apps quickly, sure, but as a technically-oriented developer (I am full-stack, usually above DSL) I'm more interested in making my mark by understanding some useful persistence/eventing/concurrency stuff. If we can master this, I believe it will be the thing that finally brings a unified model to web app development that simplifies the entire end-to-end flow without requiring redundant code or limited choices about persistence scopes.
It's strange that they don't have some scaffolding and authentication features, but as you said they'll come in time. It's just odd because they are on the more trivial end of the toolset.
But that doesn't turn me off and maybe that's the point. It's not really meant for someone trying to make a CRUD app. Sure it should and will be able to do this well, but to me the JVM is the place where people are really trying to dig past CRUD and get to some novel data-and-event-driven apps.
Lucky for me this is something I'm learning as a hobby so I don't have to support production-level apps with it anyway. But yeah to me it feels like they've taken a lot of the attractive features of Django/RoR and backed them with some more serious language features. This may be a bit delusional since I guess Ruby & Python are legitimate in their own right, but.... well, as you can tell, I'm more excited for a JVM language to try to introduce stronger modern design patterns into the framework world. MVC on it's own is dead & done (er... solved), it's the extra unifying logic layers that are more important now.
Er, doesn't .NET have Reactive Extensions (and RxJS too) by none other than Erik Meijer? Where's the love? Even MS does something right sometimes....
Yep, the Erik Meijer wrote the original Rx while at Microsoft Research. Others have expanded his work: now there's RxJS, RxCpp, Rx.rb, Rx.py, etc.:
https://rx.codeplex.com/
https://rx.codeplex.com/
heh here is where i need to apologize for not paying attention to .NET :(
i had a bad experience with it in my early days of webdev. moreso my fault than microsoft, but by the time it was over i was firmly lodged in the open source world.
Netflix has many other cool Java libs besides just RxJava, but by all means give credit where credit is due. Interesting to know
i had a bad experience with it in my early days of webdev. moreso my fault than microsoft, but by the time it was over i was firmly lodged in the open source world.
Netflix has many other cool Java libs besides just RxJava, but by all means give credit where credit is due. Interesting to know
In my mind, Akka is the reason to use Scala right now.
Why? Akka works fine with Java, Kotlin, and most other JVM languages.
Why? Akka works fine with Java, Kotlin, and most other JVM languages.
I'm sure this is going to read as dickish, but I personally would be much more inclined to give a thoughtful response if your question showed some evidence of you having attempted to explore this question before asking other people to spoon feed you answers.
This is really one of those questions that _requires_ someone to spoon feed you the answer.
He is asking a Scala expert to describe how a port to JavaScript allows developers to take advantage of advanced Scala language features or tools. The alternative is spending hours working with Scala and coming up with the answer himself.
Being a discussion forum, I don't see why you have a problem giving away knowledge freely over HN.
He is asking a Scala expert to describe how a port to JavaScript allows developers to take advantage of advanced Scala language features or tools. The alternative is spending hours working with Scala and coming up with the answer himself.
Being a discussion forum, I don't see why you have a problem giving away knowledge freely over HN.
I've got no problem at all answering people's questions, if you look at my comment history. I just think this particular question was both vague and lazily written. It's natural that a question requires more effort to answer than to ask, but a thoughtfully asked question clues potential answerers into what the asker already knows and has already attempted to do to educate themselves. Like "I know Scala is X and Y, but why would these things be useful on the browser side?" or if you don't know anything about Scala in the first place, "I read Wikipedia about Scala but didn't understand Z, could someone explain this?"
Anyway, the answer of his questions has definitely its place in this thread, so it's a good thing that someone is asking it.
You're looking for a sales pitch for Scala? I can't provide that, but I'd argue that having the same language on two rather different platforms is pretty cool/useful in any case.
I'm finding a sort of corollary of JavaScript being a byte-code equivalent for the web, what with everything being translated to compilation in js syntax.
Maybe the browsers need to move beyond JavaScript interpretation, and think about things more like a VM to allow actual scala/java/c#/ruby/python/erlang/lua/something-completely-new/etc. to be executed in context.
Or, maybe a more forward-thinking approach would be to consider "docker in the browser" -- containers that run in execution. Probably a performance nightmare, but I'm thinking of an interesting compilation of bits -- CMS done well in Ruby, an e-commerce cart in Python, data charts in Erlang, and enterprise-based workflows in Java -- all working together, client-side.
Disclaimer: it's a holiday and I'm enjoying a nice cabernet sauvignon. Thought clarity and consistency may not necessarily be present at this point in time.
Maybe the browsers need to move beyond JavaScript interpretation, and think about things more like a VM to allow actual scala/java/c#/ruby/python/erlang/lua/something-completely-new/etc. to be executed in context.
Or, maybe a more forward-thinking approach would be to consider "docker in the browser" -- containers that run in execution. Probably a performance nightmare, but I'm thinking of an interesting compilation of bits -- CMS done well in Ruby, an e-commerce cart in Python, data charts in Erlang, and enterprise-based workflows in Java -- all working together, client-side.
Disclaimer: it's a holiday and I'm enjoying a nice cabernet sauvignon. Thought clarity and consistency may not necessarily be present at this point in time.
[deleted]
I wonder how complicated it is to parse JSON in Scala.js. It's pretty involved in regular Scala and incredibly easy in JavaScript, so what's it like in Scala.js?
Parsing JSON in Scala is very easy with lift-json:
https://github.com/lift/lift/tree/master/framework/lift-base...
There's also Play-Json, Spray-Json, various wrappers for Jackson and a few others I don't remember. We use Play-Json and its macros a lot at the company I work for and I contributed a performance fix for it a while back. I wouldn't consider Play's JSON inception to be "pretty involved" at all if you're using case classes.
http://www.playframework.com/documentation/2.2.x/ScalaJson
https://github.com/spray/spray-json
http://www.playframework.com/documentation/2.2.x/ScalaJson
https://github.com/spray/spray-json
Well, damn it, now I have to bookmark this thread.
Lots of options, see the complete list here: http://stackoverflow.com/a/14442630
We use Argonaut at Snowplow.
We use Argonaut at Snowplow.
I use argonaut.io and it isn't really hard so much as tedius compared to JavaScript or Python.
Is this supposed to be ironic? Considering JSON.parse( {a: "B"} )
JSON is always going to be a bit more difficult to parse in statically typed languages than dynamically typed ones.
The amusing part is that most APIs use JSON as if it were statically typed - except for null/undefined, very few APIs return values of more than one possible type for a given key[0].
It doesn't always have to be so bad, though, even in statically typed languages. For example, I created a tool in Go to automatically generate struct definitions, given an example JSON response: https://github.com/ChimeraCoder/gojson
In the time that I've been using it (since last December), I don't think I've run into any issues with an API returning an incorrect type for a particular key[1].
[0] For the record, I'm not complaining. The alternative would be a nightmare to deal with. [1] Though they do sometimes return a different object altogether; this is an issue regardless of which type system you use.
The amusing part is that most APIs use JSON as if it were statically typed - except for null/undefined, very few APIs return values of more than one possible type for a given key[0].
It doesn't always have to be so bad, though, even in statically typed languages. For example, I created a tool in Go to automatically generate struct definitions, given an example JSON response: https://github.com/ChimeraCoder/gojson
In the time that I've been using it (since last December), I don't think I've run into any issues with an API returning an incorrect type for a particular key[1].
[0] For the record, I'm not complaining. The alternative would be a nightmare to deal with. [1] Though they do sometimes return a different object altogether; this is an issue regardless of which type system you use.
Given that it uses reflect I bet your library very slow. I wonder how it compares to parsing JSON in Python or node.js.
> except for null/undefined,
That's not a small issue.
Not only do JSON responses for API's vary a great deal from request to request, some handle errors without HTTP response code's. So the JSON you get back can be very different then you might expect otherwise.
> except for null/undefined,
That's not a small issue.
Not only do JSON responses for API's vary a great deal from request to request, some handle errors without HTTP response code's. So the JSON you get back can be very different then you might expect otherwise.
> Given that it uses reflect I bet your library very slow.
Look carefully - what I wrote is not a library; it's a standalone binary. It's run exactly once, when you write the code, so speed isn't an issue.
> That's not a small issue.
Depends on the language. In Go, it's very easy to allow a JSON value to be null and/or undefined by making the value it unmarshals to a pointer (which you should be doing already anyway).
What's harder (in most languages, not just Go) is dealing with a value that could be (say) either a string, or a 64-bit int. Or, worse, a string whose value just happens to be a 64-bit number. When that happens (which is thankfully rare), it breaks the "JSON should be self-documenting" motto.
> So the JSON you get back can be very different then you might expect otherwise.
This is an issue no matter what language you use. You have to know what the set of possible response structures is in order to know what keys to query/access.
Look carefully - what I wrote is not a library; it's a standalone binary. It's run exactly once, when you write the code, so speed isn't an issue.
> That's not a small issue.
Depends on the language. In Go, it's very easy to allow a JSON value to be null and/or undefined by making the value it unmarshals to a pointer (which you should be doing already anyway).
What's harder (in most languages, not just Go) is dealing with a value that could be (say) either a string, or a 64-bit int. Or, worse, a string whose value just happens to be a 64-bit number. When that happens (which is thankfully rare), it breaks the "JSON should be self-documenting" motto.
> So the JSON you get back can be very different then you might expect otherwise.
This is an issue no matter what language you use. You have to know what the set of possible response structures is in order to know what keys to query/access.
> Look carefully - what I wrote is not a library; it's a standalone binary. It's run exactly once, when you write the code, so speed isn't an issue.
Oh missed that.
> This is an issue no matter what language you use.
It's a lot bigger issue when you have to define classes for each type of possible response.
Oh missed that.
> This is an issue no matter what language you use.
It's a lot bigger issue when you have to define classes for each type of possible response.
Incidentally, the one place I often have to deal with values of different types for the same key is from a java app that is poorly converting XML -> JSON and converts a list with a single element into just the element.
It's exactly the same as in JavaScript: JSON.parse(...)
Scala has Dynamic types for when you want to play rough like that.
Scala has Dynamic types for when you want to play rough like that.
You can just use the Javascript Api's for that. So the answer would be incredibly easy.
This is exactly what I've been hoping for - I'd like to write little games/etc in Scala, but it's a lot easier to distribute JS.
Anyone know how the compilation times compare with regular Scala?
Scala's compile times (along with other aspects of its development experience) are among my biggest annoyances with the language. It just seems like it should be way better than it is for such an intellectually advanced language.
I've been investing a lot of time in learning Scala because I think that it's at the head of the vanguard of a software engineering revolution, but with some of its ergonomic issues, I can't help thinking it's eventually going to lose out to something that's more elegant from a design standpoint and has better tooling.
I've been investing a lot of time in learning Scala because I think that it's at the head of the vanguard of a software engineering revolution, but with some of its ergonomic issues, I can't help thinking it's eventually going to lose out to something that's more elegant from a design standpoint and has better tooling.
Take a look at Kotlin (http://kotlin.jetbrains.org), it was designed to address the issues you mention.
Fascinating, thanks! For anyone else interested, I found this to be useful: http://confluence.jetbrains.com/display/Kotlin/Comparison+to...
Kotlin seems like a lightly stripped down Scala.
Lightly? I'd say one of the most important features were removed - implicits and most of the typesystem magic. Kotlin feels just like Java with lambdas, better null checking. slightly improved generics and some minor syntactic refinements. Most of its "features" will be obsoleted by Java 8.
It's basically equivalent to Scala for the compilation itself (no noticeable difference).
But the browser refresh in dev mode can take up to 5 seconds (or down to under 1 sec, depends on the machine).
There is a tool that helps with this by using clever tricks to refresh the browser without reparsing the standard lib:
https://github.com/lihaoyi/scala-js-workbench
Too bad that there is not more effort on Scala.NET instead of this. Lots of people are comfortable with writing Javascript in the browser so all of these compilers emitting Javascript end up being little more than a technology demo. But Scala on the .NET vm would really fill a gap.
I used to wish for this also. But then I found C# to be pretty good; maybe it doesn't have as many features as Scala, but it is definitely a step up from Java.
The demand for Scala on .NET just doesn't seem to be that large, couple with the fact that reified generics make encoding Scala directly kind of difficult (Nikolay Mihaylov spent a lot of time on that).
The demand for Scala on .NET just doesn't seem to be that large, couple with the fact that reified generics make encoding Scala directly kind of difficult (Nikolay Mihaylov spent a lot of time on that).
>> But then I found C# to be pretty good; maybe it doesn't have as many features as Scala, but it is definitely a step up from Java.
I left C# to do Java, Java is a step up from C#.
I left C# to do Java, Java is a step up from C#.
How so? I started out in Java, then did a lot of Scala for a couple of years, and have been mainly working in C# for the last 6 years afterwards. The only things I miss from Java are anonymous inner classes and some of the better debugging features (hot code replace) that Visual Studio hasn't really matched yet (edit and continue is not as robust).
I miss many things from Scala in comparison, but C# has some good features that almost make up for it.
I miss many things from Scala in comparison, but C# has some good features that almost make up for it.
What niche do you see Scala filling on .NET that isn't already handled by F#?
Case in point, .NET already has FunScript, an F#-to-JS compiler: http://funscript.info/
FunScript also provides a way to do strongly-typed interop with TypeScript, via F#'s type providers.
Case in point, .NET already has FunScript, an F#-to-JS compiler: http://funscript.info/
FunScript also provides a way to do strongly-typed interop with TypeScript, via F#'s type providers.
F# is primarily functional, Scala is much more of a hybrid of both OO and FP; so Scala has things like traits that are actually advanced OOP constructs, while F# tries to push you more in the direction of pure FP.
The tradeoffs are different also. F# focuses a lot on performance in the spirit of Caml, whereas Scala is a bit more free to dive into more powerful features that go against that spirit. This is my grock at least of my conversations with Don and Martin over lunch when Don was doing his sabbatical at EFPL.
The tradeoffs are different also. F# focuses a lot on performance in the spirit of Caml, whereas Scala is a bit more free to dive into more powerful features that go against that spirit. This is my grock at least of my conversations with Don and Martin over lunch when Don was doing his sabbatical at EFPL.
Why would you need anything on .net which already runs on the JVM? Is there any platform where you can install .net but not the JVM? Or does .net have a significantly better performance than the JVM?
Imagine a polyglot project where some major .Net libraries are already in use, but ongoing development or integration was done in Scala.
I'm not saying it's a good idea, but there's a use case there.
I'm not saying it's a good idea, but there's a use case there.
Wouldn't it be a direct competitor for F# then instead of "filling the gap"? Scala has some more features, but the idea of fast and expressive functional-oop language is basically the same for both of them.
Also, F# was there first, has very good support in IDEs, integration with core .NET, etc. I think Scala would have a rather hard time on CLR (I may be biased, I don't know Scala very much and I worked with OCaml long before F# happened).
Also, F# was there first, has very good support in IDEs, integration with core .NET, etc. I think Scala would have a rather hard time on CLR (I may be biased, I don't know Scala very much and I worked with OCaml long before F# happened).
IIRC, Scala.NET was basically killed by the fact that .NET reified generics and Scala's generics are pretty fundamentally incompatible, which means a .NET implementation of Scala would either not be very Scala or not have a good .NET interop story.
Why would you need Scala on .NET when you have F# and C# that are completely the same thing.
Scala integrates OOP and FP in a truly elegant way, F# is mostly FP with some OO bolted on it as an afterthought, and C# is much closer to Java than to Scala. You may argue whether Scala is really more expressive than F# (IMHO it is), but regardless of it, they are not the same thing.
F# doesn't have "OO bolted on it as an afterthought". Sure, F# strongly favors the FP approach to things, but the language's OO features are important -- critical, even. Without support for OO programming, F# wouldn't be able to easily consume existing .NET (C#, VB.NET, etc.) libraries, nor would you be able to use F# to implement components/libraries to be easy consumed by C#. The ease of interop'ing with C# is one of F#'s best features, IMO, and an important part of the wider adoption it's now seeing.
Neither F# nor C# are "completely the same thing" as Scala.
It supports Node.js or is only for web applications?
It supports Javascript. Node.Js runs on Javascript.
Draw your conclusions.
Draw your conclusions.
True, but its main target is definitely the browser. The stand-alone interpreter of Node.js can run code written in Scala.js, and is actually used for benchmarks (along with d8) [1]. However, Scala.js does not emit Node.js modules, nor does it provide any built-in way to import other Node.js modules.
[1] https://github.com/jonas/scalajs-benchmarks
[1] https://github.com/jonas/scalajs-benchmarks
So now it's Dart vs Scala. Great to have some good options.
I think it's Dart vs ClojureScript vs Scala.
You forgot about GWT.
You forgot typescript ,haxe,JSX, opal ,coffeescript and zillions of languages that compile to JS.
Or if you write webapplications (with emphasis on applications): Zk.
Is there anything Javascript can't do?
Javascript is obviously Turing-complete, so it is as powerful as any other language, and you can implement any other programming language on top of it.
The trick is not wasting too much performance while doing that. Fortunately Javascript performance is already not bad, and specific subsets like asm.js can have their performance optimized even further.
So your question is not unlike "what an x86 command set cannot do?", just for a 50-100x slower command set.
The trick is not wasting too much performance while doing that. Fortunately Javascript performance is already not bad, and specific subsets like asm.js can have their performance optimized even further.
So your question is not unlike "what an x86 command set cannot do?", just for a 50-100x slower command set.
Threads.
Not completely true, you already have WebWorkers, and if you're targeting, say, JavaScriptCore on iOS and OS X Mavericks then threads are an option via running multiple JS Virtual Machines - JSValues may be passed between them.
Precise numerics.
Type safety.
ints
They will be adding prefix notation next...
Fun stuff, but again, doesn't come with any tools. Microsoft Typescript is much better on that matter.
What javascript universe needs right now is not some more of syntactic sugar clusterfuck followed by debugging nightmare, but real tools, static code analysis. I don't want to waste my precious time dealing with closure compiler+scala something combo. It's fun from programmers POV, but still it won't make me pay my bills!
reality check, please
What javascript universe needs right now is not some more of syntactic sugar clusterfuck followed by debugging nightmare, but real tools, static code analysis. I don't want to waste my precious time dealing with closure compiler+scala something combo. It's fun from programmers POV, but still it won't make me pay my bills!
reality check, please
Have you looked into the tools and amenability of Scala to static analysis and found them lacking?
Also, it seems a bit odd to call Scala "syntactic sugar". It's a pretty unique language in its own right.
Also, it seems a bit odd to call Scala "syntactic sugar". It's a pretty unique language in its own right.
I suggest you RTFA, some highlights regarding your fears:
- Integrated with sbt (including support for dependency management and incremental compilation)
- Can be used with your favorite IDE for Scala
- Generates Source Maps for a smooth debugging experience (step through your Scala code from within your browser supporting source maps)
- Integrated with sbt (including support for dependency management and incremental compilation)
- Can be used with your favorite IDE for Scala
- Generates Source Maps for a smooth debugging experience (step through your Scala code from within your browser supporting source maps)
Scala is outside of reality, it's academic diarrhea.
It's nothing but syntactic sugar (more like salt) for Java's async functionality and we all know that anything made from shit is expected to be shit.
It's nothing but syntactic sugar (more like salt) for Java's async functionality and we all know that anything made from shit is expected to be shit.