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.
since concurrent programming becomes constantly more important, I was wondering
what you think about Erlang vs. Scala in that respect. It seems to me that Scala
has a larger user base and potentially a brighter future than Erlang. Furthermore,
Scala is kind of java.
I know these questions are alway a bit subjective, but what would be the better
future investment: Erlang or Scala. Or even another language?
Erlang has been designed for concurrent, fault-tolerant communication systems. You can easily write servers that handle large number of network connections and (thanks to one garbage collector per Erlang process) the servers can retain soft real-time characteristics (i.e., the whole server is not paused until GC finishes). You can also hot-swap Erlang code, distribute it across several nodes, etc. That's why (arguably) the most-scalable XMPP server (ejabberd) is written in Erlang. Yaws (a web server) is another example where Erlang excels, see: http://www.sics.se/~joe/apachevsyaws.html. Riak/Couch are examples of NoSQL DB build with Erlang. These are the problems where Erlang is a great choice.
But Erlang VM is not as fast as JVM in terms of raw computations, so as soon as you need to do something computationally intensive (e.g. financial modeling) JVM will be your preferred platform. Moreover, Erlang's concurrency model (actors) is baked in the language. If that doesn't fit the problem you're trying to solve, then you won't be happy with Erlang.
Scala is more 'general' language in a sense that concurrency, horizontal scalability, or fault-tolerance is not part of the language. It is solved at the level of libraries (that's why there are at least 3 implementations of actors in Scala). The good thing is that you can pick concurrency model that fits your domain. For example if you need software transactional memory (STM), just pick Akka and you're good to go (http://akka.io/).
Plus there is the whole argument that with Scala you can leverage your "JVM investments" and multitude of JVM libs.
You didn't give any info on what kind of software you want to write with either of those languages so it's hard to give you a definitive answer. Having said that, given all the above, Scala may be "safer" investment than Erlang (not bashing Erlang/OTP at all, it's a fine language/platform).
BTW. If a single-machine concurrency is important to you Clojure (http://clojure.org/) should not be overlooked (also JVM language).
UPDATE1: If you like what Erlang offers but not its syntax, take a look at elixir-lang.org
UPDATE2: STM has been removed from Akka - now you have a choice (mix/match) between actors (untyped or typed) and streams.
It doesn't matter Just pick one and stick with it for a while. Learn some stuff, make some cool things and either keep going with that language or move on to another one.
With respect to learning concurrent programming, either will be fine. The key here is that you will be learning something new and unless there's a job opening that you are trying to get hired for that uses Erlang specifically, it really doesn't matter. Plus, even if that opening did require Erlang, you would still likely have a good chance if you knew Scala really well.
Just think, all of the time you have spent trying to pick a new language could have been better spent if you just picked one and already started learning it by now.
Both languages, at the core, are not that hard to learn, and also to learn the concurrency features they provide. In fact, Scala actors are influenced by Erlang actors. I would go to both of them, take your time looking at their construct, do some tests in concurrency problems, etc.
If you know Java, Scala will be more natural, as Erlang is more like prolog. If, on the contrary, you're more oriented towards mathematical or logical type of languages, start with Erlang.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
Question
Can anyone recommend a library for Ocaml that offers an actor-based concurrency model for distributed computing?
Note here the "actor-based" and "distributed" - I'd like the actor-based model, but also I want seamless handling of distributed actors - I don't want to write the protocol to talk to them. The library should ideally also offer standard patterns such a supervisor trees and so on.
Motivation
I love Erlang concurrency model and ability to transparently deal with distributed processes and local processes together. However, I find Erlang's syntax to be rather limiting and would like a much more expressive language. I'm considering moving from Erlang to either Scala or Ocaml.
I know Scala has the Akka library which seems to offer a nice Scala version of Erlang's concurrency model. I'd like to see what is available on the Ocaml side.
Aside
I'd also be happy to hear about actor-based concurrency libraries for other languages (particularly C++, Haskell, Python and Ruby).
While it may not be the exact same model that Erlang uses, you might want to take a look at JoCaml, which is based on the join calculus.
You can take a look at parvel -- message passing library/framework for ocaml. It's not yet complete, but already includes some primitives for programming with actors.
"I'm considering moving from Erlang to either Scala or Ocaml."
You should consider scalang, which allows you to program in Scala, but use Erlang's actors.
I recently saw a talk on the language by #moonpolysoft (Cliff Moon) at the Strange Loop conference. Cliff Moon developed it for https://boundary.com/ and open-sourced it earlier this year.
You'll probably spend a lot of time reading about:
Scala and F# have akka and MailboxProcessor which are being used in production apps (note: Scala actors and, I think, akka, are very tied to Hotspot; I'm not sure if MailboxProcessor can be used under MONO)
Haskell has userspace threads and at least 1 actor implementation which i don't know a lot about
For ML and ocaml, some libs which are probably not widely used: poly/ML and oc4mc
and netmulticore
Although, it is a very old question things have changed since it was asked. C++ has an actor model implementation which is quite robust. It also provides distributed computing features as asked by OP. The homepage is at http://actor-framework.org/
Further, it can also make us of OpenCL for HPC the module for which is located at github in one of the repositories.
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 starting to understand Scala and I like it a lot.
How can you position yourself to get a paying job as a Scala developer (assuming those become more common)?
What parts of the Scala ecosystem have the best job potential (Lift, Actors?).
How can you gain credibility with a prospective employer without being able to point to Scala work experience (maybe experience on open-source projects?).
(The above questions are hopefully of somewhat general interest to Scala folk. If you want to factor my particular situation into your response, here are a few details about me: longtime developer (mostly Java) with a Computer Sci PhD; not currently working; I'm tied to a non-cutting edge location (Rochester NY), so I may be limited to remote work.)
Update 2010/07/30:
Thanks for the responses. I'd like to crank up the emphasis on the location issue. I'm tied by family to a location that probably won't have Scala work locally for a long time. Are there realistic prospects for getting remote Scala work, and if so how do you position yourself to get remote work? (A modest amount of travel would be doable, but not a full-on road warrior.)
Also, I was wondering about leveraging my teaching background. Would teaching a Scala class at a local university make a big difference in one's marketability as a developer, or just divert more effort than it is worth?
Pure Scala position:
Finding a pure Scala position is not very easy, but it is getting easier and easier. I am going on my first pure Scala job interview in a few days.
I hope we will see a lot of new systems being written entirely in Scala, and I think these systems will be mostly back-end, heavy duty systems. These systems will be using Scalas less error prone functional style to reduce bugs. I think Akka, SBT and Specs will be important frameworks for the Scala developer (this is not much of a prediction since they are already important).
If you do not find a pure Scala position:
Your credibility comes from your time with Java. Most big companies have heaps of Java code that must be maintained and developed. If it is your job to babysit the old Java code, and as an old Java guru, you should have some say in how this should be done. The first step is to change the Maven setup to allow mixed Java/Scala environment. Moving to SBT is probably your best choice. This is a one time investment you have to do or else you can not proceed!
If you work independently you could probably replace Java with Scala whenever you feel like, most likely when you have to re-factor some old code. Talk about Scala as a "framework" for Java (this is technically a lie) that boosts productivity when speaking to the non technical project manager, this might calm their worrying minds. In the end it will be your responsibility to see to it that Scala indeed integrates with Java. But since Scala does this very well it is not much of a problem. Actually, maintaining old legacy code is not a dream for anyone, so PMs are usually happy if they find anyone who would do it for more than 3 month. Management will probably put up with you rebellion.
If you work in a team it is a bit more tricky. In this case you have to teach the team Scala, or else they will not be able to understand your code. You have to persuade your PM to set aside resources for Scala training (might be hard). When you introduce Scala to a team, start small. My experience is that it takes a while for a Java dude to learn Scala, so this is not done overnight. Therefore, ignore everything that is "hard" when you teach Scala. When the team grasps the basics, start with writing tests in Scala (thank Davetron5000 for this tip), continue to use Java for programming in the application (the production code). Hopefully the team will learn and enjoy Scala and after that, well, it is all downhill from that point.
Good luck!
If I was hiring at the moment, I can tell you right now what questions I would be asking and they would be about the language. It is a hard language to understand at a deep level, even if it seems easy to use and, as a consequence, you might be expected to understand code written in a large number of different styles.
Knowledge of libraries (Akka and Lift being the obvious ones) the sbt build tool is great but it is an extra. I would want to know that you understand:
a bit (well, a lot) about the type system (and higher-kinded types)
something about the typeclasses approach
implicits and the pimp-my-library approach
good scala style (i.e. idiomatic scala)
recursion
the actors approach to concurrency
the standard libraries
functional programming
If you understand the language, you'll pick up the libraries with no problems, I'm sure.
Other libraries:
scalaz for functional programming
scalala for numerical programming (linear algebra etc)
scalaj for interacting with Java
I think your best bet is to get good at Scala and to get visible in the Scala community. These are not necessarily the same thing but luckily they are very closely related in the Scala community. Once you do this there are definitely opportunities to use Scala for fun and profit, whether as a consultant/contractor or as a (remote) full-time employee. As part of getting better and more visible I would recommend becoming active in one of the existing communities (Lift, Akka, ScalaNLP, you name it) or even going out in the wilderness and hacking away to solve a common problem, even if it's just making a native Scala alternative to a popular Java library (e.g. squeryl and Dispatch maybe weren't necessary but they're awesome).
I guess what I'm saying is that contributing to any good, useful Scala code will be good experience and I think the ecosystem is so young that there's no need (or benefit?) to specializing in only one part of it. Of course, if there's a specific subject that Scala is useful for and/or a specific field that benefits from Scala that jumps out to you, direct your attention in that direction.
Having had two full-time Scala jobs at this point, I'd say that the most important thing to do is learn the type system and the standard libraries inside and out. The individual technologies can then be picked up with relative ease.
Also, start using Scala (specifically Specs and ScalaCheck) for testing in your current project, today, if you possibly can.
Finally, as pr1001 said, get visible in the Scala community. Contribute to a project, interact on the mailing list, hang out in #scala on freenode, answer questions where you can.
Take your current job, and implement resume driven development. Just claim that xyz can't get done on schedule without Scala, and then use it. After that, take your project to success and either work elsewhere, open your own business, or continue developing Scala apps at your own company.
It worked for Dick Wall, so it should work for you. :)
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 work with many different models and simulations. Some of the older models and simulations are written in FORTRAN. Some of those models have been converted to C++, but the current trend is to create these models using MATLAB/SIMULINK. From a computer science perspective I have always felt MATLAB/SIMULINK was not a good solution. What language do you use to create models and simulations and why?
I would always try to use the language that is provided by the best modeling and simulation tool (or library, if you like) to do the job for me.
And this question can really only be answered by taking into account what kinds of models you want to implement. Continuous (e.g. ODEs), discrete (e.g. StateCharts, Petri Nets), or a combination (i.e. a hybrid model, as can be implemented with Simulink+StateFlow)? There are various tools for each kind of model.
Another important aspect would be the domain in which you are working. Simulink has pretty extensive libraries for electrical engineering, finance, or computational biology (most of them are included in additional packages, though) - if you work in one of those fields, there might simply be no better (i.e. complete, valid) component library. The same goes for other commercial simulation packages, such as AnyLogic, Arena, etc. There might also be some open-source simulation tools, depending on your modeling problem.
Finally, you might prefer a specific programming language over another, and you might have additional requirements, e.g. support for
Optimization (of model parameters)
Validation
Output analysis (statistics, plots, statistical tests)
Support for parallel and distributed simulation
Model checking
...
So I'm currently working with Java with the well-known advantages - reasonably fast, good support for multi-threading, relatively simple to use etc. But if 'reasonably fast' is not fast enough, there might be no option but going down one level of abstraction :-)
I also work with a lot of legacy code, most of it in Fortran. I really don't mind using Fortran - all the modern compilers allow variable names greater than the old and silly 6 character limit. Also, with Fortran 95, you can even do OOP if you feel that your modifications to the existing codebase would benefit.
Also, there are very good code editors for Fortran, which isn't always the case for more specialized script languages.
C++ has the great disadvantage of memory considerations. I have been programming C/C++ for 20+ years now, and I still forget to delete objects and properly fill in destructors.
On a final note, if you're using Windows, there is a Fortran.NET compiler (I think from Lahey-Fujitsu?) if you want to move your Fortran to a managed environment.
Good luck!
SIMULA of course !! :-)
What I've gotten out of MATLAB is it's ability to let me quickly prototype an algorithm. I can really get a good feel for the data by plotting it and using the built in statistics functions. When trying something new out, I can do something quick and dirty to get some initial results, then go back and clean things up to refine my results. With compiled languages, there's a lot more I have to do just to get the simulation to run. With MATLAB, I spend more time thinking about the real problem, and less about compiling, linking, memory management, etc.
However, there are many problems that MATLAB is just ill-equipped to solve. For large data sets, a compiled language with user defined data structures is almost certainly necessary.
Particle physics has been moving to C++ and python. This is not universal, and probably wouldn't even be close were it not for the ubiquity of ROOT.
Root's use of cint means you needed bother with memory management when you're dinking around with a new idea, it's capacity to run compiled allows you to have speed, the ability to mix the modes is very helpful, and the bindings for python and other RAD languages allow for great flexibility.
In a very real sense, this comes down to an endorsement of roland's point.
you can use s-funcuin block for linking fortran(c,c++) with matlab.
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 develop in Lisp and in Scheme, but I was reading about Clojure and then I want to know, in which cases is better to use it than using Lisp or Scheme? Thanks
This question is impossible to answer. You should use Clojure nearly 100% of the time over CL and Scheme, is what I would say. But that doesn't mean you should listen to me. Others can make a good argument that the opposite is the case.
For me, the syntax and function names in Clojure aesthetically pleasing. Certain Java libraries are invaluable for what I do for data munging and web programming and GUI stuff. Functional programming is challenging and enjoyable. Clojure's flaws are unimportant and outweighed by its benefits in my eyes. Certain intolerable flaws in other Lisps are "fixed" in Clojure, because it's new and it can ignore backwards compatibility. It has a novel and arguably powerful approach to concurrency. The Clojure community is vibrant and welcoming and awesome. All of this says as much about me and what I value as it does about Clojure or other Lisps.
There are libraries for CL and Scheme that don't exist in Clojure or Java. There are people who dislike how Clojure uses too much syntax like [] and {} and want to use parens everywhere. If you want CLOS-style OOP or lots of mutable data structures, another Lisp is arguably better. The JVM is heavyweight, maybe too heavyweight and too much baggage for some people. A lot of Java leaks into Clojure (by design) and this offends some people's sensibilities. The STM and immutable data structures have overheads that make certain things (e.g. number crunching) slower or less elegant. Clojure is new and still rough in certain areas, still rapidly changing and evolving in others. Clojure has yet to pass the test of time, whereas other Lisps already have. Clojure is not a "standard" and some people find a language defined by an implementation to be unappealing. And so on. None of these things matter to me, but they may to you.
This is almost entirely subjective. Which language you should use depends on what you already know, what you are willing to learn, what libraries you want to use, what editors and tools you're comfortable with, what language flaws you're willing to live with and work around and what flaws you can't tolerate, and what helps you get your work done faster, more cheaply, more enjoyably, or achieve whatever your goals are.
Basically, whatever makes you feel warm and fuzzy. Learn them all and then make an informed choice based on your own tastes, and use whichever one you like the best. They're all good.
"Clojure runs on the JVM" means you get the whole cornucopia of Java libraries available. You can make pretty GUIs in Swing, use Apache's Web client or server code, connect a ready-built Sudoku solver... whatever you like.
Another big plus of Clojure is its very polished concurrency support, with about 3 different flavors. If you have a compute-intensive, parallelizable task, Clojure can make it easy. Well, easier.
Update: Another argument. Clojure is pretty strongly functional, so it's a plus if you want to force yourself to think and write functionally.
Clojure should be used when
you need to work with existing java code.
you work with people who are allergic to lisp ("boss, i would like to use a java concurrency library called clojue vs. I would like to re-write this in scheme" [1]
you will be programming for a multi-processor system.
Scheme would be better when:
you need to prove your code is correct. Clojures (call out to java) hinders but does not prevent this.
you are working with people who are allergic to java.
you are developing for a platform with no (new enough) JVM
[1] yes this is a bad bad bad reason. such is the world we live in...
When? As much as possible.
Why? Immutable Data Structures - they really are that good. There are plenty of other reasons too.
ABCL (Armed Bear Common Lisp) and a several of Scheme implementations (KAWA, SISC, ...) are also running on the JVM.
Generally Common Lisp is available in different 'flavors' - ABCL is one of them. Other compile to C, to native code, have extensive development environments or specialized extensions like logic languages or databases.
Clojure OTOH is a new Lisp dialect with emphasis on lazy functional programming and concurrent programming. Its author (Rich Hickey) is a very experienced software developer (he has also written Java and .net interfaces for Common Lisp) and did an excellent job with Clojure. Even though there is some hype around the language, it is worth checking out - it is definitely one of the better Lisp dialects developed in recent years (compared to say Newlisp or Arc).
There are lot's of reasons, some mentioned above. My take is:
The pre-existing libraries. This is such a benefit. I just can't praise this feature enough.
The language is more adapted to the
hardware currently available
(multi-core) and the development
paradigms in use today. It is so much easier to reason about concurrency. The functional aspects are nicer too. You can do functional programming in Lisp, obviously, but it is very easy to break the paradigm unknowingly, unwittingly, and unintentionally.
Cross platform. I run identical
programs on Linux, Windows, and the
Mac. There are lot's of native Lisps
that run across platforms, but
support for all features on all
platforms is a bit spotty and you
constantly have to be on the alert
for things that are missing on one
platform or the other. Likewise,the
libraries you need are not always
consistently supported across
platforms. ABCL and some of the
JVM Scheme implementations have this
consistent support as well, but I
still prefer Clojure because of
point 2.
The nature of the language
community. Let's face it, a lot of
the time the Common Lisp community
is just nasty to deal with. That is
not the case with Clojure at all.
It's easy to get useful help without
the condescension and meanness that
often comes with an answer from the
Common Lisp community. As I have
learned for myself several times,
there is no question so stupid that
you won't get a polite and helpful
reply from the Clojure community.
If I had to find one thing to complain about, it would be IDE support. Maybe it's a question of learning new habits, but it is still easier for me to handle the mechanics of Java development than Clojure. I have tried, and use, Clojure Box, enclojure on NetBeas, La Clojure on Intellij IDEA, and Counterclockwise on Eclipse. They all work fine if you are working primarily from the REPL, but for compilation and execution of class files, they all still feel a bit clumsy.
A subset of Clojure can also compile to javascript
Clojure runs on the JVM (and on the CLR), so there is that.
Clojure's design is concerned with accommodating several styles of concurrent programming safely, deliberately making it difficult to mistakenly write the dangerous, rickety, and often broken concurrency-tolerant code in other languages. If your problem domain involves concurrent programming, Clojure's array of integrated tools for managing concurrency may be a better fit than the implementation-specific or lowest-common-denominator libraries available in other Lisps and Schemes.
One of the greatest things about Clojure is the plethora of libraries you can use with it. You have the power of Java with the expressiveness of Lisp, and that is a badass combination. Clojure is more suited for real world development, because it was made for real world development. With Clojure, you have awesome libraries, awesome modern features, and an amazing community of helpful, like-minded people.
I would have to say that Clojure is a better language, all the way around. That is a highly argumentative statement to make, so I will point out here that this is just my honest opinion.
Clojure rocks.
I'm always trying to learn new languages, so I'm interested in learning Clojure. But, aren't SBCL and some other Common Lisp implementations much, much faster than Clojure? Wouldn't you need considerably more than 4 processors (and a reasonably parallelizable task) to make up for the performance difference between a Clojure app and even a single-threaded SBCL version of the same app?
As a general rule of thumb, I tend to favor Clojure over other languages in cases where either of these fit the bill:
(1). The domain model tends to look very recursive and/or graph-like.
(2). There's an opportunity to leverage a multi-core JVM environment (e.g., Elastic Beanstalk)
(3). There's a fuzzy barrier between data and code (think RPN calculator where nodes can be operators or numbers)
These might sound a bit contrived, but a lot of my work involves dealing with graphs and trees of information, whether it's looking at social networks, some kind of constrained-based optimization, or semantic relationship building. I find that my other favorite language, Ruby, cannot give me the mix of expressiveness and raw computing power compared to Clojure, particularly when it comes to quantitative, recursive, concurrent-type problem solving.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Recently i have been getting into alternative languages that support an actor/agent/shared nothing architecture - ie. scala, clojure etc (clojure also supports shared state).
So far most of the documentation that I have read focus around the intro level. What I am looking for is more advanced documentation along the gang of four but instead shared nothing based.
Why ? It helps to grok the change in design thinking. Simple examples are easy, but in a real world java application (single threaded) you can have object graphs with 1000's of members with complex relationships. But with agent based concurrency development it introduces a whole new set of ideas to comprehend when designing large systems. ie. Agent granularity - how much state should one agent manage - implications on performance etc or are their good patterns for mapping shared state object graphs to agent based system. tips on mapping domain models to design. Discussions not on the technology but more on how to BEST use the technology in design (real world "complex" examples would be great).
Even if I cannot come up with any good real world examples that provide you with design
patterns straight up, there are a few places to start.
The first is getting your head wrapped properly round the concepts. One book helping
you do this is Making reliable distributed systems in the presence of software errors
written by an Erlang Guru Joe Armstrong where explains Concurrency Oriented Programming
in a very accessible way. It is in fact a Ph.D. thesis, but do not let that scare you.
It is by far easier to read, and pleasant into the bargain, than most common text books.
Looking at actual systems normally means that you have to learn too much about the actual
language for it too make sense just to evaluate things. For Erlang the documentation
provides design methodology and behaviours(Erlang speek for design pattern libraries).
This will illustrate the design patterns most commonly used in this setting. And these
have proved to be effective in building large scale systems, i.e. millions of lines of code (comparable to a factor 4 to 10 of other languages such as Java) and milloins of concurrent processes running on one machine in distributed clusters of machines.
A recent example of a real live system is Facebook Chat.
For the other frameworks I cannot really help you I am afraid.
An "actor" is itself the unifying pattern for concurrent programming (an asynchronous message queue plus an execution context for processing it), but there are many design patterns which assist in specifying aspects or elements of agent-based systems. Many of the most common can be found in Wikipedia's article on Concurrency Patterns. Some highlights:
Reactor Pattern
Mediator Pattern
Scheduler Pattern
Observer Pattern
If you haven't come across it already, Akka may be of interest to you -- it is a "purely" event-driven actor framework running on the JVM.
I asked a similar question here which had some reasonable answers that may help. I'm watching yours carefully. I haven't yet found something which has really helped me, but I am very actively looking.
I think the mind-shift is the single largest barrier to stepping to concurrent architectures and languages and until that is cracked developers are going to stick with easy to learn MS style paradigms. For it to really become mainstream it needs to find its way into schools and be taught alongside C# and VB.
My answer to the 2080 programmers question is "concurrently".