3 ms·
> 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 ..
by smegel 13y ago
> 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 13y agoI found the continuations, and they are actually pretty nice. https://news.ycombinator.com/item?id=6125567 https://news.ycombinator.com/item?id=6125567 http://jim-mcbeath.blogspot.com/2010/08/delimited-continuations.html http://jim-mcbeath.blogspot.com/2010/08/delimited-continuati... https://github.com/jimmc/scoroutine 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 13y ago// 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?