
.NET Core 1.0 release – what you need to know to get started - yurt_
https://raygun.com/blog/2016/08/net-core-1-0-release-get-started/
======
dblooman
Are there any guides for OSX/Linux that don't end with printing hello world. A
lot of what seems to be out there is very basic or starts talking about
Windows when it starts to get interesting

------
mjgoeke
Too bad the tooling (e.g. restore, build, package) and (I think) the project
files format is still preview.

So far, my experience has been that small isolated project seem to work fine,
but as soon as I try to break a more complex solution out into separate nuget
dependencies things start to get hairy.

Nuget dependency versions don't support npm-like syntax, so you can forget
about the "^1.0.0.0" notation. Syntax like "[1.0.0.0-2.0.0.0)" might be
supported, but honestly I've been fighting with other issues enough that I
can't recall for sure if making the version syntax ugly makes it happy.

Another surprise to those from javascript/npm land is multiple versions of the
same library in your dependency tree isn't supported. So you basically need to
support redirecting to a commonly supported version (which, without examples
showing version ranges, you're back at the version range syntax pains).

If anyone's tackled these pain points I'd love to hear.

~~~
soulnothing
I'm new to the CLR build system myself, and have sort of gotten stuck on
project formatting. The F# side seems to have some newer build systems, and
are trying to go towards a simpler build/project system.

For dependencies see Paket[1]. It allows versioning, and only the parent
dependencies not the entire dependency tree.

For building much like Gradle there is FAKE [2]. It's an F# DSL for build
tasks, and has type safety etc. But I've seen examples with C# project as
well.

[1] [https://fsprojects.github.io/Paket/getting-
started.html](https://fsprojects.github.io/Paket/getting-started.html) [2]
[http://fsharp.github.io/FAKE/](http://fsharp.github.io/FAKE/)

------
spriggan3
Finally ! Goodbye php,ruby and go ! can't get rid of Python though, simply the
best language for analytics.

~~~
nxh
What are the biggest benefits of using NET Core in comparison with Go, Ruby,
Python?

~~~
gnaritas
Speed of course, and a huge standard library that works with multiple
languages, Ruby and Python are dog slow compared to C#; can't speak to Go,
haven't used it.

~~~
mattmanser
Core doesn't actually have a huge standard library. That's kinda the big
problem with it. It's basically, at the moment, a really shit version of .Net
4.61.

For example in the 1.0 release the ORM is a complete joke at the moment. It
can't do fairly basic stuff, like worse than ORMs from 10 years ago.

~~~
richman777
EntityFramework? In my 5 or 6 years with .NET I've had more problems with
EntityFramework than not. Most of the time it's overkill or just not optimized
for the queries I could write myself. I'm a huge fan of Dapper.Net. Looks like
there's initial support for core as well.

~~~
mattmanser
No offence, but you're probably using it wrong.

These days, it's really very, very good. And it's been amazing since EF4, for
about 5 years now. Trying to push it too far is a mistake and can cause
performance problems, but, as with all ORMs, sometimes you need to drop down
to raw queries.

~~~
richman777
Missed this comment but I don't take offense to it.

In all honesty, if you have a well designed system it's pretty good at what it
does. I've used it without any issues on small personal projects and it was
great at what it did. Although getting it to work with Postgres is needlessly
"complicated". Not complicated per-say but not as easy as it just working with
SQL Server.

What happens when you take a legacy system and move over to .Net and try to
use EF on a poorly architectured data model? Chaos.

"Oh you want to search for orders that have these attributes that are stored
in a bit-encoded string field that is only joined from 3 different tables?"

------
jsmith0295
I really wanted to give this a try, but the lack of first-class MySQL support
makes it a non-starter for me at this point. There are third party drivers,
but they don't seem to work with many Entity Framework features.

~~~
justinmk
Trust me, you don't want EF--no matter how many times they say "vNext is gonna
be great!!1 for real this time." Consider a micro-ORM like dapper[1].

[1] [https://github.com/StackExchange/dapper-dot-
net](https://github.com/StackExchange/dapper-dot-net)

~~~
gnaritas
Yes yes yes, but better yet, write your own. Micro ORM's are "micro", it's
pretty trivial to create something better than Dapper and there's no framework
in the world better than your own, to you, because there won't ever be
anything to complain about, just mold it to work exactly how you like.

Dapper..

    
    
        var dogs = connection.Query<Dog>("select Age = @Age, Id = @Id", 
            new { Age = (int?)null, Id = guid });
     

yuk, I prefer

    
    
        var dogs = Dog.FindAll(And(IsNull("Age"), Equal("Id", guid)));
    

A touch of generics done properly, a bit of reflection, a static import, and
you can do much better than onnection.Query<Dog>. Write the API you want,
implementing what is basically an active record without relationships is not
terribly difficult and will pay off for years to come in your own code.

Edit: Dappers API is ugly as fuck, that's an immediate non-starter for me, and
the cost of reflection on loading objects is the wrong problem to be
optimizing and would only show up in an absurd micro benchmark intended to
show off speed that doesn't matter, it's small compared to the execution time
of the queries. If you like it, use it, but lets not pretend it's so much
effort it isn't worth redoing. It's certainly not the end all be all of ORMs.

~~~
justinmk
No, there's no (technical) reason to redundantly solve the problems that
dapper has solved. In particular the emitted IL which avoids costly reflection
is not something many people will correctly re-implement.

> A touch of generics done properly, a bit of reflection,

Dapper avoids reflection, its performance is very close to a hard-coded
SqlCommand.

~~~
gnaritas
If you're worried about the speed difference between reflection and a hand
written command, you're spending your time in the wrong part of the code.
Reflection isn't the bottleneck, the database is, by far.

Yes, if you speed test the difference between reflection and handwritten,
it'll look slow, but such micro-benchmarks are unrealistic of production code.
If you look for slowness you'll find it everywhere you look, but if you
profile real code you'll find the only slow code that actually matters and
you'll find that database IO is the bottleneck generally.

------
cylo
I haven't been able to reliably/easily get a project to compile on Linux into
a self contained executable similar to Go.

At one point this was advertised in blog posts as something that would be
possible. Has this changed?

I think it's one of the killer features that help ease the burden of
deployment for a lot of folks.

------
meira
Now is the time, Microsoft. Go for it!

