The stuff about F# being faster is really nonsensical - it compiles down to the same thing as C# (CIL) and runs on the same VM. The so-called performance gain is not some inherent property of the language - it's due to a shift in style of programming - one where you don't modify state.
The core concept of functional programming is that state is immutable. If you wish to modify a value, you don't, you instead call a function which returns the newer value. Even operations like adding an item to a list are immutable, so instead of mutating the list, you return a new list with the new element added. It might seem slow to do such thing, but there are numerous benefits to it. Mutable state is the devil and must be avoided, at whatever extra cost.
Well, not strictly true in F#, since it's mutli-paradigm and can use mutable structures you're familiar with in C#, and you *can* introduce mutable state into F# with the mutable keyword (although highly discouraged.)
There are reasons why F# syntax is the way it is, which is certainly alien to C# users. You do get used to it though, and at some point you'll not want to go back to C# - the syntax of F# is more compact, and you can do more in less.
As for the improved use of async in F#, that's largely true, although the next version of C# will have similar capabilities, which you can already try out with the
[Only registered and activated users can see links. Click Here To Register...] - two new keywords, async and await, which add a lot of capability. The C# approach to this problem is a lot less flexible than the F# approach though - as async in F# is not a built in language feature, but an application of a more powerful feature, workflows. These can do a lot more than just async.
On using F# to write a server - someone has already mentioned that a mixed approach would be suitable. F# alone isn't really ideal for a game server, because a game server happens to be based on a huge collection of mutable state - something actively discouraged in F#. Although a message passing approach can be suitable for solving those problems (But then, there are better languages than F# for message passing.)
I would recommend every keen C# programmer also learns F# anyway, even if they don't intend to write complete applications in it.
Quote:
Originally Posted by BaussHacker
C++ can do...
|
The problem with C++ is it's not type-safe, it only pretends to be. You can nuke the type safety anywhere. (Although the same is kind of true for C# with reflection.)
The other problems are lack of higher level features like lambdas, reflection, coroutines, and lack of a standard threading model. A lot of these features have been added and finalized, but the new specification is not yet published, and no compiler has fully implemented the new spec. You can get parts of the new version of C++ in MSVC++, GCC and Clang though.
And then comes the problem with libraries. There are many, but they are generally all incompatible with each other, or have some essential features missing. You end up juggling through many libraries to get exactly what you want. (And as for running on all platforms - that's a joke, due to the library situation). Actually C# is way easier to port between major platforms now, due to more consistent libraries.
To give a library example, take boost::asio for networking. It's been considered a defacto standard for async networking in C++ due to it's portability and ease to use. The problem? It uses boost::shared_ptr<>, which is incompatible with the now standardized (and massively improved) std::shared_ptr<>. Meaning, whenever you need boost, you can't use some standard library features which are incompatible.
I was trying to get back into C++ after years hiatus learning and using C#, but the number of problems just put me off. It's in an awkward state until the C++0x specification is implemented properly in compilers, and many libraries, particularly boost, shift to using the new smart pointers and other newer features of the standard library. Then there's the tooling - IDEs, debuggers, profilers etc need updating to work with the new language. If all that is done, the language will return to a state where it can compete with C# in terms of high level abstractions.
Oh, and as for Battlefield using Python - it only uses small amounts of it. The game engine will still be written in a low level language like C or C++, and languages like Python are only used to script some game logic, AI and such, which doesn't require intensive computation. Python is very slow compared to even C#, let alone C++, and you'd be lucky to get 1 frame per second of high quality 3d graphics in it alone.