As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm writing a webapp that uses websockets for updating vehicle positions on a google map and for exchanging messages with drivers in realtime. I've been playing around with Node.js as well as Tornado, but I've come to the conclusion that I'd prefer static typing for this project after all.
Two excellent choices seem to be Scala and Go, but I'm having a hard time deciding between those two. I've been mostly been programming in C/C++/C#/Python and have very little Java experience.
So how do those two compare? What would you learn next? I know this is subjective, but I'm kind of looking for some battle stories here. Also, what about the ecosystem? From what I can tell, Scala inherits Java's ecosystem, but what about Go?
The down side of Go - immature, with very little real world experience.
The down side of Scala - you must be familiar with the Java eco system in order to utilize scala well. You probably can't write everything in Scala. Also, some might find the learning curve for Scala higher.
Both supports websockets (Scala through Lift for instance, and Go in the standard library).
I believe that you'll be more comfortable with Go, since it's more similar to Python than Scala.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Which are mature, maintained and flexible open source genetic algorithm (GA) libraries for Scala?
Mature meaning that it is quite feature complete and bug free, ideally well documented.
Maintained meaning that it is not an abandoned project, and it works fine with current the current (2.10) Scala version.
Flexible meaning that it is fully configurable, I can plug in my own chromosome representations, fitness, breeding etc. functions, and it is generic and uses well Scala's type system.
Ideally on GitHub so it integrates best with my work flow.
If your main priority is maturity, I'd recommend JGAP, a library written in Java (which I used in my bachelor's with very successful results).
Using the natural interoperability between Java and Scala, there shouldn't be any problems about that. (But sure it would be great to see a Scala equivalent to it in terms of maturity and flexibility, taking advantage of Scala idioms)
About being maintained, it has not released new versions since 2009.
Sure there are other implementations out there but just wanted to add my 2ยข about a library I would sure revisit when the need comes (even if it is to start a port).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have heard that Play Framework 2 will go to use spray instead of netty. Spray itself believes that
"The recent trend of moving web application logic more and more away
from the server and into the (JS-based) browser client as well as the
increasing availability of good SBT-plugins for things spray itself
does not provide (like view-templating or LESS- and
CoffeeScript-Support) "
Does it mean that playframework will be using javascript MV* by default instead of scala template?
The philosophic point of scala - to provide a scalable (unique) language for big range of use-cases - like web-services, logic, web. But WEB itself goes very close with Javascript and HTML and frameworks around it.
People tend to save processors time (money) on its cloud boxes, and would probably choose to use client-side computation vs server side, when it's possible.
That's the background of this question - where the Play Framework goes about it?
Should it use scala that would compile to javascript (for example)?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Is Scala a good choice to implement a well scalable MMORPG? I read about people suggesting Erlang, because better concurrency handling. But Scala has actors/message driven concurrency and functional programming. Should not that handle the concurrency and scaling also well?
Sorry I don't know Erlang and also don't have experience with Scala neither MMORPG development. That's why I can't make the question more concrete yet. I'm looking for the best way to go to develop an easily scalable MMORPG. And think Scala maybe is/could be a good choice.
Scala is fine for a MMORPG, but it doesn't necessarily have existing frameworks that are available for other platforms (especially C++). Erlang's fault-tolerance and scalability are legendary, but if you use the Akka framework you'll have a comparable set of capabilities (for the most part).
One advantage to using Scala is that you can take advantage of Project Darkstar, a Java-based platform for MMORPG creation. Here's an example of it being used, though I'm not sure it's actively maintained any more.
Scala actors (consider akka) are actually influenced by erlang. This is highly subjective, but I believe actor model is a great fit for mmorpg.
I guess the overall architecture would involve actor per character/NPC - Akka is perfectly capable of handling millions of actors in a cluster. Oh, did I mention Akka 2.0 can be easily distributed?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'd like to start programming in Scheme but the variety of different implementations is confusing. What are some advantages or disadvantages of various implementations?
Every implementation tends to focus on something different. Racket emphasizes its large libraries as "batteries included", while Ikarus Scheme touts itself as compiling fast code. You should examine implementations based on what you want. If you're just learning Scheme, DrRacket is a good choice with its friendly interface and specific environments for various Scheme books.
Also, you probably don't need to find a R6RS implementation, when most implementations target R5RS and most textbooks were written for R5RS and earlier.
Since you're looking to learn Scheme, I recommend The Little Schemer as an introduction to thinking using Scheme's lists and recursion.
Honestly, while each one has their own quirks and modifications to the standard, they're mostly the same. The biggest differences is how it compiles. You should probably just pick one and go with it.
Racket would be a good choice because it comes with a nice debugging IDE and is easy to set up.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
The FAQ for the new Go language explicitly makes this claim:
There is a growing rebellion against cumbersome type systems like those of Java and C++, pushing people towards dynamically typed languages such as Python and JavaScript.
Is there (non-anecdotal) data to actually support such a claim? I've always found dynamic typing sloppy and tiresome, but if I'm losing touch I at least want some warning.
I'd call it a trend, not a rebellion, but I see the same in our company moving from C (25 years ago) over C++(20 years) and java (12 years) to javascript and python (2 years).
One of the reasons could be, that scripting seems to be more agile and better for rapid development (which I actually doubt). That impression came along when some developers started nice applications in impressive development speed, while the 'old OO-family' often came up with (over-)complicated application architectures which showed a depressing progress.
I think it doesn't has to be scripted if time to market is a criterion (but sometimes it helps to get rid of old habits)
I agree with kai1968, it is more of a trend. Here is a good paper done by IEEE that will give you a better understanding Developers Shift to Dynamic Programming Languages