jinaldesai.net
It is a fantastic tool in many cases where a null is much clearer than something like -1 to denote a missing value.
However, I can see the issue with some developers using nullable types for everything. But any sufficiently powerful/flexible tool is always going to be misused by some.
(I have a the same opinion about goto and operator overloading; clearly the folks at Microsoft agree with me here.)
No More:
Check.IsNotNull(objRef, "stop being a muppet");I agree, allowing a nullable wrapper around a (already inherently nullable) reference type would be a horrible misfeature. What language was that?
The only exception is Java, where everything is basically frozen after release and cannot ever be changed anymore.
Most of the time, targeting a newer version in Scala is just a recompilation away, like on .NET. So if you are good with .NET, you should be good with Scala, too.
Mono admittedly lags a bit behind Microsoft's implementation of the platform, but that's mostly a question of resources. If Mono had been embraced by the open source community the way Java has been (as it should - see previous paragraph), then that wouldn't quite be the case.
Though not by much, and not in all respects. That crew is doing some really great stuff.
I'd like to see more attention paid to it as well.
[1] http://www.phoboslab.org/log/2012/04/javascript-on-the-xbox-...
Mono is a real alternative, many businesses run it production, including the likes of Fog Creek.
Enterprisey is a matter of perception and shouldn't be a slur.
I actually work at a .NET startup doing non-traditional things with .NET and we have the hardest time hiring new developers because of the "enterprisey" nature of .NET and the type of developer that generates.
For those not in the know, you just need to add an async to the front of the method and then put in await on whatever operation is going to take a while.
You can literally take synchronous network code modify a few methods and get 100x the throughput.
A few methods? Visible async taints, always (think haskell monads, because that's pretty much what it is), you have to convert the complete dynamic scope leading to those newly async method or it'll never work correctly.
It's more than "a few methods" unless your system is absolutely trivial.
So no, you literally can't do that, let alone literally.
Not to mention, `async` marks the method as asynchronous, it does not make the method asynchronous:
> put in await on whatever operation is going to take a while.
That operation also needs to be async itself, and ultimately it needs to be implemented as running on a separate execution queue. At the very least, this means wrapping "whatever operation" in a `TaskFactory.StartNew`. Not just adding an `await` to synchronous code.
Ultimately, `async` and `await` still are nothing but sugar over the Tasks API.
Personally, I haven't had the time to really sit down and play around with both to see how I feel about code legibility and maintainability between the two techniques.
Are you aware of any extra functionality gained by marking methods async? It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods.
As far as I know there isn't any, the gain is in code readability/simplicity from the POV of an imperative developer: async/await are hints which the compiler transforms into CPS by thunkifying code following an `await`. According to Eric Lippert's series on async/await[0], the compiler also performs complex code generation to try and make try/except blocks behave "sensibly" in this imperative-looking code. While necessary for the coding style, I still am not sure whether that's an advantage or a drawback of async/await.
> It seems the new markup is more useful for frameworks. Think async action methods on controllers for mvc rather than your own little methods.
Technically, from outside the method `async T foo()` is no different from `Task<T> foo()` I believe, it's only the internal detail which change (mostly composing async callees and returning the result of an async chain). On the other hand (again this is something drawn from Eric's post) alongside async/await the framework team will add new APIs the Tasks API set, one of them being "multiplexing" of tasks (waiting for all tasks of a set of tasks, or any task of the set, although I'm sure the community has already implemented that separately)
https://github.com/koush/node/wiki/%22async%22-support-in-no...
What are those?