Mono 3.6.0 is out
mono-project.com
mono-project.com
I'm currently working on a big C# codebase and it would be interesting to see if F# would make some of it cleaner.
http://fsharpforfunandprofit.com/series/why-use-fsharp.html
It compares and contrasts C# and equivalent F# code for relatively simple, but common-in-the-real-world examples, while introducing some functional constructs. I'd also recommending reading the "Thinking Functionally" series.
After that I'd recommend skimming some of the topics on the F# wikibook:
http://en.wikibooks.org/wiki/F_Sharp_Programming
And then I'd begin with rewriting some components in your existing project while continuing reading through that book and other online resources.
Me and a coworker also rewrote ~600 line C# module into a working module in F#, along with some interop POC here: https://github.com/cartermp/CSharpToFSharp
It's the product of a little over 20 hours of development across two people new to the language (and thus has some warts...), so take it as a grain of sand. Uses MS Unit Testing framework for F# (available via NuGet).
http://msdn.microsoft.com/en-us/library/vstudio/hh314518%28v...
F#'s benefit will come as a bunch of tiny improvements, "programming in the small" as they call it. For instance:
let xs = [ while r.Read() do yield r.GetInt 0 ]
var xs = new List<int>();
while (r.Read()) { xs.Add(r.GetInt(0)); }
let f x =
let x = try int s with _ -> -1
x * 3
int f(string x) {
int x1;
try { x1 = int.Parse(s); }
catch { x1 = -1; }
return x1 * 3;
}
let x =
use db = new DB()
db.GetX()
SomeType x;
using(var db = new DB()) {
x = db.GetX()
}
These are by no means a complete or even important showcase of C#'s lacking. Just a few quick thoughts off the top of my head. In general, every time I'm writing C# code, I keep realising how things would be much more concise if I was in F#.
1) Simply write a quick extension method (not ideal but not a reason to switch languages):
var xs = r.YourExtensionMethod<int>(rr => rr.GetInt(0)).ToList();
int f(string x)
{
int number; /*Will be not necessary in C#6.*/
return Int32.TryParse(value, out number) ? numeber * 3 : -1;
}
But it sure all adds up.
Switching for a codebase might not be a wise move for many reasons. But writing new code doesn't have those excuses.
Actually workflows are the closest to a "killer" feature but C# took the most popular, async, and hard-coded it in.
I'm not sure how new List<string> { "a", "b" } is more readable than new List<_> {"a", "b"), but hey, sure, if you want to argue type inference is bad, go for it. F# also lacks loop constructs like break/continue.
I don't feel I've misrepresented C# at all to make it look bad. I've written a lot of C# code and a fair amount of F# code. Line by line, char-by-char, expression-by-expression, F# is simply much less code. Those examples are just things off the top of my head, from real codebases.
C#'s alright, because the competition (like Java) is laughable. So in that sense, it's "great". In absolute terms, it doesn't measure up (and this isn't a secret, bit-by-bit C# adopts features F# proved out.)
Units-of-measurements are implemented via erasure, yes. How would you represent float<m> externally to make it available to common types, but without losing performance? The compiler consuming them would need to be aware of it. And at runtime, you certainly don't want extra overhead, and I don't think the CLR has any efficient way of exposing primitives with additional type info. It's an unfortunate tradeoff.
In general, I find writing in C#, I'm going to need 50-200% more code for "business logic" type code that doesn't particularly benefit from F#. That is, using F# as a better C#. And this is after C# hacked in async - before that, there's no comparison if you need async style code.
If C# added pattern matching, tuples, active patterns, type inference, everything-as-an-expression, nesting, more comprehensions, etc. etc., then yes, C# would be competitive. And with all the resources C# gets, the IDE would be far better than F#, sure.
C# is for legacy and large corporate red-tape-encumbered enterprise projects only, as far as I'm concerned.
- Accessing the DB is easier in C# (just select a nice micro-ORM), type providers do not always cut it.
- When using any kind of library that relies on anonymous types (e.g. Dapper for database access).
- Tooling is still not complete, not being able to create directories in F# project (!) from IDE level (and even if you edit .fsproj, it can be a bit buggy) is really annoying in both web and desktop apps.
- If you want to use some of object-oriented features e.g. co/contravariance in interfaces, protected access modifier.
- (admittedly, that does not happen often) no unsafe context/keyword
That being said, I agree that F# has a very sane set of defaults and I really like using F# for library work.
The rest of the real arguments are essentially "library support". Which is a good argument, but not really about the language itself. There's no reason that WPF, DB access, etc. can't be just as fine in F#.
(C#'s limitations, like no tuples, led high-profile projects like ASP.NET MVC to do dumb hacks like "pass in an object and we'll assume each field is a parameter". If C# had been more capable in the first place, they wouldn't have resorted to such hacks.)
You shouldn't be writing WPF apps at all.
Says who? Are we supposed to stop writing Windows desktop apps in C# just because the frameworks are in maintenance mode?
And you can use F#! http://funscript.info/
As mentioned, not a big fan of transpiling.
But then what of C#, which lacks object expressions? Which forces you to declare a type, often an interface, just to implement a member or two?
Also, the .NET libraries we end up using were, to my knowledge, written in C#. Sometimes interacting with them feels awkward if done functionally.
I noticed that was something certain folks tended to do, they'd insist on creating an expression as a series of folds and maps, even if it had a very simple expression otherwise (as a list comprehension or simple for..in loop). Cast those cares aside, and write what is most useful for your use case.
Sometimes though, you do want break/goto/continue, although in most cases I think such code is better off in C or Rust.
In the enterprise C# is the way to go. You won't find many Fortune 500 companies, with offshoring projects, going F# instead of C#.
For many 9 - 5 developers, C# is already too complex, many of each are ex-VB developers.
F# lacks the Visual Studio tooling support for the typical enterprise projects workflow and frameworks.
Usually it is C++ > Java > C# > VB.NET > .... in the Fortune 500 world set I work on.
Not to mention the C++ salary rates in High Performance Finance and High Performance Computing in general. I doubt any C# developer would get those rates.
It is a pity. I did do some C# work but preferred writing C++ hence I do it as a day job now (and a sideline for fun too!).
Even Java jobs are offered for more than C++.
Clearly not all places are equal. :)
I did C++ for many years, was on the C++ side since day one on the C vs C++ wars, since 1993.
Nowadays mostly Java, C# on the job. C++, among others, mostly on hobby projects.
Given my Turbo Pascal initial background I still prefer more memory safe systems languages though. Although modern C++ surely feels good.
Ideally, a "work from home" remote job would suit me where I get to write C++ all day. Know anyone offering such a delight?
What hobby projects do you write? I am working on a scheduling system.
Not much nowadays, as family and friends take most of the time.
It's impossible (and foolish) to avoid C# if you develop for Windows, but I haven't written a single line of C# since 2004.
Anything complex may still hit some issues, though this might not matter much in the future as ASP.NET vNext will fully support Mono.
Wow. Really impressive -- our MSBuild hackery is gut-wrenching.
I got pretty far into building an MVC project that I have been working on for a long while in Windows.
I had to manually run the NuGet package restore command, as I couldn't see a way to enable package restore for the project. I set EnableNuGetPackageRestore=true preceding the command and it installed all the packages successfully.
I have run into a roadblock with a MSBuild TypeScript target however. The error message wasn't very telling but I'm assuming it's because it can't find the TypeScript compiler.
The exception is when you're dealing with a very high transaction rate (say, doing 100K msg/sec, non-trivial processing per message, in a single process). Then the GC overhead is something to be aware of, and you'll go to extreme lengths just to remove a handful of allocations for each message. At that point, manual memory management (either via hacking up the runtime with unsafe code, allocating large arrays of structs, or using unmanaged code) is the right path. But from light reading, it seems the same is true in Java or other GC languages, so no difference for Mono there.
So the alternative is C, usually, which has its own set of tradeoffs. Rust looks far more promising, but in general, Mono's performance is just good enough that I'm more likely to keep my nice F# code and add a few boxes. Unless you're in a high-performance arena, and you'd know if you are, this likely holds true for your business.
Edit: Also, I'll note we're using Mono 2.10. So updating to 3 should get us the new GC which may make a difference, as well as allow LLVM code, which should help significantly for server apps.
All critical code is F# on Mono and CLR. Each voice-handling machine makes an HTTP request to a CLR process to get routing instructions, then the results of the call are handed off to a Mono process, which protobufs stuff into a local RabbitMQ instance, which gets shoveled into billing, analysis, etc.
Lots of "XML", as that's FreeSWITCH's preferred format (it's not real XML, but a psuedo-XML with inane encoding rules, for some reason). This is the cause of at least 20% CPU time when handling call records.
In general, scaling out by adding a few more machines to the mix is so easy we're not really pressed hard to make things go faster. But it's certainly fun to do. I'd guess we can improve many pieces up over 100% without doing anything really tricky.
As a comparison, I know of at least one successful competitor that has everything in PHP. Every call creates multiple processes and multiple (10+ sometimes) DB queries. Their entire scale-out process is to throw hardware at things. At one point they had over 100(!) servers just to hold call records (maybe 100M a month?). Inefficient? Hilariously so. Did the primary owners get rich from it? Absolutely. Engineering quality counts for surprisingly little, when it really comes down to it.
One nice thing using Unity/mono enables for us to use the same game logic code from client to backend.
I've been following Supernauts since you released in December. PM me.
To put their language into Mobile, OSX and Linux.
Also, as pointed out elsewhere in this thread, Java has a colossal momentum in just about every space outside Microsoft's sphere of influence. It would seem Oracle is trying, but it'll be very difficult to kill Java.
Besides, it's not a bad language, if you avoid the most common anti-patterns.
As for the whole Oracle vs Google, Google was the one trying to avoid paying for J2ME licenses.
James Gosling mentioned on his blog that Sun did not sue due to lack of money.
We quickly forget the technologies we don't see in front of us. It's been 3 years since I wrote my last line of Java code for a web application. I wouldn't choose Java for the kinds of application I am doing.
It is not like Google is a poor startup trying to get some product out of the ground. Maybe they even have paid more to their layers as they would have paid in licenses.
If it was right for Microsoft, it should be for Google as well.
As for choosing Java or not, there are lots of areas in the industry right now where the JVM is the only game in town, as I mentioned in another thread.
The companies with money outside FOSS freebies, don't care about this.
Java makes sense for some applications, probably not for what you're doing. I mean if you want to pick a stack on the server (not talking about websites) that's in wide use, has a big pool of programmers to choose from and capable tooling what can you pick? Java and .NET pretty much and the latter is getting super-expensive as many here will testify.
Sun was a company, not a charity.
As it is now we are already at a point not that many people are willing/eager to learn Java. Push it further and it becomes COBOL.
It's not about what Google did. It's about whether it benefits the Java ecosystem or not.
Maybe the hipsters. I see no shortage of Java developers around here.
For the last couple years, all Java code I wrote was intended to run on Android devices. If it weren't for Android, I'd have no reason whatsoever to bother doing it.
You mean Bluray licenses, Smart cards, embedded devices, car infotainment systems, radio controlled temperature meters, factory assembly line controllers .... ?
> For the last couple years, all Java code I wrote was intended to run on Android devices. If it weren't for Android, I'd have no reason whatsoever to bother doing it.
I take you don't work in the enterprise world, then.
Do you have the numbers? For me, smartcards excepted, all those things based on J2ME are on their way out.
Unless Xamarin starts supporting all the platforms out there with Java compilers and JVMs available, that are currently out of scope for them:
- BlueRay players
- Temperature controllers with network capabilities
- Programmable smart cards
- Robotics like JamaicaVM
- Real time systems like Atego Perc
- Car infotaiment systems like JamaicaCAR
- Mainframe systems like OS/400
- Microcontroler systems like MicroEJ
This is a very small sample where you can find Java code running.
Maybe it would be even better if they were to open source just the .NET runtime and core libraries in order to cut down on the workload that both companies have to put into maintaining their own separate versions of the core platform. But there's also something to be said for friendly competition and having two different groups working on their own innovations.
It's quite possible to have a new Linux distribution up and running on VirtualBox in under an hour, or in a chroot under an existing Linux installation.
Thanks
Is Ubuntu supported? Where do Linux users other than OpenSUSE users get packages? Do they build it themselves?
It's not too hard to build, but it does take an age on a non-ssd machine.
One of the early outcomes of this are CI packages built for each commit: http://www.mono-project.com/DistroPackages/Jenkins
"Yawn... what is out? Oh yeah, I think I heard of that..."
If Xamarin should care about VB.NET, it should be better at things than C# is.
But if anyone cared, they would do it. No one cares, so it does not get done.
Use majority tools or deal.
Disclaimer: Am a C# programmer and haven't used VB.net in a few years.
It used to be that VB.NET's late binding features made interacting with COM objects way easier, but C# sorted that out when `dynamic` came along.
Now the only difference that I'd say is really substantive is C#'s unsafe blocks. However, I should immediately follow that up by saying that in the past 5 years I think I've written a grand total of one unsafe block that turned out to be a keeper, and the only reason I'm not embarrassed to admit that I even bother with unsafe blocks is that I have no shame.
"Optimising your notation to not confuse people in the first 10 minutes of seeing it but to hinder readability ever after is a really bad mistake."
David MacIver, writing about Scala: http://rickyclarkson.blogspot.co.uk/2008/01/in-defence-of-0l...