Will it be open source? I would be happy to contribute (I work full-time with Scala).
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.
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 =)
While such an early release is definitely aimed at scala enthusiast, I'd still like a sales pitch for the rest of us.
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.
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.
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.
And yes, action composition is how we handle authentication. ;)
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.
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
Why? Akka works fine with Java, Kotlin, and most other JVM languages.
Being a discussion forum, I don't see why you have a problem giving away knowledge freely over HN.
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.
We use Argonaut at Snowplow.
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.
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.
 For the record, I'm not complaining. The alternative would be a nightmare to deal with.
 Though they do sometimes return a different object altogether; this is an issue regardless of which type system you use.
> 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.
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.
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.
Scala has Dynamic types for when you want to play rough like that.
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.
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).
I left C# to do Java, Java is a step up from C#.
I miss many things from Scala in comparison, but C# has some good features that almost make up for it.
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.
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.
I'm not saying it's a good idea, but there's a use case there.
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).
Draw your conclusions.
So your question is not unlike "what an x86 command set cannot do?", just for a 50-100x slower command set.
It's fun from programmers POV, but still it won't make me pay my bills!
reality check, please
Also, it seems a bit odd to call Scala "syntactic sugar". It's a pretty unique language in its own right.
- 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)
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.