I work on the Entity Framework Team at Microsoft.
Today we made a huge step towards RTM. I know this is no news anymore, but well, it has been one of those days ;)
Now please, go get the bits, start creating your models with the designer. Then tweak them with some nice inheritance. Why not, taste a few EntityReaders. Generate some classes and take a look at the generated code. Get familiar with our objects and namespaces! Surround an ObjectContext in a Using statement. Plunk some ObjectQuery<T> inside. Indulge yourself with some LINQ to Entities queries. Change values here and there, add some Entities. Call SaveChanges()...
If you have been waiting to get familiar with the Entity Framework, there is no way and no reason not to start now.
BuildYourSkills() and most of all, SendYourFeedback()! :)
John Papa asks in my comments about some differences among the two query languages.
Let's start from the beginning:
Updatable queries: Neither LINQ to Entities nor ESQL currently enclose a real Data Manipulation Language. However, both can return tracked entities that you can then update and send back to the store. To make it clear, that is the case with ESQL only when you run your queries against Object Services (ObjectContext + ObjectQuery<T>), and not when you use it directly on top of Entity Services (EntityClient).
Dynamic queries: Being a text based language, ESQL can be really very dynamic. You can get whatever you want by manipulating strings (which in my opinion can become dirty business :)). However, you better know what type will be returned from the query in order to use the result appropriately. I have seen some blog posts describing very smart ways to build dynamic LINQ queries without using any text based query languages. Those functional programming inspired techniques should be applicable in general to LINQ to Entities.
Access to functions: While in ESQL you have full access to EDM and store functions, in our LINQ implementation your options are currently limited to some CLR methods that we have mapped. For this we choose only methods that we can guarantee will behave consistently in a database store.
Association navigation: In ESQL you can always navigate an association using NAVIGATE, even if there is no navigation property in the conceptual model. In LINQ if you don’t have a navigation property, you need to fall back to a JOIN.
Equal comparability: In ESQL entities are “equal compare”, but not in LINQ to Entities. This affects the way you writ GROUP BY and JOIN operations in LINQ (not that you need them a lot if you have navigation properties).
Syntax: In LINQ you basically get the nice query comprehension syntax, including very nice things like FROM first, LET, etc. In ESQL you get the nice SQL-like syntax, including SELECT first, and what else? ;)
Result types: You can get entity types, complex types, scalars, or IEnumerables of entity types from either ESQL or LINQ to Entities. Only LINQ returns anonymous types and IGroupings, and only ESQL queries can return DbDataRecords.
But it is very difficult to tell at this stage if any of those will make it for v1.