Generic code working with reference types can be shared, but passing structs for generic parameters forces JIT compiler to generate separate instances of generic methods or classes for each combination of structs. From there inlining becomes trivial. But yes, being able to pull stuff like this is one of the cooler parts of .NET.
That's a little bit too harsh. The solution is a no-brainer if you come from C#/Javaland, but if you don't... well, we get a nice illustration to the saying that "there are no stupid questions".
> The answer is not just "var" because you have now completely dismissed local variable immutability (something C# does not have)
It is something that C# does have. It just doesn't allow immutable variables to be implicitly typed, i.e. you can't write something like "const var x = 0;" This lack of let or val in C# is a reminder that "var" was introduced in the language not just to reduce visual clutter, but to support anonymous types, which were in turn introduced to greatly enhance LINQ experience allowing for such nifty feature as "let" clauses in query expressions...
> Autocratic states ultimately can't work with democratic ones. Its unfair to expect one group to 'follow the rules' and another to go off willy-nilly when it serves them.
Libya's "no fly" zone, Iraq, Kosovo, nationalistic coup against a democratically elected president.... etc etc etc
I don't even what to say when reading texts like this. It's like democracy is the racism of the 21st century. White infallible democrats versus autocratic niggers.
From the description, almost 90% of created tasks in this benchmark are tiny "leaf" tasks, which are quite likely to be optimized away completely. So it looks like the benchmark compares how well these compilers optimize one particular case, and not general performance of goroutines/tasks/whatever...
"Fourth, the causes espoused by Mr Litvinenko – such as the FSB’s alleged responsibility for the apartment bombings, the war in Chechnya, and alleged collusion between President Putin and other members of his administration and organised crime – were areas of particular sensitivity to the Putin administration. "
"Finally, there was undoubtedly a personal dimension to the antagonism between Mr Litvinenko on the one hand and President Putin on the other. The history between
the two men dated back to their (only) meeting in 1998, at a time when Mr Putin was the newly appointed head of the FSB and Mr Berezovsky and Mr Litvinenko still hoped that he might implement a programme of reform. In the years that followed,Mr Litvinenko made repeated highly personal attacks on President Putin, culminating in the allegation of paedophilia in July 2006"
That is from the report. Call me a Putin-apologist, an agent from Olgino, but these motives look like garbage. There is an entire industry of "making highly personal attacks" on Putin and blaming all kinds of things on him. The name of these "Putin's critics" is legion, they have been doing it for more than a decade, and they've had zero success... that is, of course, if by "success" you mean making Russians believe what they say, and not just selling shocking stories about the darkest secrets of the KayGeeBee to British tabloids...
I'll go with "Putin-apologist." Why act like pointing out an obvious motive is the focus or even a main point of the report? What about substantive points like:
"Traces of the isotope were later found in many of the same places where the two alleged killers had visited: The hotel's bathroom, their hotel room, a board room where they conducted an earlier meeting and the plane they traveled aboard."
We're not talking about traces of carbon or lead, here.
Of course not, Putin is not an idiot and wouldn't leave a trail to him after ordering someone killed on British soil. There is no doubt about Lugovoy or Kovtun's involvement, but directly or indirectly Putin is responsible for his agents running around poisoning people with polonium (edit: not plutonium!). The fact they are refusing to extradite them is telling as well.
>Putin is not an idiot and wouldn't leave a trail to him after ordering someone killed on British soil.
Perhaps but that's not evidence.
>There is no doubt about Lugovoy or Kovtun's involvement, but directly or indirectly Putin is responsible for his agents running around poisoning people with plutonium.
That's not evidence either. Besides, they were ex-KGB / FSB agents.
>The fact they are refusing to extradite them is telling as well.
Let's reverse this. Would Obama agree to extradite a Republican ex-CIA agent with powerful friends who flew to Moscow and killed Edward Snowden without his knowledge?
Can you imagine what the political fallout would be if he did? He'd be characterized as a mixture of powerless, hypocritical, traitorous and anti-American all at once by both friends and enemies. Political suicide at worst; own goal at best.
"Why act like pointing out an obvious motive is the focus or even a main point of the report?" Because this motive is quoted in articles to link this crime to Putin. I certainly don't care about Lugovoi, Kovtun, their motives, was it even a crime and not an accident, involvement of the British secret services etc. etc. Britain should have known better when it welcomed all the dirty money from Russia...
Let's be real here, a minuscule proportion of critics die. The vast majority are ignored and a few get sent to prison for some crime they may or may not have had any hand in.
The motivations described are certainly insufficient to withstand scrutiny.
And who killed Paul Khlebnikov in 2004? He was a Putin-apologist and chief editor of Russia Forbes. Unfortunately, a lot of journalists die in Russia every year, and has been for the past quarter of century. Cherry picking some of them proves nothing.
There is no way to allocate objects of reference types on stack because references can easily outlive objects, leaving you with dangling references.
And as I understand ByVal in VB.NET is redundant since it's the default option. It's just a leftover from VB6 where the default was ByRef. Crazy language.
> There is no way to allocate objects of reference types on stack because references can easily outlive objects,
That's simply due to a lack of analysis. In many cases it's easy to show the object is short lived. Yet there's no way to annotate this and AFAIK, the JIT doesn't even try to figure this out.
Huh, author even uses exceptions as a part of normal workflow, instead of checking if "previousVersions" list is empty before calling Min on it he instead catches InvalidOperationException. I don't want it to look like an ad hominem argument, but...
Anyway, C# authors had Java in sight when designing the language and after some contemplation they didn't include checked exceptions in the language. And their main argument is that in the vast majority of cases ignoring the exception and allowing it to propagate further up the stack is exactly what you want to do, simply because there is nothing you can do about it but to log it and tear down the entire object graph or write an error message to the user.
> propagate further up the stack is exactly what you want to do
This is an important point imo. It is actually one of the ways you can describe to a non-programmer why it can be so hard to write typcial desktop software which never ever crashes (as in 'unhandled exception' dialog): huge amounts of time would be wasted to figure out for each and every single statement what can go wrong and how to handle it. Seriously, I've been at meetings where more time was spent on discussion on how to deal with/present to the user some obscure once-in-a-lifetime error than on actually fullfilling requirements.
I have a desktop app that has a single exception handler at the event loop. It's amazingly robust. That file you're trying to save is locked? Network location went away? Doesn't matter. It displays the error in a dialog box (so you know what went wrong) and returns the user to the app. Whatever operation they were doing, they can just try again. Any cleanup is performed automatically and the application, without really any effort, is always in a stable state.
That's how exceptions are supposed to work. The wack-a-mole attempt at ensuring you "handle" every case is wrong.
The problem, in my opinion, is that most programmers have been so brain damaged by Java that anyone exposed to that way of programming can't see how exceptions are supposed to work. Java not only makes you try/catch/declare everything but also makes you use exceptions for non-exceptional operations. A perfect storm.
