Google joins .NET Foundation as Samsung brings .NET support to Tizen

Build 2016 is probably THE defining moment for developers that have previously shied away due to their inherent closed, proprietary nature.

At least for me anyways, AWS seriously needs a killer IDE like Visual Studio's tight integration with Azure.

See, I feel the opposite. I think UI programming is the worst application of OO-design because the data and actions of a UI are inherently decoupled.

You have have n data structures and m events that can be fired on a page and not every event is associated with every data structure. However, importantly, any event can be associated with any number of data structures, some of which may not even be conceived at the time of run/execution. OOP-doesn't work well in situations where you have functions that can operate on lots of disparate data-types.

When you apply OO principals to UI work, you end forcing a coupling that artificially limits what you can do with the data, requiring an increasing the levels of abstraction in order to provide baseline functionality. For example, when you have a button, it's an object, then if you want to apply a listener to it, you need to create a method on Button that accepts a listener. But to ensure that the method can actually interact with the passed object, you need to create an interface then ensure that every potential listener implements it. There is an entire world of classes that could be bound to the listener as-is, but those existing classes don't implement the correct interface since they didn't know of its existence. So the OOP-land solution is to write wrappers for every class you'd like to attach as a listener to the button.

In a functional world, you can attach any function that takes the appropriate number of arguments and be on your merry way. If the function doesn't fit that mold for whatever reason, you can cleanly wrap it in an anonymous function right where you're attaching it as a listener.

For instance, let's say you have a very simple Resize Image dialog, with two fields for desired height and width and a toggle button for keeping the current aspect ratio. Your data model is just (height : int, width : int), but you also have a UI state (keepAspect : bool). Changing the state could affect the actual data model, but it's not part of the final data you get out of the dialog.

In the traditional OOP paradigm, you'll just have to mix data and state, and once the UI gets more complex, you'll often end up with convoluted and bug-prone UpdateWidgets() methods being called after every user action or external data model update, and this function will both read and update the data model, the UI state and the UI view parameters. With the FP paradigm, you can just cleanly implement one function which receives the data model and state and creates the UI View, another function that enforces constraints on the data model and state and a few event handlers for specific user actions. This is essentially what you get nowadays with the more well-conceived workflows in ReactJS.

But while I really like this style of programming, I don't see how you can apply it to go. If there is one thing Go is worse at than OOP, that's FP. Go has no concept of pattern matching or currying, almost no inference, a cumbersome closure syntax and a pathetically weak type system without generics. Yeah, I know, JavaScript also falls short on most of the items in that list, but being dynamically-typed you can still easily write higher-order functions like map, filter, reduce and compose. Try to do that in Go without using reflection.

The Go authors and community seem to favor explicit for loops to functional constructs or comprehensions, and a little bit of copy-paste to function composition. That's OK, since Go's #1 goal is to be 'simple' in the sense that the code you see describes the imperative execution flow as accurately as possible, with very little magic happening behind the scenes. As far as UI design goes though, Go is probably even worse than C in some respects, since it doesn't even have these fancy macros that helped us brave UI programming back in the day. ;)

C# on the other hand, offers not only better-Java-than-Java OOP, but also an array of surprisingly competent functional features which keeps increasing with every language version. It had proper generics and closures since version 2.0 and covariance/contravariance and lambda syntax since version 4.0, expression bodies since version 6.0, pattern matching and tuples since version 7.0 and it will hopefully have proper record types and discriminated unions by version 8.0.