> What's wrong with being explicit in casting?

Nothing, but why do we need more syntax for it? That's my real complaint with Swift - lots and lots of one-off syntax in places where it didn't seem to be needed. What's wrong with:

var view: NSView = (NSView)anyObject

It's just as explicit, yet this uses familiar syntax that everyone already knows and uses. For that matter, why did they decide to use this syntax:

var view: NSView = (NSView)anyObject

When:

NSView view = (NSView)anyObject

It exactly the same in terms of expressiveness, yet is using a syntax that we're already familiar with? Does adding var really make the code more clear? I certainly don't think so. And the colon? Really? I know the answer already, it's because they picked language X as their model rather than language Y, which is *precisely my point*. Generally if you're going to introduce a new language you have exactly one chance to get it right, and I can't say I'm at all pleased with v1.0.

> No header files confuscate

Ugh. More inside-the-box thinking. You don't need header files to do this right, which is your implication, and ideally you want more than one API for another. Dylan, yes, *Dylan*, did this way better than any language I've seen since. You could have a private API, a public API, a beta API and a release API all from the exact same code.

While it's true that using headers makes certain aspects simpler for the compiler author, it's also true that it pushes that work onto the end user - you - by forcing you to keep your headers up to date with manual edits. One could semi-automate this, but that's precisely the purpose of public/private. I have yet to see a real-world use-case where public/private didn't work.

> you are still exposing your entire class code and layout to users of it

How is that?

> presents itself as a WebDAV option

Lolz. And you get to it using a QR code!

> world in which a man is judged by the bullets on his resume, not by the knowledge in his head

This world, then.

I suspect than one adds transit to the mix, the headline is rather misleading.

By this means, Canada has met this goal since electricity was commercially available (53% of our electricity is hydro, alone).

> solar panel that has a quantum efficiency of around 40%

Conventional panels have a QE around 90%. That's why they're opaque.

"As a result, is nuclear going to be acknowledged as the future of energy production?"

Ummm, no.

As long as NG peakers are $1/W CAPEX and ~2 cents OPEX, nuclear is as dead in the water as it is today.

For comparison, the average price for nukes in the western hemisphere is about $8/W and ~5 cents OPEX.

> They come with free overheating problems. Solar panels need the airflow behind them to keep cool

Using conventional Si cells, yes. Using CdTe, CIGS or other thin-film tech, no. Which is why...

http://www.myplant.com/doc/solar-pamphlet.pdf

> "about 10 cents a watt..."

Watt hour. So would you like you re-state your invective in light of that mistyping on my part?

Here, I'll just point you to the calculator so you can do it yourself... http://www.nrel.gov/analysis/tech_lcoe.html

Any estimates on how much power will be needed to run the crypto so a bunch of static web sites can put an S in the URL?

> Client-side code (WPF) in .NET is utterly dependent on DirectX

Which is why they...

1) allow you to use the platform's native UI, and...
2) developed the new "modern" UI that has no (or few) such dependancies

> That's being either mistaken or misleading.

Really? Huh. You see, I'm on the Mono dev list, and they're all saying the exact opposite. "They" including Miguel de Icaza, of course. I think I'll take his word over yours, AC.

> People don't just want to write websites with C#

That's a weird statement. Who cares what they "want"? I know lots and lots of people doing C# websites whether they want to or not.

> It was easy and I will never come back

Here too. And when you see comments to the contrary, it's always got something to do with it being OSS. "It's slower, and not OSS". But it's not slower, and now it is OSS. It's like listing to people try to convince me that vaccinations are bad for you, you wonder how they can stare bald facts in the face and then say the opposite is true.

> sticking to Xamarin's toolset

Which, unfortunately, is a serious subset of Mono. I found that every program I tried to port used some code that wasn't supported, and most of our code simply does XML file handling.

Actually, it's difficult to even tell what you have due to MS's totally bizarre naming practices. Why is System.IO.Packaging, which deals with ZIPped XML files, part of WindowsBase? It's practically impossible to go from a namespace to the assembly that contains it. This has always bugged me.

> Even the bloated Eclipse is faster than VC++ on Windows - at least if you run Eclipse on Linux

I've run Eclipse on OS X, Windows and Linux. None of those are *remotely* as fast to work with as VS. The fact that Google is trashing Eclipse in favour of Android Studio is proof positive of the problems with Eclipse, and the compile-to-the-metal that both MS and Google are adopting is an indictment of the entire byte code regime, IMHO.

I've also used Xcode and VS head-to-head, and VS is definitely the superior platform. Although Xcode offers many of the same features, and outright superior GIT integration (it's like two clicks and one url to get it working), the indexing system is completely broken so you can't even do things like "find all references". When running one of the CLR languages the superiority of VS is magnified through on-the-fly compiles and such. Xcode claims to offer this, but it's horribly broken, and the late-stage operations like code signing and packaging make it a moot point anyway.

I don't know if you'll ever *really* be able to write iOS apps on VS, but if that day comes, I'd switch in a heartbeat.