> No it doesn't use magic, but it does take a language that is burdened with a complex type system and throws it out the window.

What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it.

> You also are glossing over a huge host of complexity around build/deployment. What jvm are you targeting? Is it on the servers you are deploying to? Are you going to make a fat jar? If not, how are you doing dependency resolution? Is your build artifact something that sbt does out of the box or slightly different (lord help you if it is)? Are you going to do ivy, s3, or maven resolution?

If you're just playing around, you push the button in your IDE and it runs. If you're a serious business you make these decisions once and reuse them in every project. (To answer your questions explicitly: the default is to build for java 1.6, which has been on servers since before go even existed; if you're building for a newer version it's because you know what you're doing. My personal choice would be the maven appassembler plugin, but using the shade plugin to make a fat jar works fine too. I wouldn't touch SBT, it's too complex).

Yes, you do have to make some choices, put a bit of effort into deployment. But I think that's a necessary cost, because it's the only way to allow tooling to evolve. Imagine if ant had been built into the JVM back in 2000; maven would never have been able to replace it, so we'd be stuck with it forever. Look at the Python standard library; when Python first got big, it was this great selling point full of really useful tools. Now, it's where modules go to die, because things that are built into the language can't evolve at the same place as things that are outside it. I fear exactly the same thing will happen to the Go tooling (though of course, we won't know one way or the other for ten years). If I can think of one language that really emphasised an "easy deployment model", it's PHP. Not only did that approach lead to terrible deployment practices, but now that the landscape has shifted and Apache is no longer universal the way it once was, it's not even particularly easy to deploy PHP any more.

> What are you talking about? Spray works hand-in-glove with the Scala type system; would, in fact, be impossible in a language without it.

In the example you linked to: https://github.com/spray/spray/blob/release/1.1/examples/spr...

The "main" function dispatch is not type safe (nor can it be given Spray's reliance on the current akka type model).

My experience is that anything that relies on akka ends up throwing out a huge majority of useful type safety because it is hard to minimize it. A bunch of the advantages you mention around AOP and not monkey patching are due to this.

Ah, my bad. https://github.com/spray/spray/tree/release/1.1/examples/spr... (or even https://github.com/spray/spray/blob/release/1.1/examples/spr... if you want the very simple case) are better examples, that use the lovely type-safe routing DSL.