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'm considering writing an app that has the following requirements. I'm proficient with Ruby, but I'm willing to learn a new language like Scala, Clojure or Python.
Concurrency / Best performance
This is my main goal. It needs to be amazingly fast and support concurrency in a decent way.
Use Redis as a back-end
This won't be a big problem, redis has a wide range of drivers available, but it may influence the final decision on a language/platform.
Websockets support
Good support for websockets is a must. Using an add-on library (like Cramp for Ruby::EM) is okay.
Options
I've gathered the following options:
Ruby EventMachine
Python Twisted
Node.js
Clojure
Scala
Java
Writing raw C or assembler are not viable options at this time.
Concurrency
Ruby 1.9 still uses the GIL, where as all JVM based solutions can use native threads. I'm not sure about Node.js in this case.
How does the selected language affect performance?
The question
What do you recommend and why? Do you have hands-on experience? Please enlighten me (and the rest of StackOverflow)
Clojure is about twice as fast as node.js, which is about three times faster than Python which is held to be faster than ruby.
I'd vote for Clojure if high performance concurrency is your main criteria. Clojure was basically designed for concurrent development from the beginning, and there have been some impressive Clojure demos running on 800+ core Azul boxes.
It is very much worth looking at this video presentation to understand Clojure's approach to concurrency:
http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
The main trick in Clojure's concurrency performance is a clever implementation of Software Transactional Memory (STM) that lets you conduct many concurrent transactions without complex and expensive locking schemes. It also uses persistent data structures to give immutability and efficient management of multiple versions of data. It's very cool.
As for general purpose performance, Clojure is pretty fast already and getting even faster with the new 1.3 alpha branch. A stated aim of Rich Hickey (Clojure's creator) is to allow you to do anything in Clojure with the same speed that you can do it pure Java.
Other things in Clojure that I really like but may or may not be relevant to you:
Hugely powerful LISP-style macro system - "code is data" and you can manipulate it as such
It's a fully fledged functional language
It's dynamically typed by default (for flexibility and quick prototyping), but you can add static type hints if you need to (for better performance)
Excellent JVM / Java integration, so you can make use of all the good Java libraries and tools out there (e.g. Netty for event-driven server communications)
On Clojure you could use Grizzly for async http processing and comet/websockets based apps.
Redis is a great choice to cache and create a powerful distributed session with pub/sub protocol built-in
Another big thing is use RabbitMQ or ZeroMQ to simulate a agent based distributed system and provide group, data or integration services for example.
Is relative ... a like clojure a lot and agree in parts with you , where clojure is one of the fastest language on jvm .
But the knowledge on language is essential and could confirm our feeling.
Some interesting links on benchmarks , performance and comparisons :
http://bit.ly/dtqHAG
"Premature optimization is the root of all evil", by Donald Knuth
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 10 years ago.
What language, between Go and Rust, would you use to create a library for games (no bindings)?
Go is a simpler language that leans more heavily on garbage collection. Rust is a more complex language that can be safely used without the GC at all which is perfect for low-level systems programming.
I'm biased since I spent two summers working on Rust, but if you're willing to invest the necessary time to keep up with a rapidly changing language, Rust would be really good for games. It has a really nice set of built in concurrency primitives, so it would be easy to separate the different components such as the rendering engine, the AI, etc. and take advantage of multicore computers. It's also possible to avoid the need for garbage collection, so you don't have to worry about unpredictable GC pauses. It's designed to integrate nicely with existing C code, and many of the data types map directly onto C types. Rust's approach to polymorphism leads to some really nice assembly once LLVM is done with it.
Many games nowadays are running in the web browser, which suggests that web browsers and games have similar requirements. Mozilla is designing Rust alongside its new parallel browser engine, which means the language will continue to evolve in ways that would work well for game programming too.
Rust: This is alpha-level software with many known bugs, incomplete features and planned future changes. Use at your own risk, expect some instability, disruption and source-level incompatibility for a while yet.
No good for commercial game.
You can't make library with Go for games at all. There is no support to create library in Go. With Go you can create mobule(library) that you will use only with Go.
You can use C++ library in Go. But you can't use Go lib in C++.
You may ask what language is better for games Rust or Go.
UPDATE 2015 year
Go 1.4 has office/beta support for Android and Go 1.5 (2015 Summer) will have iOS support.
Right now it is tricky to build for android. You have to install docker image
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'm designing a game, but this question is applicable to any situation that requires bidirectional communication between nodes in a cluster and a main server. I am pretty new to clusters, but I actively program in Go and occasionally in D.
I really want to use a modern language (not C/C++), so I've chosen these two languages because:
Array slices
Good concurrency support
Cross platform & compiles natively (with multiple compiler implementations)
GC (both working on a precise GC)
I've read https://stackoverflow.com/questions/3554956/d-versus-go-comparison and The D Programming Language for Game Development.
At a high level, my game will do most of the processing server side, with the client just rendering the game state from their perspective. The game is designed to scale, so it will need to act in a cluster. Components are mostly CPU bound, and update to a main server asynchronously, which shares game state with clients. Most computation depends on user input, so these events need to be sent down to individual components (hence bi-directional RPC).
Reasons I like D:
Manual memory management
Templates/CTFE
Code safety (#safe, contracts, in/out)
Reasons I like Go:
Standard library (pprof, RPC)
Go routines
go tool (esp. go get -u to install/update remote dependencies)
The client will likely be written in D, but that shouldn't have an impact on the server.
I am leaning towards D because manual memory management is baked into the language. While it doesn't have the nice libraries for RPC, I could theoretically implement that, but I cannot as elegantly implement manual memory management in Go.
Which would you use for this problem given the choice between the two languages?
I expect that either will work and that a lot of it depends on which you prefer, though if you're doing the client in D, I'd advise doing the server in D simply because then there are fewer languages involved. If you use two languages, then anyone working on your project generally has to know them both, and both Go and D are small enough in terms of their user base at this point that few people will know both - though if it's just you working on it, you obviously know both of them already.
However, I would point out that if the problem with using D is the lack of an RPC library, then that isn't a problem, because D is supported by Apache Thrift. So, D does have a solid RPC library, even if it's not in its standard library (in fact, it was one of the fruits of D's first round of participation in Google's Summer of Code).
I do not know anything about your game, If good concurrency for your server is important then I vote for Go.
I developed communication server in Go that implements communication with PUSH technology. Go is great in for such tasks. Compact clean code that is easy to understand.
Automated memory is important in concurrent apps.
Client apps are not so concurrent like server apps.
Client apps should keep constantly high frame rate.
So manual memory management without global GC locks are better for client apps.
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'm looking for a tool that will allow me to test a Rails-based JSON web service. LoadRunner would fit my needs, but I need a free solution.
JMeter is free and scriptable, you should have a look.
What is your virtual user need? Some of the commercial tools offer no cost versions at a limited load level, so before addressing your need I am looking for more specifics on the virtual user number requirements.
For clarification, are you looking for a tool which can produce a ACM/IEEE definition stress test from a scheduler perspective? This would be a test which increases in load by a defined interval every ~n~ seconds|minutes|hours until the system collapses or a particular metric is achieved, such as response time exceeds SLA value by 250% for five minutes or CPU is greater than 90% for 45 seconds, etc.... Schedulers are all over the map in the tools space, some are better than others when it comes to Stress, most work equally well for a defined load level.
How does monitoring fit into your tool model? Are there specific architectural components which you would like to monitor which would drive a tool? This will help you identify system bottlenecks in the use of resources on architectural components.
What about your team skills? You mention scripting, but how much are you expecting the tool to handle for you. Some of the open source tools are great, but they mandate that a person be a highly skilled developer to get the most out of the tool. The commercial side rounds some of the edges off of the tools, but in general you are still going to need to be proficient in the language of the tool. If you need Python, that takes you one path, Java another, VB a third, Pascal a fourth, C a fifth, etc.... Sometimes its easier to document what languages you know and know well and concentrate on tools that fit that model as trying to learn a new tool and a new language at the same time rarely yields benefits.
Have a look to AgileLoad it is free for small test and provide both recording and advanced scipting features. It is compatible with JSon service. It is quite easy to use, there is also tutorials and video on how to use the tool on the website. Support is free and the support team can helps you with scripting process.
I'd also take a look at The Grinder. It has a nice feature where you can create your load script by recording your browser activity.
There is a version of Load Tester that is free and has no limits on the number of virtual users you can run: Load Tester LITE.
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 have been advocating using Scala at my company. One of my co-workers forwarded me this link tonight
http://blog.joda.org/2011/11/real-life-scala-feedback-from-yammer.html
I was hoping to get some constructive feedback from the SO community about this. I don't want this to turn into a flaming thread, but if there are legitimate concerns floating around out there I think it would be beneficial to discuss possible reasons and best practices that can avoid others falling into such traps.
I will say that I have been loving Scala and have not run into any of the problems that are mentioned. My application is also not very hashmap intensive, which appears to be where a fair number of their problems came from.
[Edit - apparently I need a question!]
The question is, do you think that the problems described are systemic to Scala, or more unique to their environment? If they are systemic, are there some good guidelines for a company that is just getting started with Scala to follow so that they don't end up in the same boat in 2 years?
Issues Described
Language Complexity
Systemic issue. Scala is unlikely to get less complex, whether or not that is a problem depends on the developers that are working with it. For me, it is complex enough to keep me interested and engaged, whereas pure Java can be mind-numbingly boring. My suspicion is that if Scala is way too complex for a particular developer, it is unlikely they're going to be top-notch dev when it comes to Java as well.
Community
So this one guy says the only way to do this is with a bijective map
on a semi-algebra, whatever the hell that is, and this other guy says
to use a library which doesn't have docs and didn't exist until last
week and that he wrote. The first guy and the second guy seem to hate
each other. What's the Scala way of sending an HTTP request to a
server?
That quote is pretty funny, but this is obviously a non-systemic issue with Scala. His main complaint about a lack of consensus regarding best-practices is relevant to all up-and-coming languages. I think Java developers have been spoiled in a way -- having gotten used to being part of such an enormous community where pretty much everything has been done before and possibly already standardized.
Build Toolchain
Another non-systemic issue.
Performance
This one does worry me a little bit and I can see getting frustrated very fast having to uncover previously unknown performance gotchas. I suspect for years to come there will be some pretty big performance penalties depending on how you use certain aspects of the language -- so people will have to exercise caution and make their own analysis regarding each project's performance requirements.
I concur with his sentiments here:
Despite the fact that we're moving away from Scala, I still think it's
one of the most interesting, innovative, and exciting languages I've
used...
And finally I would urge people to read Stephen Colebourne's blog with some degree of skepticism, because his personal disdain for the Scala language seems a bit oversize relative to the arguments.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm part of a group that starts a new development project from scratch.
Currently it is on hobby-basis but we aim to make it our living
in the time frame of 1-2 years.
We are senior developers coming from a multitude of languages and techniques
with much of the focus on Java for the last few years.
Now, we're thinking of choice of toolsets and languages (the future is
bright when starting from scratch).
We want to be able to use modern architectures efficiently and have
good experience in Java and other JRE-based techniques.
The project is in short a lot of I/O, databases and a decent UI that probably
needs to be web-based and feel quite efficient.
One route to go is classic Java and build UI using GWT (or layers on top of GWT),
another is Scala + lift.
Then there are other techniques based on Ruby, Groovy and so on.
My question is then: What would you select as tools for a new long-term
project given the above. Is Scala here to stay for instance or is one
of those with only temporary hype?
What other techniques do you consider for larger projects from scratch?
Possibly your biggest binary choice is whether you decide to stay on the Java Virtual Machine (JVM) via either Java or one of the other languages which compile into bytecode, or to move onto some other platform, possibly Ruby or Python (with the complications of working with different architectures/operating systems that this may entail). Personally, I decided that I very much wanted to stick with the JVM and hence your language choices would be...
Scala
All I can give is my own experiences coming from a Java background: migrating to scala was made easy by its natural integration into the Java ecosystem and the ability to continue to use pretty much the same toolset in the same way.
By this last point I mean that the statically-typed nature of scala means that all the refactoring and code-navigation opportunities are still available to the developer but scala's type inference means that this comes without the unnecessary verbosity of type declarations littered throughout your code.
I can still use my favourite stuff like Spring, ant, IDEA and I can still use all the libraries I've ever written in Java (this is an argument for picking a language which integrates with Java over a completely new one like Ruby, Smalltalk or Python).
From the perspective of whether scala is here to stay as a JVM language, this is what concerned me most. But consider how many questions on SO have been tagged Jython (161), JRuby (176), clojure (388) and Groovy (661), assuming you wish to stay on the JVM. Not only is scala now well ahead of these (815) but it is growing at quite a rate.
Lastly, although I have not used Lift, a colleague has been extremely impressed with it (and I would probably look at it if I were writing a web application). The fat-client alternative (scala swing) I have found to be more than useable (better than raw swing at any rate!).
Groovy
It's worth noting that the creator of Groovy recently said that had he known of the existence of Scala, he would never have bothered to create Groovy!
JRuby / Jython
I have lumped these two languages together because they both represent an attempt to port the syntax of a dynamic language onto the JVM. Unless that syntax is already familiar to you, why would you bother to go down this route? I must say, the SO stats (above) do not indicate that these have the momentum at the moment.
I would also opine that moving from a statically-compiled to a dynamic language is a big step and you might be surprised by what you miss (in terms of refactoring and development aides etc.) - you may also care about the fact that the interpreted nature of these languages makes them over an order of magnitude slower than Scala.
Clojure
I have no real opinions on clojure other than to say that with an imperative background, its syntax is scary and its flow extremely unfamiliar. I am becoming more impressed by the functional paradigm but I felt that clojure was a step too far for me; I would be a fish out of water in the language, having no previous experience of LISP/Scheme.
The choice of language implies a lot of other choices, which collectively can be more important than the language choice itself. More specifically, when you choose a language, you're also choosing that language's web framework, ORM, IDE, build tool, etc.
For example, if you choose Groovy, you're implicitly also choosing the Grails web framework, if you choose Scala you're choosing Lift, etc. Although you can use Eclipse/Netbeans/IntelliJ for almost any JVM language, the experience varies quite a bit depending on which language you're using. Eclipse is a great IDE for Java development, but a pretty crappy one for Groovy/Grails development.
The problem with this kind of question is that if you ask a guy who uses language X, he'll tell you to choose X, then list all the reasons why X is so great and a few shallow reasons not to use the other languages. Examples of such shallow criticisms include:
Scala
poor tool support
functional programming is esoteric to typical OO developers
Groovy
dynamic languages are unsuitable for large projects
dynamic languages perform poorly
Jython
whitespace indendation as code block delimiters sucks
dynamic langages (see above)
JRuby
reputation for bad performance
funky syntax (from the POV of a Java developer, at least)
Clojure
very funky syntax (from the POV of almost everyone)
very immature
I should emphasise that I don't necessarily believe any of the statements above to be true,
the point I'm trying to make is that it's very easy to dismiss languages without any real experience of them (I only really know one of the languages above). So I wouldn't put too much faith in what people say against a particular language, unless you're sure they've really used it.
If I was faced with your choice I would use Groovy/Grails, because I find it to be an extremely productive and enjoyable technology to work with for building web apps, with good tool support. Are there other choices that might be even better? Sure, but Groovy/Grails is good enough for me (for now).
If you all have strong Java background and no functional and/or dynamic languages background, then you are likely to do well by keeping to Java or migrating to Scala.
I don't mean to disparage any of the other languages here, but Scala will be more familiar to you, and you can put your Java familiarity to good use. Whether you should jump to Scala or not -- that's another question. If you do, however, take notice that you need not be stuck with Lift. Not only there are other web frameworks in Scala, but people have had success combining Scala with traditional Java frameworks such as Wicket.
I worked a lot with Scala, Groovy and JRuby and I can share my experience
Scala
This language was designed in a very in a professional way. You can see it in every aspect of it.
No performance issues because it is a static typed language.
Interesting to learn and play with because of its functional nature.
BUT:
It is very complicated. You can't spend an evening to write a hello world program. You should spend at least a weekend)) Dmitry Jemerov (one of the creators of IntelliJ) said that Scala is much more complex than C++.
Lack of a good tool support. I believe that IDEs for Groovy and Ruby is much superior.
Not well integrated into java ecosystem. Of course you can use java libraries but you will dance a lot of all conversions from one collection to another e.t.c.
Lack of pure Scala libs. You always have to write a small wrapper over a java lib.
Groovy
Has shortcuts for most java boilerplate code.
Great IDE integration.
Interactions with Java are so natural and easy. It is not important whether you use a java class or a groovy class, it just works.
Great for writing DSLs
BUT:
It is a slow language (But I think that it is not an issue in most cases)
As the integration with java is the main goal of Groovy there are some unnatural aspects of the language.
JRuby
One of the best designed languages I've ever seen.
There are a lot of cool libs that can be used.
The best language for writing internal DSLs
Easy to learn.
BUT:
The integration with java sucks.
In my opinion it is too early to use Scala in production systems. It is just too hard because of the lack of tools and libraries. I used Groovy in many big projects quite successfully so it may be the best tool from these 3 languages.
With the information given you can choose any language proposed. They will all still be here in 5 years.
If you cannot decide which tool to pick for your requirements we can't help you. The information given is just to vague to decide. Start building some prototypes for all language/framework and see what fits best. Maybe the requirements are more clear afterwards.
Have you tried Jython -- Python working on JVM? I use it quite often to do various database tasks and it works quite well with such databases as Oracle, PostgreSQL and Informix. I do not create classic UI apps, but I have read that well known Python Web frameworks like web2py or django work with Jython.
If you have experience using dynamic languages, and are able to write the unit tests to support them, go that way. The development speed should be greater than what you can achieve from a static language. However, as the project will get bigger, it may become harder & harder to mantain ( it may only be me, but compile time checks help you a great deal ).
If however, you have Scala experience, I'd choose that instead. I find Scala to be a nice mix between Java and Ruby.
Good luck!