8 ms·
Announcing Scala.js v0.1
- leokun 13y agoI 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?
- jakozaur 13y agoParsing JSON in Scala is very easy with lift-json: https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/ https://github.com/lift/lift/tree/master/framework/lift-base...
- smenko 13y agoIs this supposed to be ironic? Considering JSON.parse( {a: "B"} )
- chimeracoder 13y agoJSON 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 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.
- leokun 13y agoGiven 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.
- chimeracoder 13y ago> 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.
- leokun 13y ago> 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.
- mnutt 13y agoIncidentally, 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.
- saryant 13y agoThere'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 http://www.playframework.com/documentation/2.2.x/ScalaJson https://github.com/spray/spray-json https://github.com/spray/spray-json
- interstitial 13y agoWell, damn it, now I have to bookmark this thread.
- leokun 13y agoI use argonaut.io and it isn't really hard so much as tedius compared to JavaScript or Python.
- alexatkeplar 13y agoLots of options, see the complete list here: http://stackoverflow.com/a/14442630 http://stackoverflow.com/a/14442630 We use Argonaut at Snowplow.
- auggierose 13y agoYou can just use the Javascript Api's for that. So the answer would be incredibly easy.
- tree_of_item 13y agoIt's exactly the same as in JavaScript: JSON.parse(...) Scala has Dynamic types for when you want to play rough like that.
- jakozaur 13y agoFor those who haven't heard about it. The initial presentation: http://www.parleys.com/play/51c380bfe4b0ed8770356866/ http://www.parleys.com/play/51c380bfe4b0ed8770356866/
- auggierose 13y agoThis 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 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).
- drewhk 13y agoWow! 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).
- modersky 13y agoIt is open source. I am sure the committers would be happy to get additional help.
- saosebastiao 13y agoI 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.
- SkyMarshal 13y agoIndeed. 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.
- ghostdiver 13y agoFun 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
- chc 13y agoHave 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.
- fhd2 13y agoI 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)
- anotherfadjs 13y agoScala 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.
- krisajenkins 13y agoAnyone know how the compilation times compare with regular Scala?
- acjohnson55 13y agoScala'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.
- chris_overseas 13y agoTake a look at Kotlin (http://kotlin.jetbrains.org http://kotlin.jetbrains.org), it was designed to address the issues you mention.
- acjohnson55 13y agoFascinating, thanks! For anyone else interested, I found this to be useful: http://confluence.jetbrains.com/display/Kotlin/Comparison+to+Scala http://confluence.jetbrains.com/display/Kotlin/Comparison+to...
- humpty44 13y agoKotlin seems like a lightly stripped down Scala.
- pkolaczk 13y agoLightly? 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.
- julianduque 13y agoIt supports Node.js or is only for web applications?
- romanovcode 13y agoIt supports Javascript. Node.Js runs on Javascript. Draw your conclusions.
- sjrd 13y agoTrue, 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 https://github.com/jonas/scalajs-benchmarks
- memracom 13y agoToo 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.
- seanmcdirmid 13y agoI 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).
- jebblue 13y ago>> 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#.
- seanmcdirmid 13y agoHow 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.
- profquail 13y agoWhat 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/ http://funscript.info/ FunScript also provides a way to do strongly-typed interop with TypeScript, via F#'s type providers.
- lihaoyi 13y agoFun demos using Scala.js: http://lihaoyi.github.io/scala-js-games/ http://lihaoyi.github.io/scala-js-games/ http://lihaoyi.github.io/scala-js-game-2/ 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 =)
- wodenokoto 13y agoAs 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.
- fhd2 13y agoYou'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.
- acjohnson55 13y agoI'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.
- antoinec 13y agoAnyway, the answer of his questions has definitely its place in this thread, so it's a good thing that someone is asking it.
- zschuessler 13y agoThis 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.
- acjohnson55 13y agoI'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?"
- dysoco 13y agoI 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?
- tkellogg 13y agoI 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.
- swannodette 13y agoNote 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.
- jkrems 13y agoI 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.
- ismail 13y agoRemember to write the slidedbread.js in under 30 lines :)
- ShardPhoenix 13y agoThis 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.
- macmac 13y agoThey will be adding prefix notation next...
- coldcode 13y agoIs there anything Javascript can't do?
- nine_k 13y agoJavascript 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.
- nickbarnwell 13y agoThreads.
- technomancy 13y agoPrecise numerics.
- swannodette 13y agoNot 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.
- efnx 13y agoType safety.
- peq 13y agoints
- myth_drannon 13y agoSo now it's Dart vs Scala. Great to have some good options.
- jroseattle 13y agoI'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.
- deleted 13y ago[deleted]