Live data from Hacker News

Understanding .NET 2015

blogs.msdn.com

51–60 of 107 posts

Re: Understanding .NET 2015

#51
post #17

Earlier quoted context omitted.

I spend most of my time in C# and it's always a sad moment when I start typing .Where(x => ...) in another language and realize it doesn't exist.

It's spelled filter http://en.wikipedia.org/wiki/Filter_%28higher-order_function...

Nah, it's spelled Select: http://www.w3schools.com/sql/sql_where.asp

(but academics like non-human-friendly terms, sure)

Re: Understanding .NET 2015

#52
post #36

Earlier quoted context omitted.

Well, I can assure you that Java is used.. more everywhere.

From itjobswatch.co.uk: C# - 16748 jobs [1]; Java - 13816 jobs [2] [1] http://www.itjobswatch.co.uk/jobs/uk/csharp.do [2] http://www.itjobswatch.co.uk/jobs/uk/java.do

He meant like COBOL - wider historical spread (despite declining workforce).

Re: Understanding .NET 2015

#53
post #2

Recently I got to use some C# on Linux (with Mono framework), and I gotta say it wasn't bad. I didn't do anything with GUI elements, was all back-end server code. 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…

I am python developer, I am looking forward to program in F#. F# just seems right after developing with python unlike languages like c#, java.

Plus if you run - it works.

Re: Understanding .NET 2015

#54
post #2

Recently I got to use some C# on Linux (with Mono framework), and I gotta say it wasn't bad. I didn't do anything with GUI elements, was all back-end server code. 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…

I am python developer, I am looking forward to program in F#. F# just seems right after developing with python unlike languages like c#, java.

Yes! <3 F# :)

Re: Understanding .NET 2015

#55
post #17

Earlier quoted context omitted.

It's spelled filter http://en.wikipedia.org/wiki/Filter_%28higher-order_function...

Nah, it's spelled Select: http://www.w3schools.com/sql/sql_where.asp (but academics like non-human-friendly terms, sure)

No idea what point you're trying to make.

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.

Re: Understanding .NET 2015

#56

Earlier quoted context omitted.

Just out of curiosity, what is your go-to language? 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!

I'd love to see a comparison of Golang's goroutines/channels vs async. If you know of one or could write one here, that would be appreciated! :-)

Task/async is a slightly different beast, effectively its a goroutine+channel which can only return 1 value or throw an exception.

A better alternative to channels is Rx (Reactive Extensions) which gives you IObservable. 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.

Re: Understanding .NET 2015

#57
.NET Native ... It would be great to have it for back-end also as opposed to only front-end. I'd take that 60% startup increase in IIS also, the first request is always slow...

Re: Understanding .NET 2015

#58
Any reasons I should switch to Java or other technologies?

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?

Re: Understanding .NET 2015

#59
post #17

Earlier quoted context omitted.

It's spelled filter http://en.wikipedia.org/wiki/Filter_%28higher-order_function...

Nah, it's spelled Select: http://www.w3schools.com/sql/sql_where.asp (but academics like non-human-friendly terms, sure)

No.

Select == Map

Where == Filter

SelectMany == FlatMap

Aggregate == FoldL

Re: Understanding .NET 2015

#60
post #37
post #33

Earlier quoted context omitted.

It is fairly clear on the GitHub repositories. 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 w…

Thanks for clarifying. 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...?

It doesn't depend on Win32, but MilCore depends on DirectX 9, so I guess it would be hard to port to other platforms.
Post reply on HN