When I hire developers for general mid-to-senior web app development positions, I generally expect them to understand core concurrent programming concepts such as liveness vs. safety, race conditions, thread synchronization and deadlocks. I'm not sure whether to consider topics like fork/join, wait/notify, lock ordering, memory model basics (just the basics) and so forth to be part of what every reasonably seasoned developer ought to know, or whether these are topics that are more for semi-specialists (i.e. developers who have made a conscious decision to know more than the average developer about concurrent programming).
I'd be curious to hear your thoughts.
I tend to think that at this point in time concurrent programming at any serious level of depth is still a specialist skill. Many will claim to know about it through study, but many will also make an almighty mess of it when they come to apply it.
In addition to the considerations listed, I would also look at resource implications and the various overheads of using processes, threads and fibers. In some contexts, e.g. mobile devices, excessive multithreading can have serious performance implications. This can lead to portability issues with multithreaded code.
I guess if I was interviewing a candidate in this situation, I would work with a real world example rather than hitting on more general topics which can be quoted back verbatim from a text book. I say this having done a fair bit of multithreaded work myself and remembering how badly I screwed up the first couple of times. Many can talk the talk... ;)
I know all these topics, but I studied them. I also know many competent senior programmers that don't know these. So unless you expect these programmers to be using those concepts actively, there is no reason to turn down a perfectly good candidate because they don't understand every aspect of concurrency
The real question is:
In what ways does it matter to the code they will be developing?
You should know which concepts the development position you're hiring for needs to know to be able to work on the projects that they will be responsible for.
As with anything in the programming world.. The devil is in the details, and you can't know everything. Would you expect them to know Perl if you were hiring for a Java position?
Also, concurrency, at this stage, while well described in generalized theory, is heavily implementation and platform dependent. Concurrency in Perl on an AIX box is not the same game as concurrency in a C++ Winforms app. They can have all the theory in the world under their belts, but if it's required for the job, then they should have intimate knowledge of the platform they are expected to use it on as well.
I interview folks for concurrency-related positions frequently and I look for three general aspects:
General understanding of core concepts like the ones you list (language-independent)
Specific understanding of Java concurrency libraries and primitives (specific to the work they'd be doing)
Ability to design the solution to a concurrent problem in a reasonable way.
I consider #1 a requirement (for my positions). I consider #2 a nice to have. If they understand it and can describe it in terms of pthreads or whatever other library, it's no biggie to learn the latest Java concurrency libraries (the concepts are the hard part). And #3 tends to separate the hires from the maybe-hires.
Per your question, I wouldn't consider fork/join to be known by almost anyone, esp someone applying for a web app developer position. I would look for developers to have experience with some (but not all) of those topics. Most developers I've interviewed have not used the Java 5+ concurrency libs at all but they can typically describe things like data race or deadlock.
Related
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 8 years ago.
Improve this question
I'm well educated in the C++ programming language regarding syntax, STL, etc. I haven't done any true projects with it yet other than some college courses. My goal is to start writing progams but attempt to keep it to industry best practices. One of my main goals is to work in the game industry. A door is opening which lead me to ask these questions.
Are C++ game developers usually limited on using all the C++ features? Is it true more or less for each platform?
Is STL used these days in the environment, or should I avoid it?
Do they treat C++ as "everything must be an object" or is it a mix of paradigms?
Any features they tend to not use?
Is C still used, and is it good to show a project completed in it?
I did talk to a famous game designer and he said they don't use STL and said to use basic encapsulation with classes, but he said not to use all other advanced C++ features. The idea is to keep it simple. Is this common?
Thanks in advance!
Bear in mind that "games development" covers everything from phones to websites to PSPs and DS to Wii, Xbox, PS3 and PC/Mac, so the answers you get may vary from one product/developer/platform to another.
1) Yes. Games development can mean that you have to use a particular compiler for your target platform, which may not support some of the "newer" features of C++. You may be restricted on which libraries the development studio will allow you to use. In addition, hardware restrictions on some platforms may influence how you code (e.g. on some systems the cost of virtual functions can be excessively high compared to a PC, so your designs can be restricted away from pure OO for performance reasons. Some systems have limited resources (memory, disk, etc) which will influence your design a lot. On the Playstation3 you may need to write vector-processing SPU tasks rather than traditional single/multithreaded code. etc).
2) Yes. (it's commonly used, as there's usually no point wasting time rolling your own, probably less efficient, equivalents)
3) A mix. Generally in games the key goals are (in rough order): Deliver the impossible on time (why are you going home now, it's only 10pm?), deliver high performance, and try not to crash.
4,6) Generally keep the code simple and flexible so you can develop fast and change to suit the producer's latest vision. You usually have tight deadlines so a lot of design and careful coding tends to be difficult to achieve. The industry unfortunately tends to work on the "churn out the code quickly so we can throw it away and start on the next product", although it is slowly coming around to the idea of re-usable libraries (and more methodical professional practices like unit tests, etc).
A typical scenario is to be asked to code up a quick and dirty demo for the boss, and then when you think you'll be able to throw it away and write it properly, the boss says "we don't have time to rewrite something that already works, start on the next level". So if you're asked to be quick'n'dirty, try not to burn too many bridges or you'll regret it.
5) You may use C, but it depends on the platform and the development house. These days most devlopment will be C++ even if parts of the code are effectively "little more than C" in terms of syntax and features used.
These questions are not at all unique to game development. You will find they vary as much by field as they do by company. I can think of two game design firms that use STL off the top of my head, and also of a few that don't.
1) Define "all C++ features". They typically don't use goto, if that's what you mean.
2) Yes STL is used. You shouldn't avoid it, or not avoid it - use the tools you need to get the job done every time you have a job that needs to get done. Keeping what you use in line with other ways similar problems were tackled -within that project or context- is importent.
3) Depends where you are, both in games and out of games. Some are graduated C guys who want things more C like. Others are C#/Java guys who are more OO (Object Obsessed).
4) goto
5) Yes, and yes. Knowing more than one language is always a good thing. Even if it's just C to C++.
6) Again, use the tools available to solve your problems. Keeping it simple is good when you can, sure.
1) No limitation really, except that you should follow programming guides so as to use them properly (i.e. avoid dinosaurs when using goto's).
2) Yes, its used, and Boost also (which is kinda the preview of the next STL).
3) Mix, always a mix. To say that C++ is only object-oriented is to misunderstand the language. "Everything is an object" is really a Java (or things like it) thing; check out C++'s concept of POD, as an example of how not everything is an object.
4) same as 1)
5) It is used, but as far as I've seen, no new project is being created in C.
6) No... he kinda said the opposite of what I've just said.
Generally, some parts of C++ are limited for patform and performance reasons.
Exceptions and RTTI are normally disabled. Exceptions are expensive when they unwind the stack, and RTTI uses too much memory. Lack of exceptions is particularly a pain because rather than come up with another error handling system, programmers tend to just return NULL. :)
Floats are used almost exclusively over doubles, for performance reasons.
Virtual functions and inheritence can be used, but the virtual table lookup can be costly so sometimes it's optimised out.
The STL can be used, but you normally have to write your own allocators to avoid fragging memory (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html). It's more common to see custom containers - of varying quality. I've never come across boost being used in a console project.
Most code is OO, almost to a fault.
Best C++ programming practices in professional game development environments?
The question is too broad.
Are C++ game developers usually limited on using all the C++ features? Is it true more or less for each platform?
No, or at least extremely unlikely. Depends on platform/compiler.
Is STL used these days in the environment, or should I avoid it?
You shouldn't avoid it, but:
you'll definitely need a profiler if you want stl containers
STL containers are extremely slow in debug builds. This might be a problem, because if you're frequently accessing them, there will be a huge performance drop (say, from 300 fps to 50) in debug build (when compared to release build). Debug code is already slower, and stl containers have large amount of "security check" in debug build.
Do they treat C++ as "everything must be an object"
Every idea is bad if you take it to extremes. "Everything must be an object" is one of those.
Any features they tend to not use?
Why? Unless there is a compiler bug or performance loss there is no point in avoiding feature. Besides, there are commercial 3D games written in java, so I see no point in avoiding feature of compiled language.
Is C still used, and is it good to show a project completed in it?
Some opensource projects may use C, but I can't remember a game completely written in it. There is Q3 engine, but afaik it is mix of C/C++.
I did talk to a famous game designer and he said they don't use STL and said to use basic encapsulation with classes, but he said not to use all other advanced C++ features.
They could decide to avoid stl simply because containers are slow in debug build. It is unclear what exactly you call "advanced C++ features". Also, keep in mind that he is designer, not programmer.
The idea is to keep it simple. Is this common?
The idea may or may not be common, but it is a correct idea for a small teams. With limited human resources everything should be made as simple as possible - to reduce development costs. If you stick to concept like "everything should be an object", decide to build "nice-looking" class hierarchy, etc, AND if you have limited resources, then you are doomed - It is very possible that you'll never finish your project and will be rewriting code forever and trying to decide what should be derived from what. Needless project flexibility and extensibility may kill small project. Game engine doesn't have to be complicated.
Large teams may afford complex solutions, but complexity leads to additional bugs. For example, you could look at sims 3 - it has a VERY advanced system (object "plugins", game resource management, GPU resource management, content "streaming", etc, and I think they even put game logic into a few .NET modules that are stored within game archive...), but extensibility of the system resulted in mountain of bugs after certain updates.
Electronic Arts as one example uses STL, but felt compelled to create their own version of it called EASTL.
Are C++ game developers usually limited on using all the C++ features? Is it true more or less for each platform? These days, I think it's pretty good on the main console platforms but if you were developing for mobile devices I doubt it's quite so even
Is STL used these days in the environment, or should I avoid it? It is used and should be used... but some people don't trust it because in the past STL support was much less even, and sometimes had performance problems
Do they treat C++ as "everything must be an object" or is it a mix of paradigms? Far too general. Varies from person to person and company to company. On average, game developers have a reputation for being less focused on software engineering and more on hacking code, but that's far too generalised to really be of use. However spouting for 30min about design patterns and frameworks and abstractions in an interview is probably not a wonderful plan
Any features they tend to not use? STL still has a bad rep amongst those who worked on older platforms. Exceptions also and RTTI, probably sicne they weren't well supported (and maybe are still not)
Is C still used, and is it good to show a project completed in it? I'm sure it is, and if you have a project then show it, but it's not anywhere near as widely used as C++
I did talk to a famous game designer and he said they don't use STL and said to use basic encapsulation with classes, but he said not to use all other advanced C++ features. The idea is to keep it simple. Is this common?
That view is pretty common but it doesn't mean it's right. You might want to tread carefully to avoid upsetting a 20-year veteran who has not moved with the times
I'm going to assume you're referring to people who develop full-price games for consoles and PC.
"Are C++ game developers usually limited on using all the C++ features?"
I think most are avoiding exceptions, RTTI, and many avoid the STL part of the standard library. They're probably using templates, though not much metaprogramming. I don't think this varies much across platform. But it does vary from company to company.
"Is STL used these days in the environment, or should I avoid it?"
It is used by many, but not all. Don't avoid it - it's a useful tool that is very good at the tasks it is designed for. Just make sure you can get by without it.
"Do they treat C++ as "everything must be an object" or is it a mix of paradigms?"
Different places will work in different ways. There's nothing intrinsic to object orientation in C++ that makes it good or bad for game development. Bear in mind that there is often legacy code or 3rd party libraries that are written in C or designed to be operated from C, so it's very rare that you'll have C++ throughout.
"Any features they tend to not use?"
I think we covered this above.
"Is C still used, and is it good to show a project completed in it?"
Yes, and no. Life is too short to spend on mastering every related language and dialect before you get your first job. Showing the ability to use a C-style library (eg. SDL) should suffice. Obviously if you set your goals on joining a company that just uses C, you will have to consider that.
"I did talk to a famous game designer and he said they don't use STL and said to use basic encapsulation with classes, but he said not to use all other advanced C++ features. The idea is to keep it simple. Is this common?"
See above. Incidentally, game "designers" typically aren't programmers, so watch your terminology. If you apply for a game designer role, you won't usually be showing programming skills.
I understand it should cover threading primitives (mutex, semaphore, condition variables etc.) plus design patterns (such as those specified in POSA2). But what's more? Every project has its own multithreading scenarios and one may have not dealt with those that the job is expecting?. So how does one build their knowledge and prove that they have the ability?
Regardless of specifics solid, detailed and very deep knowledge is required. One should understand how the bottlenecks form, how to deal with scalability problems, how to diagnose cases where synchronization is required but is erroneously omitted.
If for example you had a job experience with multithreading and I ran an interview to assess you I'd ask detailed questions on typical scenarios that arise when developing multithreaded programs. I wouldn't expect you knew many technologies or some specific technology, but I'd expect you to have mastered the technology you claim you're familiar with in great detail and to understand which fundamental problems it solves and how.
I would expect the candidate has knowledge and experience of the issues that arise when multiple threads access shared resources. What problems can be caused by concurrent access and what problems the solutions (such as locking etc) present.
At the very least understanding of how to write and read asych code on the platform of choice.
After this it will be understanding the specifics if the platform - e.g. such how to access the primary window in windows system while many things needs up the display at the same time.
Fundamentally is about understanding what trade-offs are needed and when.
May I present a different view. I think you should understand the basics,
but really never give up on a job based on a flyer description. I have
not met a programming concept that could not be figured out in half a day.
So, basically, read a tutorial before the interview, do not try to misrepresent
your actual experience with threading, but make sure they know the things you
had more hands on experience, and see if there is a mutual interest in you working
for the company. They may like you even if you know nothing about threading if they are confident that you can pick it up at full speed.
Can anyone help me on design patterns commonly used for RTOS?
In VXworks, which pattern is more preferable?
Can we ignore the second sentence in your question? It is meaningless, and perhaps points to a misunderstanding of design patterns. The first part is interesting however. That said, I would generalise it to cover real-time systems rather than RTOS.
Many of the most familiar patterns are mechanistic, but in real-time systems higher-level architectural patterns are also important.
Bruce Powell Douglass is probably the foremost author on the subject of patterns for real time systems. If you want a flavour of what he has to say on the subject then read this article on Embedded.com (it is part three of a series of three; be sure to read the first two as well, since they also touch on the subject, (1) (2)). You could also do worst than to visit Embedded.com and enter "design patterns" into the search box, there are a number of articles on specific patterns and general articles on the subject.
While I think you are being far to specific in requesting patterns for "RTOS(VxWorks)", patterns I have used specifically with VxWorks are the Facade and Adapter patterns. Partly to provide an OO API, and also to provide a level of RTOS agnostic abstraction. The resulting classes were then implemented for Segger emBOS (to allow us to run a smaller, lower cost, royalty free RTOS), and both Windows and Linux to allow test, debug and simulation of the code in a richer environment with more powerful tools.
A non-exhaustive list of many patterns is provided on Wikipedia, many of which will be applicable to real-time systems. The listed concurrency patterns are most obviously relevant.
As Mike DeSimone commented, way too generic. However, here are couple things to keep in mind for a RTOS (not just VxWorks).
Avoid doing too much in the ISR. If possible pass on some of the processing to a waiting task.
Keep multithreading optimal. Too much and you have context switching overhead. Too little and your problem solution may be complicated.
Another important aspect is keeping the RTOS predictable and understandable for the user. Typically you see fixed-priority schedulers that do not try to be fair or adaptive, but rather do exactly as told and if you mess up with priorities and starve some task, so be it. Time to complete kernel operations tend to be short and predictable, often documented with their worst-case execution times.
I'm currently writing a large multi threaded C++ program (> 50K LOC).
As such I've been motivated to read up alot on various techniques for handling multi-threaded code. One theory I've found to be quite cool is:
http://en.wikipedia.org/wiki/Communicating_sequential_processes
And it's invented by a slightly famous guy, who's made other non-trivial contributions to concurrent programming.
However, is CSP used in practice? Can anyone point to any large application written in a CSP style?
Thanks!
CSP, as a process calculus, is fundamentally a theoretical thing that enables us to formalize and study some aspects of a parallel program.
If you instead want a theory that enables you to build distributed programs, then you should take a look to parallel structured programming.
Parallel structural programming is the base of the current HPC (high-performance computing) research and provides to you a methodology about how to approach and design parallel programs (essentially, flowcharts of communicating computing nodes) and runtime systems to implements them.
A central idea in parallel structured programming is that of algorithmic skeleton, developed initially by Murray Cole. A skeleton is a thing like a parallel design pattern with a cost model associated and (usually) a run-time system that supports it. A skeleton models, study and supports a class of parallel algorithms that have a certain "shape".
As a notable example, mapreduce (made popular by Google) is just a kind of skeleton that address data parallelism, where a computation can be described by a map phase (apply a function f to all elements that compose the input data), and a reduce phase (take all the transformed items and "combine" them using an associative operator +).
I found the idea of parallel structured programming both theoretical sound and practical useful, so I'll suggest to give a look to it.
A word about multi-threading: since skeletons addresses massive parallelism, usually they are implemented in distributed memory instead of shared. Intel has developed a tool, TBB, which address multi-threading and (partially) follows the parallel structured programming framework. It is a C++ library, so probably you can just start using it in your projects.
Yes and no. The basic idea of CSP is used quite a bit. For example, thread-safe queues in one form or another are frequently used as the primary (often only) communication mechanism to build a pipeline out of individual processes (threads).
Hoare being Hoare, however, there's quite a bit more to his original theory than that. He invented a notation for talking about the processes, defined a specific set of signals that can be sent between the processes, and so on. The notation has since been refined in various ways, quite a bit of work put into proving various aspects, and so on.
Application of that relatively formal model of CSP (as opposed to just the general idea) is much less common. It's been used in a few systems where high reliability was considered extremely important, but few programmers appear interested in learning (yet another) formal design notation.
When I've designed systems like this, I've generally used an approach that's less rigorous, but (at least to me) rather easier to understand: a fairly simple diagram, with boxes representing the processes, and arrows representing the lines of communication. I doubt I could really offer much in the way of a proof about most of the designs (and I'll admit I haven't designed a really huge system this way), but it's worked reasonably well nonetheless.
Take a look at the website for a company called Verum. Their ASD technology is based on CSP and is used by companies like Philips Healthcare, Ericsson and NXP semiconductors to build software for all kinds of high-tech equipment and applications.
So to answer your question: Yes, CSP is used on large software projects in real-life.
Full disclosure: I do freelance work for Verum
Answering a very old question, yet it seems important that one
There is Go where CSPs are a fundamental part of the language. In the FAQ to Go, the authors write:
Concurrency and multi-threaded programming have a reputation for difficulty. We believe this is due partly to complex designs such as pthreads and partly to overemphasis on low-level details such as mutexes, condition variables, and memory barriers. Higher-level interfaces enable much simpler code, even if there are still mutexes and such under the covers.
One of the most successful models for providing high-level linguistic support for concurrency comes from Hoare's Communicating Sequential Processes, or CSP. Occam and Erlang are two well known languages that stem from CSP. Go's concurrency primitives derive from a different part of the family tree whose main contribution is the powerful notion of channels as first class objects. Experience with several earlier languages has shown that the CSP model fits well into a procedural language framework.
Projects implemented in Go are:
Docker
Google's download server
Many more
This style is ubiquitous on Unix where many tools are designed to process from standard in to standard out. I don't have any first hand knowledge of large systems that are build that way, but I've seen many small once-off systems that are
for instance this simple command line uses (at least) 3 processes.
cat list-1 list-2 list-3 | sort | uniq > final.list
This system is only moderately sized, but I wrote a protocol processor that strips away and interprets successive layers of protocol in a message that used a style very similar to this. It was an event driven system using something akin to cooperative threading, but I could've used multithreading fairly easily with a couple of added tweaks.
The program is proprietary (unfortunately) so I can't show off the source code.
In my opinion, this style is useful for some things, but usually best mixed with some other techniques. Often there is a core part of your program that represents a processing bottleneck, and applying various concurrency increasing techniques there is likely to yield the biggest gains.
Microsoft had a technology called ActiveMovie (if I remember correctly) that did sequential processing on audio and video streams. Data got passed from one filter to another to go from input to output format (and source/sink). Maybe that's a practical example??
The Wikipedia article looks to me like a lot of funny symbols used to represent somewhat pedestrian concepts. For very large or extensible programs, the formalism can be very important to check how the (sub)processes are allowed to interact.
For a 50,000 line class program, you're probably better off architecting it as you see fit.
In general, following ideas such as these is a good idea in terms of performance. Persistent threads that process data in stages will tend not to contend, and exploit data locality well. Also, it is easy to throttle the threads to avoid data piling up as a fast stage feeds a slow stage: just block the fast one if its output buffer grows too big.
A little bit off-topic but for my thesis I used a tool framework called TERRA/LUNA which aims for software development for Embedded Control Systems but is used heavily for all sorts of software development at my institute (so only academical use here).
TERRA is a graphical CSP and software architecture editor and LUNA is both the name for a C++ library for CSP based constructs and the plugin you'll find in TERRA to generate C++ code from your CSP models.
It becomes very handy in combination with FDR3 (a CSP refinement checker) to detect any sort of (dead/life/etc) lock or even profiling.
a theoretical question. After reading Armstrongs 'programming erlang' book I was wondering the following:
It will take some time to learn Erlang. Let alone master it. It really is fundamentally different in a lot of respects.
So my question: Is it possible to write 'like erlang' or with some 'erlang like framework', which given that you take care not to create functions with sideffects, you can create scaleable reliable apps as well as in Erlang? Maybe with the same msgs sending, loads of 'mini processes' paradigm.
The advantage would be to not throw all your accumulated C/C++ knowledge over the fence.
Any thoughts about this would be welcome
Yes, it is possible, but...
Probably the best answer for this question is given by Robert Virding’s First Rule:
“Any sufficiently complicated
concurrent program in another language
contains an ad hoc,
informally-specified, bug-ridden, slow
implementation of half of Erlang.”
Very good rule is use the right tool for the task. Erlang excels in concurrency and reliability. C/C++ was not designed with these properties in mind.
If you don't want to throw away your C/C++ knowledge and experience and your project allows this kind of division, good approach is to create a mixed solution. Write concurrent, communication and error handling code in Erlang, then add C/C++ parts, which will do CPU and IO bound stuff.
You clearly can - the Erlang/OTP system is largely written in C (and Erlang). The question is 'why would you want to?'
In 'ye olde days' people used to write their own operating system - but why would you want to?
If you elect to use an operating system your unwritten software has certain properties - it can persist to hard disk, it can speak to a network, it can draw on screens, it can run from the command line, it can be invoked in batch mode, etc, etc...
The Erlang/OTP system is 1.5M lines of code which has been demonstrated to give 99.9999999% uptime in large systems (the UK phone system) - that's 31ms downtime a year.
With Erlang/OTP your unwritten software has high reliability, it can hot-swap itself, your unwritten application can failover when a physical computer dies.
Why would you want to rewrite that functionality?
I would break this into 2 questions
Can you write concurrent, scalable C++ applications
Yes. It's certainly possible to create the low level constructs needed in order to achieve this.
Would you want to write concurrent, scalable, C++ applications
Perhaps. But if I was going for a highly concurrent application, I would choose a language that was either designed to fill that void or easily lent itself to doing so (Erlang, F# and possibly C#).
C++ was not designed to build highly concurrent applications. But it can certainly be tweaked into doing so. The cost might be higher than you expect though once you factor in memory management.
Yes, but you will be doing some extra work.
Regarding side effects, consider how the .net/plinq team is approaching. Plinq won't be able to enforce you hand it stuff with no side effects, but it will assume you do so and play by its rules so we get to use a simpler api. Even if the language doesn't have built-in support for it, it will still simplify things as you can break the operations more easily.
What I can do in one Turing complete language I can do in any other Turing complete language.
So I interpret your question to read, is it as easy to write a reliable and scalable application in C++ as it is in Erlang?
The answer to that is highly subjective. For me it is easier to write it in C++ for the following reasons:
I have already done it in C++ (at least three times).
I don't know Erlang.
I have read a great deal about Stackless Python, which feels to me like a highly concurrent message based cooperative multitasking system in python, but of course python is written on top of C.
Having said that. If you already know both languages, and you have the problem well defined, you can then make the best choice based on all the information you have at hand.
the main 'problem' with C (or C++) for writing reliable and easy to extend programs is that in C you can do anything. so, the first step would be to write a simple framework that restricts just a bit. most good programmers do that anyway.
in this case, the restrictions would be mostly to make it easy to define a 'process' within whatever level of isolation you want. fork() has a reputation of being slow, and threads also need significant time to spawn, so you might want to use a cooperative multitasking, which can be far more efficient, and you could even make it preemptive (i think that's what Erlang does). to get multi-core efficiency, set a pool of threads and make all of them complete to run the tasks.
another important part would be to create an appropriate library of immutable data structures, so that using them (instead of the standard lib) your functions would be (mostly) side-effect-free.
then it's just a matter of setting a good API for message passing and futures... not easy, but at least it doesn't seem like changing the language itself.