Turkish Kurdophobia

The hatred that Erdogan and the Turkish nationalists (hence, most of the Turkish population) feel for Kurds, Kurdophobia is almost unlimited. They hate any Kurd that considers himself a Kurd, regardless of whether he is a Socialist or not, regardless of whether he is a Muslim or an atheist. From the ultra nationalist, islamist point of view of an Erdogan supporter it's easy to understand their hatred for the Kurds living in Turkish soil. First they wanted an independent country, then they lowered their demands to just some basic autonomy and the respect of their culture, but anyway that is an insult to the sacred Turkish nation. For these Ottoman beasts that consider Turkey a sort of divine entity, the fact that someone wants to break away from such a "magical entity" is an insult, an affront. If furthermore those people a left leaning and not particularly religious (many kurds in Turkey are "soft muslims" or even not religious at all), they consider that their hatred is more than justified...

For decades Turkish nationalism has denied the existence of the Kurdish people. Furthermore they don't only attack and oppress the Kurds inside the fictitious Turkish borders, but now particularly the ones in Syria. This is pure ethnic hatred, the same hatred that led them to perpetrate the Armenian, Greek and Asyrian genocides. This hate and detestation is what has pushed them to ally themselves and sponsor the jihadists that torture, rate and mutilate Kurdish female fighters.

For sure this goes far beyond the nationalist need of protecting the "Turkish national unity", and I think it could come from the fact that Kurds have been living in those lands from much, much before the Ottoman invasion. The Kurds, same as Armenians or Persians, have been around the region for many, many centuries before Christ (4000 BC?). On the other side, Turks are a central Asian people, and they did not invade and settle in Anatolia until the 11th century AD. I assume most of the Turkish population are not full descendants of the Central Asian invaders, they are the Anatolian people that were colonised, accepted the culture of the invaders and maybe mixed with them, renouncing to their own culture. On the other side the Kurds kept their culture and identity alive, so one could think that the Turks have a hidden complex of inferiority with regards to the Kurds.

We all descend of migrants, so for sure our right to live in one territory has nothing to do with how long ago our ancestors got there, but such antiquity plays a role in to what extent we can consider that we are a "nation" and you are not. In that sense, the Kurds are a nation, and the Turks in nowadays Turkey are either descendents of the recent invaders that destroyed the Byzantine Empire or descendents of the natives that assimilated the culture of the invaders. I think for Turks the denial of the existence of a Kurdish people is a way to defend the legitimacy of the invasion and surrender of Anatolia and Thrace. If we applied to the Turks the same logic that has been applied to Europeans regarding colonialism, we could say that nowadays Turkey is just a colony, that all Turks of Central Asian origin living there should be expelled back to Central Asia and "the natives" should reject the imposed Turkish culture and recover their previous identity.

Well, I'm not asking exactly for that... just asking Turks to go fuck themselves and allow Kurds to do whatever they want with their destiny.

BIJI BERXWEDANA ROJAVA! BIJI KURDISTAN!

Await for completed/resolved Task/Promise

This post is complementary to this one. I've come across another difference between how async/await works in .Net/Javascript, awaiting on an already completed/resolved Task/Promise.

In C#, if you do an await on a completed Task (for example you've created it already completed with Task.FromResult), the code will continue synchronously, there is not a "jump outside the method that will be continued later". Oversimplifying it, we could say that the ContinueWith method invocation that the compiler creates under the covers checks if the Task is already completed and hence decides to call the continuation delegate in sequence. Let's see an example, notice how while in DoAsync1 there is no "jumping out", everything runs synchronous, in DoAsync2 we have the "jump out and continue later" behaviour:

static async Task<string> DoAsync1(string st)
{
Console.WriteLine("DoAsync, before await");
//Task.FromResult returns an already completed Task, this gets immediatelly and there is not an interruption of the current method and later reentrance
var res = await Task.FromResult(st.ToUpper());
Console.WriteLine("DoAsync, after await");
return res;
}

static async Task<string> DoAsync2(string st)
{
Console.WriteLine("DoAsync2, before await");
await Task.Delay(500);
Console.WriteLine("DoAsync2, after await");
return st.ToUpper();
}

Console.WriteLine("started");
Task<string> task =  DoAsync1("hi");
Console.WriteLine("after calling doAsync1");
Console.WriteLine(task.Result);

Console.WriteLine("---------------");


Console.WriteLine("going on");
task =  DoAsync2("hi");
Console.WriteLine("after calling doAsync2");
Console.WriteLine(task.Result);

// started
// DoAsync, before await
// DoAsync, after await
// after calling doAsync1
// HI
// ------------------
// going on
// DoAsync2, before await
// after calling doAsync2
// DoAsync2, after await
// HI

In Javascript the behaviour is different, even if the Promise is already resolved (Promise.resolve("a")), the "jumping out of the function" takes place anyway. Let's see an example. The behaviour of test1 and test2 functions is the same, in both cases we have that the "after invoking" runs before than the "after await" :

async function test1(){
 console.log("test1 before await");
 let res = await Promise.resolve("hi");
 console.log("test1 after await");
}

async function test2(){
 console.log("test2 before await");
 let res = await new Promise((res, rej) => {
  setTimeout(
   () => res("hi")
   , 1000);
 });
  
 console.log("test2 after await");
}

test1();
console.log("after invoking test1");

test2();
console.log("after invoking test2");


//test1 before await
//after invoking test1
//test2 before await
//after invoking test2
//test1 after await
//test2 after await

Ethnic Cleansing in Afrin

For a while we've been hearing everywhere that ISIS/Daesh were defeated, that they were over. This was almost true, and the main actors in this victory have been the Kurds: the Kurds from Irak and particularly the Kurds from Syria (the heroic YPG/YPJ). Sadly, today ISIS/Daesh has won a battle and is conquering territory again. Along with the Turkish army and with the passive support of Rusia (that has allowed Turkey to enter the Syrian-Kurdish airspace to conduct airstrikes that included hospitals) they have captured Afrin, expelling the YPG/YPJ forces and causing the exodus of most of the Kurdish population, fleeding for their lives.

You could say that I'm lying, that it's not ISIS, but the FSA, the "Syrian rebels" who have invaded Afrin. Well, that's the name they are using, but names aside, they are a conglomerate of different Islamist factions put together by Erdogan. Some of them come from Al-Nusra, many of them from ISIS, some of them from whatever stupid name a bunch of Islamist beasts had decided to use. You can read it here

One former Isis soldier has told the journalist Patrick Cockburn: “Most of those who are fighting in Afrin against the YPG are Isis, though Turkey has trained them to change their assault tactics.

The thing is that they are all Islamist scum seeking revenge against those who had managed to defeat them before, thirsty for the blood of anyone that does not adhere to their vision of Islam (and Kurds are either moderate muslims or non religious). The Kurdish population is at serious risk of being slaughtered by these Islamist rats. Will we see again images of Kurdish/Yazidi women being sold as slaves? To what extent the ethnic cleansing orchestrated by Erdogan will be conducted? Will it be enough with just expelling the Kurds of the territory or will they be massacred? Turks really excel at conducting genocides, this, along with invading, looting and the slave trade are the main contributions of the Turkish people, the Ottoman beasts, to Human History.

You really must read this article, and this other one clearly explains why the Kurds had no chance to resist this invasion and talks about what can come next. This one has almost made me cry.

Once againg the Kurds have been betrayed and abandoned by the West, that has closed its eyes to these tragic events. I think now they have to be ready for the next treason. The DFNS seems like a risky bet to me. I think Kurds should not trust Arabs (well, nobody should trust Arabs), and of course they must not trust Turkmen, they should abandon the idea of this democratic confederation with them. The YPG/YPJ should concentrate their forces in the northern part of the region, where they are the majority, and not allow Arab/Turkmen forces to be there. The only armed forces in the Northen part of of the region should be the YPG/YPJ and the Assyrian militias, and be ready for an attack both from Turkey or from the Arabs.

Outside Syria, Kurds have to be ready and willing to war. I'd love to see Turkey pay for what they have done. I'd love to see each YPG/YPJ martyr killed by Turkish forces or Turkish sponsored yihadist be avenged, 10 Turkish soldiers for earch Kurdish (or international brigadist) martyr, 10 Erdogan supporters for each Kurdish civilian. Anyone that supports the war of the Turkish Islamist state against the Kurds both inside and outside Turkey is guilty. Any Turkish Nationalist that supports Erdogan is in the end an ISIS supporter and is guilty of raping and selling women as slaves, bombing hospitals and cutting throats...

The Turkish Nationalists feel pretty safe because unfortunately they are the majority both inside and outside Turkey. For example in Germany there are 3 million people of Turkish descent for 1 million people of Kurdish descent. For sure some of these Turks have become westernized and condemn the Erdogan Islamist crap, admit the existence of an Armenian Genocide and recognize the right of the Kurdish people to take control of their future... but unfortunately many of the German Turks are Turkish nationalists, Islamists, ignorant beasts... and hence they are the enemy. Of course you have to add to their ranks all the Islamist scum that has invaded Europe. The war between Turkish fascists and Islamists against Kurds in European soil is just waiting to start, and Kurds, given that they are weaker in numbers must be stronger in skills. Kurds have been the vanguard of the fight against the Islamist scum in Levant, now they must be it in Europe now. They have the courage and determination that us, the Europeans "de souche" lack. The Kurdish youth in Europe should be ready for this war. I'd love to see them organizing and training, gathering weapons and setting up underground training facilities. Last weeks have seen some attacks in Germany against Turkish "cultural" centers, mosques managed by the Turkish government, businesses... I hope this is just the beginning, I'd love to see them grow in quantity and quality. I'd love to see how the Islamists that poison our streets are fought and "neutralised", I'd love to see their indoctrination centers burnt to ashes. I'd love to see those Turkish nationalists that after having lived for decades in Germany still consider themselves 100% Turkish and 0% German... to fleed back into their Anatolian paradise... The fight for Kurdish rights and the fight for keeping Europe the land of humanism and freedom must converge as we share targets and enemies.

I've been on the verge of crying when reading about this young British International Brigadist killed by a Turkish airstrike.
Glory to Martyrs, Heroes never die.

Async Await Comparison

I think the async/await pair is one of the most "revolutionary" features added to programming languages in the last years. I have to admit that when they were added to C# it took me a while to wrap my head around them, same as with the yield statement. Both cases come down to the same, a method that gets restarted at an intermediate point, a continuation, it seemed like magic until I understood all the compiler magic involved... Hopefully, the way async/await behaves in JavaScript is pretty similar, so most of the tricks you learnt in C# apply also in JavaScript, but there are some subtle differences. I'll write down here some notes on similarities and differences that I guess I'll be revisiting from time to time.

As you know async/await revolves around Tasks in C# and Promises in JavaScript. If we want to return a Task/Promise from an already existing value rather than from a really asynchronous operation (for testing for example), we can do like this:
C#: Task.FromResult("hi");
JavaScript: Promise.resolve("hi");

The previous feature is particularly useful in C# for testing. In C# you can only await for a Task, so easily creating a Task from a value can be pretty usefult. I thought it would be the same in JavaScript, but to my surprise I've realised that in Javascript you can await for any value, I mean, these 2 lines are equivalent:
let res = await Promise.resolve("hi");
let res = await "hi";

In both languages, marking a method/function as async means that the compiler magic will create a Task/Promise as soon as the method is invoked and that Task/Promise will ultimately contain the final result returned from the function or the exception thrown from it. Even if the exception is thrown before any call to await happens in the function (so it's running synchronous), it won't be available until we await for the function.

async function throwExceptionAsync(st){
 throw {message: "crashed"};
 return st.toUpperCase();
}

console.log("calling throwExceptionAsync");
prs = throwExceptionAsync("hi");
//I get here, so the exception has been wrapped in the promise
console.log("after calling throwExceptionAsync");
console.log(prs.constructor.name); //Promise
//I get the exception in the await 
try{
 res = await prs;
}
catch (ex){
 console.log("exception: " + ex.message);
}


//output:
calling throwExceptionAsync
after calling throwExceptionAsync
Promise
exception: crashed

There's a difference that I found when checking this question in stackoverflow. As I've just said, the compiler automatically creates and returns a Task/Promise for any async method. In JavaScript this Promise will resolve to the value that the function returns, and in C# we'll have a Task<Result> (or Task if the method returns nothing). This means that the code that we write in our async method must return a value, not a Task/Promise of value (as the compiler itself takes care of creating that Task/Promise). This means that in C# we have this:

private async Task<string> GetContentAsync(string url){...}

private async Task<string> FormatAsync(string url){...}

//this is good
public static async Task<string> FormatUrlContent(string url)
{
 string content = await GetContentAsync(url);
 return await FormatAsync(content);  
}

//this is not good, it won't compile:
//error CS4016: Since this is an async method, the return expression must be of type 'string' rather than 'Task<string>
public static async Task<string> FormatUrlContent(string url)
{
 string content = await GetContentAsync(url);
 return FormatAsync(content);  
}

The second method won't compile because our code is returning a Task<string>, that would get wrapped in the Task that the compiler automatically creates, so in the end we would be returning a Task<Task<String>>.

In JavaScript I was not expecting an error, just that we would get a Promise that would resolve to another Promise that would resolve to a string, but to my surprise the compiler seems to take this into account and returns a Promise that will be resolved when the internal Promis is resolved (so indeed it's doing the same as it does with a call to then that also returns a promise.

async function anotherAsyncMethod(){
 return Promise.resolve("hi");
}

prs = anotherAsyncMethod();
console.log(prs.constructor.name); //Promise
res = await prs; //this is already the string not a Promise of string
//console.log(res.constructor.name); //String
console.log(res);

There's another difference that I'd like to mention, though it's not about async/await, but about Tasks/Promises. In C#, if you want you can block your code (which in general is quite a bad idea) waiting for the result of the async call, by doing either Task.Wait() or Task.Result. In JavaScript, promises lack any blocking method, you can only access the result in a callback function provided to then() (or obviously through await magic.

Asp.Net Core Pipeline

I've been playing around with Asp.Net Core 2 for a while and I pretty like it. Following the examples you can start your application with a few lines of code, as seen here, but what these lines are doing is a real lot and I wanted to get a better view of what's really going on.

In the end we can think of any asp.net core application (the .dll or .exe that we end up with) as a selfcontained web application made up of 3 main components:

• A Web Server that takes care of receiving http requests and sending http responses
• "Our application itself" (our controllers and so on) that processes that request and generates a response.
• The framework code that communicates both components. The communication between these 2 components involves a Request Pipeline where different middlewares are hooked (think of these middlewares as equivalents to HttpHandlers in classic ASP.NET). MVC is one of those middlewares (Websockets is another possible middleware).

Asp.Net core comes with 2 web server components, the multiplatform Kestrel and the Windows only http.sys, but you can implement your own. Reading this excellent post about that, has quite helped me to better understand the different classes involved.

First of all we have an IWebHost. This IWebHost hosts the whole application and is its starting point (IWebHost.Run). We have to tell the WebHost what Web Server to use. We usually do this via the IWebHostBuilder UseKestrel or UseHttpSys extension methods. From the linked article this seems to come down to adding an IServer implementation to the Services collection (the default IOC container). The IWebHost will take care of calling the IServer.Start method, passing to it an IHttpApplication. Then the Web server will be calling IHttpApplication.ProcessRequestAsync with an HttpContext to process requests. What comes to mind is that this ProcessRequestAsync should be starting the processing in the chain of middlewares.

We have set up the chain of middlewares in our Startup.Configure method. This method receives an IApplicationBuilder where we invoke different Use methods to add middlewares. The part that was confusing me a bit is that IHttpApplicationBuilder.Build does not return an IHttpApplication, but a RequestDelegate. This RequestDelegate represents the Request pipeline with all its middlewares. So the IHttpApplication is the glue between the IServer and the RequestDelegate. When trying to figure out this I came across this excellent article that so well describes what I have been trying to explain in this post :-)

TypeScript Inheritance Oddities

In addition to Structural Typing, TypeScript provides some other surprising features (that indeed make sense in part thanks to this Structural Typing).

In "conventional" languages (C#, Java) inheritance is based on this idea:

• Classes extend classes
• Classes implement interfaces
• Interfaces extend interfaces

In Java we have the extends and implements keywords, in C# it's just a matter of vocabulary (we just use ":" for inheritance, both for extending or implementing).

TypeScript comes with 2 surprising features.

• Classes can implement classes
• Interfaces can extend classes

I think the idea is that a class can be used as an interface, so it seems to make sense that another interface can extend it, and a class can implement it.

Notice an important detail, while a class can extend only 1 class (so it follows the JavaScript logic of "class to class" single inheritance), an interface can extend multiple classes.

I've checked some stackoverflow discussions and the TypeScript documentation dealing with this topic, but I'll write down here my personal vision on how these feature can be useful.

A class implementing another class (rather than extending it)
As the class implements rather than extends, it's not inheriting the method implementations from the parent, so it will have to implement all those methods on its own (so the parent class is behaving like an interface for you). If you are going to inherit from another class but planning to implement all the methods, using implements rather than extends has a semantic value, it makes it clear that you are not reusing anything from the parent class. In a way this is a patch, cause the right design would have been having defined the interface from the beginning and having both classes implementing it.

An interface extending a class
The interface will inherit the method declarations, but not the implementation. When extending a single class, this again feels a bit like a patch. Let's say you want to define new classes that have the same contract as the "parent class" but that need to implement everything. I's useful then to declare this interface "in between" that inherits from that parent class, it saves you the keystrokes of putting those (empty) method declarations in the interface. This is similar to the first case, and again the good design would have been having defined the interface since the beginning, with all the classes implementing it.
On the other side, if extending several classes, this technique is an alternative to Intersection Types. I mean, these 2 codes would be equivalent:

class Person{
 talk(){}
}

class Animal{
 growl(){}
}

function doSomething (item: Person & Animal){

}

//or I could do:
//this is fine, an interface can extend multiple interfaces
interface IPersonAnimal extends Person, Animal
{}

function doSomething2(item: IPersonAnimal){

}

let perAn = {
 talk(){},
 growl(){}
};

doSomething(perAn);

doSomething2(perAn);

Notice that other odd extend/implement combinations like a class extending an interface, an interface implementing another interface, or an interface implementing a class are not allowed.