Understanding .NET 2015
blogs.msdn.com
blogs.msdn.com
C# wouldn't be my top "go to" language, but I would put it above Java. I liked some of the generics handling better, it can be less verbose it seems.
Monodevelop is not on par with Visual Studio, but it is solid and worked well for me. I usually don't like IDEs, but for a new language/framework and large projects it was very helpful to have it.
Wondering if open sourcing .NET core will breathe a new life into Mono project and maybe it is going to be bigger thing that what we expected -- we'll start seeing more back-end usage of .NET.
F# is nice too, and if anyone stayed away because of having to use Windows, maybe now is a time to take a second look.
http://en.wikipedia.org/wiki/Filter_%28higher-order_function...
(but academics like non-human-friendly terms, sure)
On human-friendliness, filter can read as a physical metaphor, so scores rather well. Just need to remember whether what's caught is kept or discarded.
Select == Map
Where == Filter
SelectMany == FlatMap
Aggregate == FoldL
Besides that, one of the early intents behind LINQ was to allow a language-integrated ORM, so LINQ's choices for names are actually extremely appropriate.
myList.Where(x => x.name = 'Person');
.Where(x => x.age > 18);
.ToList();
_.where(listOfPlays, {author: "Shakespeare", year: 1611});
LINQ doesn't just combine Wheres. It tries to optimize your query as much as possible and executes lazily, so you aren't actually doing any work until you try to use the resultset (in a ToList, for example).
[0]: https://lodash.com/
_(myList)
.filter(x => x.name == 'Person')
.filter(x => x.age > 18)
.value()
public static IEnumerable<T> Where<T>(IEnumerable<T> source,
Predicate<T> predicate)
{
foreach(var item in source)
{
if(predicate(item))
yield return item;
}
}
var results = myList
.Where(x => x.name == 'Person');
.Where(x => x.age > 18);
.ToList();
var results = new List<Foo>();
foreach(var x in myList)
{
if(x.name == 'Person')
{
if(x.age > 18)
results.Add(x);
}
}In fact, how else could "Where" be implemented while keeping lazy semantics?
(Rust, AFAIK, can actually do this, by inlining everything including the lambdas.)
You're right it's missing the actual function calls, but that wasn't the point: the point here was that LINQ avoids building temporary enumerations and iterating over them like JS functions do.
But here's a microbenchmark[1]. It's still not close to non-LINQ code. A factor of 10, with a trivial body, just summing up some numbers. (I didn't used Sum() as it appears to use checked arithmetic.)
As far as the optimizations, the smart combining code (which still has to allocate a combined delegate + lambda object, that'll cost, what 2 objects at like 40 bytes each?)) only happens when Select is followed by Select, or Where by Where. Select after Where gets a new "WhereSelectEnumerableIterator" and so on.
So you're right that it does eliminate some overhead though depending on the order of your Wheres and Selects there may be more "foreach" loops in the comparable code. And it's still not even close to being free like it should be. (Like, say, Haskell can do sometimes.)
C# is probably my favorite general purpose language so far, although I really prefer Golang's goroutines/channels over C#'s async model. Curious to hear other perspectives!
Erlang/Elixir for larger projects where fault tolerance or concurrency is needed.
C/C++ where GC is a no-go (games, low latency, time critical data processing).
Next up in the pipeline to learn and use: Rust
Ever played something like e.g. Bastion?
http://en.wikipedia.org/wiki/Bastion_%28video_game%29
I mean if you are developing the new Unreal Engine - sure. But otherwise gaming industry would benefit from more of maintainable code.
Here's what the lead developer said on the topic of GC:
http://www.reddit.com/r/IAmA/comments/lwljh/iama_dev_team_of...
http://www.reddit.com/r/IAmA/comments/lwljh/iama_dev_team_of...
A better alternative to channels is Rx (Reactive Extensions) which gives you IObservable<T>. It's very simple and powerful. Observables can be composed using Linq, and they're monadic (if that matters). I like the first class notion that something can fail or be completed (go has close(), which lets you complete a channel, but there is no notion of errors unless you slap a tuple in there).
Rx is available on many platforms (incl JVM, JS).
Rx.NET does not yet support back pressure (Rx 3.0 will, whenever Microsoft release that, maybe at //build). There's an alternative library from Microsoft called Dataflow, though, and Dataflow does support backpressure as well as a lot of other great features. Dataflow is underused, but its great. Rx & dataflow interoperate very easily (.ToObservable() etc)
There are a bunch of videos from Netflix on their use of Rx, which are a good watch if you're interested.
Edit: Channels in Go don't compose: I can't easily take one channel, mutate the values as they arrive, and create another channel from the mutated values. With Rx, that's just `var uppers = keyPresses.Select(key => key.ToUpper())` and now I've got a new stream of data. If keyPresses completes, so does uppers. If it fails, that failure is propagated through uppers. This isn't easy in Go.
goroutines don't have any reasonable kind of monitoring. I can't say "this routine has completed/failed", I have to implement that notion every single time using a WaitGroup or something, and that only handles completion, not failure.
I'm not saying C# is perfect and that go's channels/goroutines don't have any merit, just that there are some things I wish I could do more easily using them.
For example of a RX backend API check out https://github.com/AdaptiveConsulting/ReactiveTrader
It pays off in spades in a lot of situations, but the biggest I've noticed is Android development. Hitting a network from a button press in Xamarin is as simple as:
button.OnClick += async
{
var data = HitTheNetworkForSomeData();
// Note that since this is still async,
// you may want to set a global or have a
// different approach to handling data than
// "standard" Android development.
DoSomethingWithTheData(data);
}
button.SetOnClickListener(new OnClickListener() {
new HitTheNetworkTask(this, this).execute()
});
@Override
public void onNetworkTaskDataRecieved(String data) {
doSomething(data);
}
public class HitTheNetworkTask extends AsyncTask<Void, Void, String> {
Context mContext;
NetworkDataTaskCallbacks mCallbacks;
public HitTheNetworkTask(Context context, NetworkDataTaskCallbacks callbacks) {
mContext = context;
mCallBacks = callbacks;
}
@Override
public String doInBackGround(Void... voids){ // I'm not pulling your leg here
return doTheNetworkTask();
}
@Override
public void onPostExecute(String data) {
callbacks.onNetworkTaskDataRecieved(data);
}
}
One PITA for me is that whenever talks about various technologies happen on HN, I tend to comment on disadvantages, because it's the disadvantages that dictate the best use cases for that particular technology.
But whenever I do that for .NET / C#, there's like a circle of jerks on HN that down-vote everything that sounds bad about .NET.
That's fine, I had some hopes for Microsoft's .NET, now that it is finally being open-sourced and made multi platform, but when choosing a language, you're also choosing the ecosystem around it and this instance, amongst other interactions I've had, confirms that .NET is not for me and probably never will be.
Cheers,
This just isn't a JVM vs .NET competition. If Prolog were the best answer, you could port it to JVM or .NET to your heart's content.
For me Scala is more accessible and elegant than both C# and F# and in my opinion has less baggage.
public SearchViewModel(ISearchService searchService = null) : ReactiveObject, IRoutableViewHost
{
SearchService = searchService ?? Locator.Current.GetService<ISearchService>();
// Here we're describing here, in a *declarative way*, the conditions in
// which the Search command is enabled. Now our Command IsEnabled is
// perfectly efficient, because we're only updating the UI in the scenario
// when it should change.
var canSearch = this.WhenAny(x => x.SearchQuery, x => !String.IsNullOrWhiteSpace(x.Value));
// ReactiveCommand has built-in support for background operations and
// guarantees that this block will only run exactly once at a time, and
// that the CanExecute will auto-disable and that property IsExecuting will
// be set according whilst it is running.
Search = ReactiveCommand.CreateAsyncTask(canSearch, async _ => {
return await searchService.Search(this.SearchQuery);
});
// ReactiveCommands are themselves IObservables, whose value are the results
// from the async method, guaranteed to arrive on the UI thread. We're going
// to take the list of search results that the background operation loaded,
// and them into our SearchResults.
Search.Subscribe(results => {
SearchResults.Clear();
SearchResults.AddRange(results);
});
// ThrownExceptions is any exception thrown from the CreateAsyncTask piped
// to this Observable. Subscribing to this allows you to handle errors on
// the UI thread.
Search.ThrownExceptions
.Subscribe(ex => {
UserError.Throw("Potential Network Connectivity Error", ex);
});
// Whenever the Search query changes, we're going to wait for one second
// of "dead airtime", then automatically invoke the subscribe command.
this.WhenAnyValue(x => x.SearchQuery)
.Throttle(TimeSpan.FromSeconds(1), RxApp.MainThreadScheduler)
.InvokeCommand(this, x => x.Search);
}If you implement SynchronizationContext and set it, you can actually have the TPL call back into whatever special threading stuff you want.
It doesn't work for WPF bindings, but for the quick'n'dirty procedural UI code it works great.
[1]: https://msdn.microsoft.com/en-us/library/system.threading.sy...
Having said that, more is possible with Java than many people realise. You can read statically available generic type params at runtime (field declarations, supertype tokens etc) . There are also workarounds for most of the erasure problems like methods that vary by generic type parameter only.
Java has some nice things itself too. Structural typing of single method interfaces/lambdas makes numerous things much easier. Default methods on interfaces let you do trait-like things nicer than with extension methods. Static imports reduce verbosity. More powerful enums etc.
c# approach to type inference seems to be to infer the left hand side of expressions with "var". Java infers types on the right hand side with the diamond operator, method type parameter inference, lambda to interface type inference. The Java approach makes code using fluent chained invocations less verbose, while the c# approach reduces the verbosity of assigning to lots of intermediate variables.
class Example
{
public static void Main()
{
Predicate<String> foo = Foo<String>(s => s.Contains("foo"));
}
static Predicate<T> Foo<T>(Predicate<T> p)
{
return p;
}
}
Java will infer the RHS
class Example {
public static void main(String... args) {
Predicate<String> foo = foo(s -> s.contains("foo"));
}
static <T> Predicate<T> foo(Predicate<T> p) {
return p;
}
}
public class Example {
interface MyPredicate<T> {
boolean test(T t);
default void hello() {
System.out.println("Hello");
}
}
public static void main(String... args) {
MyPredicate<String> foo = s -> s.contains("foo");
foo.hello();
}
}
As for type inference, C# will sometimes infer the RHS from the LHS, lambdas are one example. Also sometimes it can figure out the types from a lambda. Here is an example where the type information for inference comes from the literal int zero:
public void Main()
{
var i = 0;
var list = MakeThree(() => i++);
//[0, 1, 2]
}
private IList<T> MakeThree<T>(Func<T> generator)
{
return new List<T>{ generator(), generator(), generator() };
}
Predicate<string> p = s => s.Contains("foo");
var foo = Foo(p);
Also I use Func and Action every day, but I basically never use other delegate types.
Your example of structure typing of lambdas looks weird to me. It's the same feeling I get when I see a downcast. I mean no criticism; I suspect this is a Blub reaction in me. I am not used to looking at the left-hand side to figure out the type for the right-hand side. Lambdas will implicitly convert to a Func or Action. A reference to a method with a matching signature will also convert. As a silly example: Select takes a Func<T, U>, and will implicitly convert a method that accepts the same T as its only parameter.
public ShortTons ConvertTons(LongTons t) { ... }
public void Main()
{
var readings = GetReadings();
var exportWeights = readings.Select(x => x.Weight).Select(ConvertTons);
}
That builder pattern is pretty cool. In C# you have object initialization syntax, which is similar in being more readable as to which members are getting set. However, that's pretty much incompatible with immutability afaik. It only lets you set public properties with public setters. Normally you would make something immutable by making your setters private, or leaving them off entirely. Public fields (even readonly ones) are strongly discouraged in C#. Either way, that prohibits object initialization.
Thanks for responding, I learned a lot about Java.
I mean, attributes are reflection, and they're absolutely invaluable.
Reflection is like anything else it can be used properly and it can be abused. I've seen it abused far too many times.
I realize there are times in Java when reflection is unavoidable (Android's animation libraries rely on it), but I consider it to be a feature of C# that, so far, I've never had to use reflection in C#.
Most of the issues can actually be resolved even with type erasure. e.g. method overloading can be resolved statically.
If ever, given their attitude on last year's Google IO.
Then check out http://arteksoftware.com/resilient-network-services-with-xam... for the pattern/inspiration how to glue them together to obtain a x-platform resilient, performant and data caching network stack. Write once, enjoy on every platform.
C# - 16748 jobs [1]; Java - 13816 jobs [2]
Looking at US job search sites, Java has about 2 times as many results as C# in the US overall, and 3-6 times as many in SF and New York. Java even has almost twice as many results in Seattle.
From indeed.com:
Java - 81,818 [1]; C# - 35,623 [2];
[1] http://www.indeed.com/jobs?q=java&l=
[2] http://www.indeed.com/jobs?q=C%23&l=
comments:
- Java has more results than even ".NET", which encompasses more than just C#: 73,971 http://www.indeed.com/jobs?q=.NET&l=
- C# has about the same number of results as Python: 35,072 http://www.indeed.com/jobs?q=python&l=
From StackOverflow:
Java - 794 [1]; C# - 479 [2]
[1] http://careers.stackoverflow.com/jobs?searchTerm=java
[2] http://careers.stackoverflow.com/jobs?searchTerm=C%23
From indeed.co.uk (the only one that has a similar ratio as itjobswatch.co.uk):
Java - 25,478 [1]; C# - 28,037 [2]
[1] http://www.indeed.co.uk/jobs?q=java&l=
[2] http://www.indeed.co.uk/jobs?q=C%23&l=
From indeed.com, Bay Area:
Java - 5,997 [1]; C# - 1,013 [2]
[1] http://www.indeed.com/jobs?q=java&l=San+Francisco%2C+CA&radi...
[2] http://www.indeed.com/jobs?q=C%23&l=San+Francisco%2C+CA&radi...
From indeed.com, New York:
Java - 6,941 [1]; C# - 2,548 [2]
[1] http://www.indeed.com/jobs?q=java&l=New+York%2C+NY&radius=25
[2] hhttp://www.indeed.com/jobs?q=C%23&l=New+York%2C+NY&radius=25
From indeed.com, Seattle:
Java - 3,832 [1]; C# - 2,124 [2]
http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-bl...
Apart from that: I'm really curious and sort of excited to see what the next years will bring in terms of development using .Net in general and C#/F# specifically, on multiple platforms.
.NET Core sounds great, and its great that they are unifying the implementation, not just the API, for many of the "app models". But, its unclear to me if there's the intention for .NET Core to fully succeed .NET Framework at some point in the future. Or, rather, will some of the app models we see on top of the Framework right now (WinForms, WPF apps) be built with .NET Core in some future version?
Also Azure is a massive component to all of this (they make money of Azure, they don't make a massive amount of cash from someone using .Net).
Microsoft have a long history of keeping old versions alive (unlike say Apple). Eg Internet Explorer, Windows XP, Office, Win Forms vs MVC
I'm sure .Net core will take over one day. In the same way .Net 4.5 overtook .Net 2 / 1.1 etc.
What I get with the (much hated) Microsoft stack:
- C# with LINQ and async await
- Roslyn compiler as a service which speeds up development
- mature .NET framework
- more and more open source and cross platform parts and smaller independent libs
- typescript
- Xamarin cross platform tools
I also use python and used Java in the past. I don't see any reason why Java should be better?
I am wondering how asp.net on linux will stack up! should be interesting.
- Groovy is nice and still very similar to Java(no learning curve)when you want syntactic sugar like LINQ or JDBC SQL without all the boilerplate code.
- IntelliJ Idea is similar to Visual Studio + Resharper.
But the biggest reason to start using Java is its extremely mature and rich ecosystem!
I'm currently doing software development on Windows with C#.Net and Visual Studio without ReSharper and I really miss Linux, Java and IntelliJ Idea :(
My background is in the LAMP stack but now work in an enterprise environment where everything is .NET (though much older .NET than this article is talking about).
I want to throw myself into it but right when I started there was all this new talk about vNext and changes to .NET and all this other excited, though daunting, discussion around it.
Was hard to know where to start.
But startup cost is less relevant in a server scenario. In a server you startup once per ~1B requests or more. In a front-end app, it might run 10 requests and then stop.
Why wouldn't they open source the v4.x version? And why is WPF, Windows Forms, and ASP.NET placed above the .NET 4.x block in the diagram?
Is .NET v5 Core a from-scratch lightweight reimplementation that can't run the full stack? If not, why the huge separation?
I remember looking at the corefx github project just after the announcement, and it was very sparse with just a few commits and classes; it looked a lot like a brand new project written from scratch.
This wording also makes it sound like ".net core" is a re-boot, scorched earth reimplementation which will take some time to reach the levels of the original .net:
>.NET Framework 4.6
>The .NET Framework is still the platform of choice for building rich desktop applications and .NET Core doesn’t change that.
>For Visual Studio 2015 our goal is to make sure that .NET Core is a pure subset of the .NET Framework. In other words, there wouldn’t be any feature gaps. After Visual Studio 2015 is released our expectation is that .NET Core will version faster than the .NET Framework. This means that there will be points in time where a feature will only be available on the .NET Core based platforms.
I don't see how the quote substantiates the notion that .NET core is written from scratch.
".NET Core also includes the base class libraries. These libraries are largely the same code as the .NET Framework class libraries, but have been factored (removal of dependencies) to enable us to ship a smaller set of libraries."
It's not a reimplementation but a gradual publish of existing code, upgraded to meet the required standards (some of it was not written with being open in mind).
WPF will not be available on non-Windows platforms. That has always been the case and will remain so - it has a far to deep integration with the OS for it to ever be platform independent and a reimplementation would be an absolutely ginormous effort.
And on a tangent, I guess the WPF thing was expected. But! I also thought WPF is mostly a re-implementation of all the windows widgets on top of a framebuffer - it doesn't use native win32 buttons, dropdowns, text rendering, etc etc...?
https://github.com/dotnet/corefx/issues/973
It probably answers a few of the questions several have asked in this thread with regards to what the .NET Core is.
Unfortunately there are a few libraries I use at work that were released around the whole Windows RT/JS debacle, so their documentation takes a little more figuring, and is frequently incorrect, due to only having code samples in these dead/orphaned variants.