[happy_dino]

> [...] then it would be a different matter entirely

Have fun moving the goal posts around.

> Java was created in the mid-90s before every man and his dog was trying to solve the c10k problem on a $5/month VPS. Hardly surprising.

So what? C10k isn't a hard thing to do on the JVM and it probably beats Go by a large margin in terms of latency and performance.

> Why do you think Scala has both blocking, and "event based" (loop/react) API's?

Your point is ...? There are plenty of different libraries, because concurrency can be tackled in different ways. Use the right tool for the job. Unlike in Go, where you pretty much have to shoe-horn everything into “goroutines” or channels.

The lack of developers which run around and try to tell everyone that they found the silver bullet for solving concurrency in Scala is a sign of a mature community which has experience and expertise and doesn't just repeat whatever Rob Pike says like Go users seem to do all day long.

> Quite possibly, you must have been living under a rock if you haven't heard of callback hell in Node.js.

Eh ... so what? It's not like Node's terrible approach is the only alternative to Go's approach. Claiming “A is the best, because B is even worse” just shows a complete lack of knowledge of existing solutions.

> What is lacks (my original comment) is the ability to write event-based code using a synchronous, blocking style (without callbacks).

Again: No it doesn't. Do your research instead of claiming blatantly false things.

[smegel]

> So what? C10k isn't a hard thing to do on the JVM

It is using the traditional threading model, which is all it had before NIO came along.

> Your point is ...?

My point is if Scala's synchronous API was compatible/built on an event based system or green threads, then the far less attractive callback based API would not exist. Just like Go doesn't have callbacks...what would be the point?

> Use the right tool for the job.

Go doesn't claim to be good at everything. If you want great traditional multi-threading then by all means use Java. If you want a highly-scalable network engine with code that doesn't look like spaghetti, use Go.

> The lack of developers which run around and try to tell everyone that they found the silver bullet for solving concurrency in Scala is a sign of a mature community

I don't don't hear many Java programmers running around complaining about hand-editing reams of XML either...I still don't envy them.

> Claiming “A is the best, because B is even worse” just shows a complete lack of knowledge of existing solutions.

I don't think Go is "best", and I already gave you examples of other synchronous, event-based languages (you still haven't shown me an example in Java/Scala). I actually prefer Python/Gevent for most things.

> Do your research instead of claiming blatantly false things.

Well I think the onus is on you to provide some evidence to back up your claims.

[anonymoushn]

I found the continuations, and they are actually pretty nice.

https://news.ycombinator.com/item?id=6125567

http://jim-mcbeath.blogspot.com/2010/08/delimited-continuati...

https://github.com/jimmc/scoroutine - some of the examples in this are godawful, but you'll find that they still work if you rewrite them to be legible.

[happy_dino]

  // Some example methods which might spend waiting for other
  // services (calling the database, sending emails).

  def getEMailForUsername(username: String) =
    future { DB.Users.find(_.name == username).get.email }

  def sendPassordRecoveryMail(email: EMail, message: String) =
    future { SMTPService.send(email, message) }

  // Future/Promises API:
  def resetPassword(username: String) =
    for {
      email <- getEMailForUsername(username)
      result <- sendPassordRecoveryMail(email, "some message")
    } yield result


  // Async API:
  def resetPassword(username: String) =
    async {
      val email = getEMailForUsername(username)
      val result = sendPassordRecoveryMail(email, "some message")
      await(result)
    }

@smegel: I don't see any “callback hell” or “code that does look like spaghetti” here. By the way, I'd love to see a link to “Scala's synchronous API” and that mystical “far less attractive callback based API”. Or are you making things up again?