The future of C# and Visual Basic [video] | Hacker News Reader

The future of C# and Visual Basic [video]

channel9.msdn.com

177 pointsnstart171 comments

Much to the derision many of the developers I know, I still say that C# is the best language I've ever worked in. But the .NET platform is one of the worst I've ever worked in. So opening up C# to more platforms sounds very, very good to my ears.

I only wish Xamarin's products didn't cost so much. With Swift on the scene I really can't justify spending money to write my side projects in C# instead of in the environment Apple provides. Or Java for Android, which let's face it, is already similar to C# anyway.

Unless of course, you want your side projects to work on non-Apple platforms. Aside from mobile stuff (and who really cares about that ;), the remainder of the Xamarin/Mono toolset is feature complete and almost entirely open source.

Xamarin's value proposition is developing for multiple platforms at once (or at least, as a current Xamarin user, sharing as much as possible between platforms). Swift still offers nothing for that scenario so I don't really understand the comparison.

Obviously if you are only going to ever develop for iOS then going with Swift could make sense but then it seems that Xamarin would've never really have been an option anyhow, irrelevant of cost.

Last time I tried Xamarin (and I'll admit it's been a while) cross-platform was surprisingly difficult. A project had to be either iOS or Android - and that included projects that had no UI code in them. So the concept was there, but the execution wasn't yet.

Of course, this may have changed.

Portable Class Libraries help here. They aren't perfect, and honestly they're justly badly reinventing Java's loosely coupled jars, but they give you the ability to link stuff together in a little more general of a way.

In my current project (a video game), the core library is a PCL - it contains data structures and the interfaces and abstract classes that content (mods as well as the base game) must fulfill. I have a "desktop" library that's a normal .NET 4.5 class library that contains stuff like "load your config data from files, include the runtime-compilation mod system", and I have runner projects--text-mode via curses for now, eventually graphical post-prototype--for MacOS, Windows, and Linux[1]. I use configurations (not platforms, leave everything as AnyCPU unless you want to hate your life) to provide preprocessor flags for #if; my solution has ended up with an ugly number of "Windows-Debug", "MacOS-Release", etc., but the differences between XS and VS make it hard to do things "right".

[1] - all source/content files added via a single template .csproj, using a Ruby watcher I'm going to eventually open-source, because using MSBuild correctly to handle this situation breaks in both VS and Xamarin. (That last bit, you may be realizing, is a common theme. .NET has such good stuff, but half of it is broken at any time.)

Assuming you don't need to pass around binary libraries, take a look at shared projects-- added in Visual Studio 2013 and Xamarin Studio 5, IIRC. Unlike PCL projects, they compile in the context of the projects that reference them, so you have full access to the libraries that are common between each platform, and (if your coding style allows it) full access to platform-dependent APIs as long as they're protected by the appropriate #if __IOS__/#if __WIN32__/etc.

Keeping common code in shared projects is like night and day compared to the mess that is keeping common code in a PCL and having to deal with common APIs that aren't present (or worse, are incomplete) in your chosen PCL subset. They really clean things up a lot, even if you're treating them like they're a PCL and avoiding any platform-dependent code.

Ooh. I didn't know about this. I'm using VS2012, because I don't want to shell out again for VS2013 but want ReSharper - I'll have to look at this...thank you!

There is still a degree of that, depending on how you structure the application, and how much of it is reliant on your UI layer vs backend business logic.

Xamarin.Forms is their solution - common UI components wrapped in a generic layer.

They have a nice way to blend Xamarin.Forms, native UI controls and library projects that is getting much better, but still a bit of a pain.

They true value in my eye is that I only have to be proficient in one language, and they have very good documentation.

I still need to have a firm understanding of the API's for both Android, iOS, and WinPhone if I want to make a non-Xamarin.Forms application, but at least I'm not mentally shifting between 3 languages.

Picking up languages really isn't that te key, it's always been the library that's hard, so I can't say I can see the value if it's just that.

I suppose the value is that you don't have to rewrite your application logic multiple times. That takes time even if you're fluent in all languages. It is also a duplicatio which increases the risk of later bugs due to not doing all changes in all copies.

Exactly - and as a after work only developer, the less I have to do over, the less I have to consult the docs, the more comfortable I am with a single tool, the more productive I become.

At work we use Xamarin for iOS-only projects, as we're primarily a C# consultancy. It's expensive, but it would be more expensive and difficult to find or train native iOS developers. Or at least, that's the impression management is under. The fact that we could port an app to Android somewhat easily when a client requests it is just icing on the cake, since almost all of our mobile projects are iOS only.

Interestingly, most of my experience is in c#, but I've now got a side project that requires apps. I wrote them in Android and iOS. I looked at Xamarin as well, but I couldn't see the point of learning essentially a new framework. I figure whatever pattern you use (probably MVC) it will be the same on both. And the layout paradigms are different between them, so how is Xamarin going to fix that? My solution was just to use webviews instead of the native layouts (decided after bashing my head against both layout engines).

Anyway, my point is once you understand how things are organised, the language shouldn't make much of a difference. Especially not between popular, run-of-the-mill languages like c#, java and ObjC. Your devs could probably learn iOS pretty easily.

I agree. However, there is a lot of fear among developers in my area with regards to learning new languages. Many developers I know would rather learn 20 new frameworks than a single new language. Managers feel even more strongly along those lines. I don't share their views, but I think I am in a minority.

I hope that Microsoft buys Xamarin (I know, I'm evil) and makes it free, or very reasonably priced.

I bet Microsoft would like to buy Xamarin too, but worry that might strain Xamarin's relationship with Apple and/or Google. This could be a "if it aint broke, don't fix it" scenario.

Actually that sounds so reasonable. I have been asking myself why Microsoft hasn't bought Xamarin. But Xamarin is actually an amazing Trojan Horse for Microsoft.

If by some miracle Visual Studio ever ran on non-Windows platforms, Microsoft would then be free to kill off Xamarin Studio.

And as long as we're being evil, I wouldn't mind seeing Microsoft buy up Light Table (if that's even possible) and build some of its features into Visual Studio. Namely inline eval and live code modification.

I suspect they'd have to rewrite Visual Studio into ClojureScript or similar if they went that route. Which would certainly be interesting.

Though I'd certainly be all in favor of inline eval and live coding in VS!

Both of which it has have via Roslyn/Edit and Continue.

Interesting. I knew VS had been working toward features like that; I wasn't aware they'd come as far as they have. Though from my poking around there appear to be some limitations: no redefining lambdas in a live session, for example. And I'm pretty sure that Instaparse is still out of reach, though that's not really what was being referred to. But thank you for reminding me, it's been a while since I've had an occasion to touch VS.

Exactly, like Nokia bought Qt ;)

I have been working in a C# codebase for the last 4-5 months. I've summed up my experience with the language like this: C# is a really good language. C#'s stdlib however is subpar.

For the stdlib there is no one single problem it's death by a thousand cuts in a lot of various ways. Over reliance on inheritance for polymorphism which limits composability in a lot of ways. Too little use of interfaces.

Some of this seems like it's due to backwards compatibility concerns but it definitely degrades the developer experience with the language. Which is a shame because c# has a lot to offer.

Who provides a better standard library? I am a C# developer and have not that much exposure to other standard libraries, but from what I used, .NET is by far my favorite one.

There's a fair number of patterns which are now outdated, because they were created before, e.g. Generics.

So the

  bool Int32.TryParse(string value, out number)

method would probably nowadays be better done as

  Int? Int32.TryParse(string value)

Similarly, WinForms has loads of different events of different types with individual delegates created for them. Nowadays you'd use Func and Action instead.

And they would not make arrays covariant again, the reflection API would surely use IEnumerable<T> instead of arrays, there are a couple of glitches in the inheritance hierarchy of the collections...but that doesn't really make it a bad standard library.

What's frustrating is how few things got the needed TLC after generics and nullables were added.

Also, I'm constantly frustrated how many core libs freak the heck out over a null string vs. an empty string. Obviously there are places to distinguish those, but if I'm trying to create a nullable int out of the text that is not one of them.

Likewise Async. The basic file IO and ADO.NET APIs can be wrapped up in awaitable structures but you pretty much have to do it yourself. For most purposes if you really want to make good use of C#'s cleverest language features you have to write wrapper classes around .NET to make it work.

They've also done a terrible job of making a first class Windows UI library for .NET; WinForms was always clunky and limited in the subset of MFC/GDI it exposed; WPF was too radical and didn't make sufficient use of the underlying native capabilities of Windows - and the WinRT story has been confused from day 1.

WPF is so much better than (almost) everything else out there (that I am aware of). Yes, it is very different and switching from WinForms is hard to say the least, but it gets so many things right, is extremely powerful and really fun to use once you wrapped your head around it.

That doesn't work for a standard library - it may make you happy, but the next developer may have very different needs. Int32.TryParse() does not distinguish between null and empty strings and it takes only a minute or two to create an extension method and the problem is solved once and forever.

  public static class StringExtensions
  {
     public static Int32? ParseAsNullableInt32(this String self, Int32? fallback = null)
     {
        Int32 result;
        return Int32.TryParse(self, out result) ? result : fallback;
     }
  }

Yes, that's the obviously implementation, but so many older framework libs that have not been replaced still use serializers that, when given a Nullable type, fail to use that obvious implementation and blow up on empty strings.

In the case of the XML Serializer, that means that if I declare a class with Nullable<int> Foo {get;set;}

and

    <Foo />

appears in the XML body, then it blows up. The WebForms stuff is similarly pathetic about empty strings. There is no useful distinction between empty strings and nulls when we're talking about dates or numbers or something like that, so throwing an exception in this case is just plain wrong. It's not even protecting backwards compatibility because pre-2.0 C# didn't even have nullable ints.

Nullable is not an adequate replacement for Maybe/Option, one because it is constrained only to value types, which makes it useless generically anyway, and secondly, because you can easily "bypass" it and attempt to call .Value while skipping .HasValue, causing an exception to be thrown. C# lacks the necessary features to have a useful Maybe type - namely exhaustive pattern matching and the Unit type.

A better pattern used in say, F#, would be to return the tuple of <bool, T>, which could handle reference types and value types uniformly unlike Nullable. That won't slide in C# though as there's no syntactic sugar for tuples, and calling .Item1, .Item2 is too "inelegant" for the regular programmer.

For now though, the bool Try_(_, out _ _) is still the preferred method by most.

Func and Action are certainly useful, but sometimes having a named delegate type is still preferable because you can capture the purpose of the delegate in it's name, rather than resorting to doc comments nobody is going to read anyway.

You don't need it for reference types, because those can just return a null.

I agree that it would be nice if C# checked that you dealt with the null case of the return - Resharper will happily warn me if I haven't, but it would be nice if the base compiler did. Maybe in the future!

>You don't need it for reference types, because those can just return a null.

The point is that it is not necessarily correct to conflate the nullability of the parse with the correctness of the parse. If I wanted to parse a string into a Foo, null might be a valid value for a successful parse to return, say because the rule is that the string "(null)" maps to a null Foo.

There is a draft for pattern-matching in C# [1].

[1] https://roslyn.codeplex.com/discussions/560339

Nullable is the perfect solution for TryParse. The InvalidOperationException on null is the equivalent of the NullPointerException you would expect for a reference class TryParse method.

I have implemented TryParse methods on many reference types with exactly these semantics - object on success, null on failure (often with details logged at DEBUG).

Java's library is on the whole better than C#'s. But if you want an example of a stdlib that really sets the bar then I would point to Go. In particular the io packages. They are so composable and simple and easy to use that it makes me want to cry at their beauty sometimes. Go has one of the best written stdlib's of any language I've ever used.

I'm a C# developer of 10+ years. Your concerns are valid and no lost on many people. A class example being IList<T> and List<T>

I was once told that a lot of the original libs were effectively ported from C++ libs by C++ devs in a hurry. There are nuget packages with decent data structure / collections missing from the core BCL.

Interfaces like IEnumerable<T>, IComparable<T> and IEquatable<T> I find to be extremely useful and if you're following interface segregation principle and not chucking round the actual concrete implementations. I concede though that the BCL would be richer if one didn't have to think about this stuff too much.

I guess there's enough experienced C# devs around to know how to avoid those pitfalls. As the BCL is shrunk I expect it will be easier to substitute any structures your not happy with, with alternatives.

In a hurry is an understatement. Generics were allegedly implemented by Don Syme before the initial release of C#, but higher ups were more keen on shipping a substandard product because Generics were "only for academics".

Some of C#'s interfaces are simple and well designed, but the OOP model used is kind of weak for composition of them. For example, one would often like an IIndexable interface to cover both arrays and lists, or an numeric interface for which we can perform common operations over any number type. Without the ability to extend existing implementations with new interfaces, we're stuck using various patterns and wrappers to get the abstraction we need.

I was a C# developer for about 6 years before I got tired of the same old problems and decided it's not for me. I still use it occasionally when required, but not if other options are available.

> For example, one would often like an IIndexable interface to cover both arrays and lists

I’ve thought about this.

To be useful, an IIndexable would need get and set methods for the index, and a Length/Count property. You would need to explicitly implement it on something like the array class since you wouldn’t want to lose the semantic difference between Length (O(1)) and Count (O(n)).

But, the existence of Func<T, TResult> and Action<T1, T2> would largely obsolete the utility of such and interface.

Let xs be an “indexable” object of T (e.g. T[] or List<T>). Then any method that expects to only access an object could just accept lambda of type int -> T. So, you’d just pass it

     n => xs[n].

Similarly, methods that expect to mutate the object could take a lambda of type (int, T) -> (). So would just pass something like

     (n, x) => xs[n] = x.

This is nicer because it makes explicit what the method will do to the indexable.

I don't think there is the distinction between Length and Count you draw - Count is O(1) for most collections, even LinkedList<T> maintains the number of elements in the list in a separate field. You could say Length does not change during the lifetime of an object while Count may do so, but I am not even sure if this distinction is always honored.

Yes, I think you're right. I thought that I had read stuff about the name implying the complexity class, but my Google-Fu isn't turning anything up.

Arrays actually do implement IList<T>; they did think of that. I guess the problem is that it's not discoverable. I'd second your call for an interface on numbers (including some way to "genericise" TryParse).

Arrays implementing IList<T> is a clear example of a broken abstraction though - arrays have no need for Add, Remove and whatnot that come with IList - it only needs indexing and count.

Yeah. Although dynamic arrays would need that.

We normally think of Strings as being a special case of an array, but arguably String<T> should be a fundamental datatype, and we could do away with Array altogether. In that case, having operators for add and remove doesn't seem so crazy, especially in light of the fact that vectors often outperform doubly linked list for insertion and deletion on modern hardware[1].

[1] https://www.youtube.com/watch?v=YQs6IC-vgmo

  I guess the problem is that it's not discoverable.

I think you are absolutely right. While the reflection is available (and the documentation, in general, is not at all bad), discoverability is still weak.

Which language did you switch to?

I used to be a hardcore C# developer. From the initial beta of .NET through v3.5, I used it at least 25% of my time. But, since then I've not used it.

Last year, I inherited a .NET v4.0 project, so I've been back in Visual Studio quite a lot. And, maybe it's that my skills are rusty. That very well could be. But, the latest version of C# just feels like a sloppy mess.

Could you elaborate what's so messy in your eyes? Most features that were added are more or less only visible if you actively use them and shouldn't distract from anything.

Again, I could be using C# stupidly, or the existing code that I have could be all hacked up. But, it seems like C# is trying to be everything to everyone. There are too many features of the language that allow things to be done many different ways. This leads to a lot of inconsistencies when the code base is relatively large and there are lots of developers working on it. Some things just seem 'bolted on', like unit tests, functional idioms, NuGet, etc.

It's almost as if MS started C# as a competitor to Java and now has tried to make it a competitor to everything else (Python, JavaScript, Java, etc.). I'd rather that MS have created new languages and provided transformations to port existing C# code to those languages.

Or, perhaps I've been spoiled over the last few years working with dynamically typed languages with lots of functional idioms designed in from the start.

Edit: Obviously there are some die-hard C# advocates here. So, I hope to retract my opinions. I'm clearly doing something wrong.

3.5 => 4 hasn't really changed the way you should code much, so it's a bit confusing what about it you suddenly don't like? All the functional stuff was added in 3.5, 4 was really optional/named params, which are a godsend, dynamic, which you should use once in a blue moon, and a bunch of stuff to make COM interop easier.

The big question is when using LINQ whether to use the pseudo SQL syntax (I have no idea what it's formally called) or just use the methods. I find the former hard to read/write and as far as I can tell most people have simply avoided the pseudo SQL. A quick scan through SO's LINQ tag seems to confirm that the methods are much more commonly used, whereas when it first came out it seemed to be the other way around. Then again I don;t really do much on SO any more, so may be out of touch on that.

Is that the problem you're hitting, given you are saying there are too many ways to do something?

The big features that were added after c#3 are dynamic references and async. They both seem to be quite well done as far as I can tell. Could you comment more specifically on problems you saw?

What, exactly, is a mess? The language itself, or the project you inherited?

How is the .NET platform one of the worst? (The worst for cross-platform or simply the worst?)

I was more curious why C# is one of the best. Last time I looked at it (quite a while ago now), it was very like Java, and not many people rant about Java any more.

It's because modern idiomatic c# uses a lot functional programming inspiration.

Look again... much less like Java now, in my opinion

It's like Java 9. That hasn't been released yet. But so is C# 6.

C# has improved a lot faster than Java the last 5-6 years. I would say it is has been a much better language until recently when Java 8 was released. Now they are more equal with Java probably having some advantages since it was the last to update.

> C# is the best language I've ever worked in. But the .NET platform is one of the worst

That sums it up for me, too. I'm mostly a Ruby developer, and in C# I get tons of Ruby-like features, plus static typing and better performance. But my years with Java spoiled me for a clean and consistent stdlib. For instance in C# collections are just a mess. If I could build Rails apps in C# and deploy on Linux, I'd probably do it.

As a developer with experience in .NET, Java and Ruby, I'm curious as to what makes you say C# collections are a mess? At least relative to Java?

I haven't used either in a few years, but Java's are trivial to remember:

* List: implemented by ArrayList and LinkedLink

* Set: implemented by HashSet

* Map: implemented by HashMap

All are Collections.

Then it's easy to get immutable versions, synchronized versions, Sorted{Set,Map}s (implemented by Tree{Set,Map}).

They work with Comparator and Iterator in a consistent way.

There is symmetry and unity. I don't even remember the C# analogues, but my recollection is that sometimes they come with an interface, sometimes not, the names are messier, generics are less consistent, and there isn't a unified way to get immutable versions etc.

I don't think C#'s collections were that bad, and probably people here can correct my memory about some of the above, but they weren't as clean, and to me that was a motif throughout the framework. A messy collections API is no big deal really, but when it's the same story for I/O, networking, GUI, etc. . . . (I do think layout was a lot easier in WinForms than Swing though.)

On balance I'd take C#'s rapid evolution over Java's slowness, but what Java got from its conservatism was purity and low cognitive overhead, which as a working programmer was pretty nice.

That said, it'd still be really cool if I could write Rails apps in C# on Linux. With vim. :-)

In C#:

IList<T>: implemented by List<T> and T[] (arrays)

ISet<T>: implemented by HashSet<T> and SortedSet<T>

IDictionary<T,U>: implemented by Dictionary<T,U>

all implement ICollection<T> and IEnumerable<T>. In the case of dictionary, it implements ICollection<KeyValuePair<T,U>>, IEnumerable<T> (.Keys) and IEnumerable<U> (.Values), etc

It's all basically the same thing. Organized and unified.

IList<T> is actually implemented by a lot of things, and the more general you go, the more things implement it. IEnumerable just allows you to get an iterator that will go through the elements. ICollection adds the ability to add and remove elements. IList further adds indexed access and order. The generic collections and operations on them are one of the best aspects of C# and the standard lib.

Thank you for your correction! I am still suspicious that there is some forgotten weirdness lurking in there, but I'm glad someone didn't let me propagate my mistaken recollections unanswered. :-)

> All are Collections.

Except Map. See the section in the Java Collections API Design FAQ [1] on "Why doesn't Map extend Collection?".

[1] http://docs.oracle.com/javase/8/docs/technotes/guides/collec...

Ha ha, I knew I shouldn't have answered that question. :-)

ASP.NET MVC is very similar to Rails.

They basically took rails, removed active record, dropped in EF, gave it a better templating language, gave it static typing via C#, and threw it into the mix w/ webforms and called it a day. They've been improving it constantly since as well.

Shhh. People don't know that.

> But the .NET platform is one of the worst I've ever worked in.

Then how come is Java 9+ catching up with AOT compilation, value types, making unsafe a public API, reifeid generics and replacing JNI with something more akin to P/Invoke?

They might be referring to the core framework? If that's the case, I completely agree with them: wonderful language, nasty framework.

> nasty framework.

Only for those that never had the pleasure to enjoy enterprise astronaut architects with their DCOM, CORBA and JEE designs.

JEE is not bad, J2EE is bad.

JEE has no comparable .NET framework/library/tools.

Enterprise astronaut architects never stop to surprise me.

Ditto with cowboy coders.. hacked-up solutions, allegedly "MVP", lean/mean stack that hits the ceiling pretty fast that begs for re-write.

I guess I've hit a sore point.

"enterprise architect" here. Yes you just stamped on a lot of our toes and rightly so. There is a lot of batshit out there which is what you've most likely experienced. There are a few of us working to destroy this batshit without sacrificing the ultimate goal of building something that isn't a bag of rats though, so please don't tar and feather us all.

For ref, I don't use PowerPoint, I do write (a fuck load of) code, don't organise meetings and don't speak in buzzwords. I do however have a thinkpad so that's the only stereotype...

I am an enterprise architect/developer myself.

Hahaha, no I'm just trying to balance it.

The thing is, I've been using JEE stack and toying with Rails as well on the side. I'm amazed how Rails community changed their tone from "Java sucks" to implicitly copying the best practices in Java/JEE world.

So there ya go, my 2c.

Ah ok! I agree that there are those type of developers as well.

Me, I tend to focus on the JVM/.NET/C++ ecosystems at work, and depending on the project types, I do a mix roles of architecture/development.

I don't know, I've never worked in Java.

I've developed in C# professionally since 2002, but also have created endless critical systems with Java, C/C++, and VB6 (yes I said Visual Basic 6...real world programming can be an unholy bitch sometimes.)

I love the current crazy ecosystem of languages out there, but when I need to get shit done...C# is my first choice. I've bet my career on it, and it's paid off nicely.

C# seems to look more like Scala with every release (a good thing), with talk of primary constructors for C# and string interpolation etc.

EDIT: Interesting to see Neal Gafter is involved (See Roslyn mention here: http://www.gafter.com/~neal/), who is rather fond of Scala from what I've read: http://www.infoq.com/articles/neal-gafter-on-java

Primary constructors have been dropped from C# 6 now (https://roslyn.codeplex.com/discussions/568820)

Yep, and I'm pretty sure it's related to a comment(s) that I have made:

http://www.reddit.com/r/csharp/comments/2dc6ge/easier_immuta...

Except that C# is a first class citizen on the platform, not a wannabe replacement for the platform's main language.

This already makes a lot of difference in the tooling that one gets from the platform owner.

Another thing is from the point of view of customers.

With C# I can get all the goodies on customer projects.

With Scala, I can only play with it at home and try to be happy with Java 8 on customer projects.

> "With C# I can get all the goodies on customer projects. "

And F# can cover the rest if needed.

They really just need to let us use C# and F# in the same sln/projects. Then structure can be in C#, nitty gritty implementations in F# and everyone is happy!

>C# seems to look more like Scala with every release

It does, but then that begs the question of "why use c# at all?". C# is still missing (along with F#) scala's most powerful features, and I prefer the JVM and openness of the ecosystem to .NET

The contact I'm on, we're having a lot of success porting away a large C# application to Scala.

What about because many corporations are .NET shops and Scala dropped CLR support?

The reason they dropped CLR support was because there was virtually no interest in it.

When you are a .NET shop with C++, C# and F# at your disposal why invest into Scala?

F# is a remarkably less powerful language than scala. Along with the cost of Visual Studio + windows licenses, the Scala/open source ecosystem is just a better choice.

For corporations, the cost of Visual Studio and Windows licenses is a drop of water in their ocean budget.

There is enterprise software way more expensive than that.

Corporations for which VS/Win licenses don't matter are usually exactly those which don't let developers use F#. So what's your point?

No, I'm pretty sure the reason they dropped CLR support was that there was no good way to get a decent .NET interop story with a language with a substantially different type system than .NET assumes (particularly, with higher-kinded types) given .NETs reified generics.

This is one respect in which .NET's superiority over the JVM as a platform for its core languages (C#/VB.NET on .NET vs. Java on the JVM) made it worse for flexibility. Reified generics are great for implementing languages with a C#-like-type-system, but they limit the power of the type systems you can have.

No.

Your comment might be more useful if you gave a reason or an argument or some data or something...

You also get a step-wise path to rewrite the applications. Going to Scala would probably be a complete re-write which is risky and time consuming. I don't think Scala usage will grow much more now that Java 8 is released. The benefits of rewriting a Java application to Scala is probably not that great in comparison to the cost. And the C# to Scala re-write is probably even worse from a cost/risk perspective.

Well, obviously other people did the math and went ahead with it.

> I don't think Scala usage will grow much more now that Java 8 is released.

I don't get that reasoning. As the GP mentioned, even C# projects migrate, so why would Java's more concise anonymous inner classes be a show-stopper?

>I don't think Scala usage will grow much more now that Java 8 is released

Do you think the main reason people use Scala is because of lambdas and type inference?

I wish there was a tl;dr version as its quite hard to find the time and motivation to sit there and watch something like this for over an hour.

There are slides, which give you a quick synopsis (look under the video)

Thank you - completely missed them :)

TL;DR (slides) https://view.officeapps.live.com/op/view.aspx?src=http%3a%2f...

Although most of the language features have been discussed before. I am excited for null propogation as well as string interpolation. These are will improve the signal to noise ratio and allow for easier to read and write code.

From my experience with C# null checking before method calling or indexing is such a pain and the coffeescript like null propagation is a much needed feature.

They're releasing it under the Apache licence 2? Impressive. That definitely seems like something the Mono project could just utilise directly without any licence concerns.

Xamarin is selling licenses to proprietary gamedevs for quite a while now. That may put a dent in their business.

The mono compiler (that Xamarin uses, and would presumably be replaced by the Roslyn compiler), is released under GPL and MIT X11 licenses (https://github.com/mono/mono/blob/master/LICENSE)

I don't think this will have any effect on Xamarin licenses at all.

I don't see why Microsoft still put resources into Visual Basic.

C++/C#/F#/MSSQL/PowerShell is all they really need to concentrate on.

There are surprisingly big enough number of people who hate curly brackets and adore Begin/End's... unfortunately.. ;)

And there's an even larger number who don't hate curly brackets, but are forced to deal with Begin/End's because the large company they work for is so inertia-bound to VB.

Yes, and I think these people should ask premium bonuses for this.

This might be in jest, but I've seen something close to this. I do a lot of work in C# and a number of years ago I had two different roles approach me to work in VB.NET and it was > 10% premium over the C# equivalent market rate - the megacorps struggled to get people to switch so threw money at anyone with a whiff of interest and talent.

(I said no in-case your wondering).

At my previous employer, I had to use VB.NET and you honestly forget about it after a couple of weeks, especially since both languages are mostly on par today ...

I have to switch between both at my job, and hardly ever notice when I do. Sometimes I'll start to write an If wrong and get squiggly red lines, but that's about it.

Visual Studio is busted for VB.NET - Snippets are unusable. There goes a quarter of your productivity.

It's death by a thousand cuts with VB.Net - You can have namespaces, but oh - VS won't put them in your code automatically like it does for C#. VB.NET also has a mismatch with the .NET framework compared to C# which has "static class" instead of "Module". When forced to use a Module in VB.NET, every function is hoisted into the global scope (and all you wanted to do was make some extension methods).

I use both languages, and like them both just fine. Your complaints are a matter of having a preference for the C# paradigm over the VB one.

Snippets: In what way are snippets unusable? Hold down the Ctrl, then type KX.

Namespaces: VB is sneaky. Right-mouse-click on the project (in the Solution Explorer), select Properties, go into the Application tab. The equivalent to the automatically inserted namespace is the "Root namespace" field.

C# static class vs VB Module: What is the mismatch, exactly? They essentially the same thing (see http://stackoverflow.com/questions/881570/classes-vs-modules...). Members of a Module can still be qualified with the Module name - it's just optional when there's no ambiguity. BTW, "Extension Methods" are available in VB since VS2008 (see http://msdn.microsoft.com/en-us/library/bb384936(v=vs.90).as...).

You're probably also not happy about the case-insensitivity, lack of implicit interface implementation, or the use of keywords over braces to make code blocks, among other things. Whatever, but I use both, and at the end of the day I don't find VB more verbose than C# overall, or C# less friendly.

Each have quirks that make them a mixed blessing. One can easily google on "c# vs vb syntax" and get plenty of articles on the strengths and challenges of each.

> Hold down the Ctrl, then type KX.

You forgot the last step - after you hit those keys you must still type or choose the snippet list. Compare to C# where the workflow is much more streamlined - I just type the name of the snippet and intellisense shows the list of snippets (as I'm typing). Huge difference.

> The equivalent to the automatically inserted namespace is the "Root namespace" field.

No, it's not. If I add a folder in C# (again, where the workflow is much more streamlined) - it automatically becomes a namespace. 99% of the time this is what I want. In VB.NET, when I add a class to a folder, it does not automatically use the folder name as the namespace. Instead, I have to open each file and add the namespace myself.

> Members of a Module can still be qualified with the Module name - it's just optional when there's no ambiguity. BTW, "Extension Methods" are available in VB since VS2008.

There is no concept of a "Module" in the .NET framework. That's a VB.NET thing and that's why I say that C# is more in line with the .NET framework. The framework has static classes, C# has static classes, VB.NET has...no static classes.

I know that VB.NET has extension methods, what I said was that you're forced to put them in a "Module", which means that every extension method now shows up globally. Meanwhile in C#, the more streamlined language, things work the way you'd expect: Extension methods only show up on the class-instances that you're extending.

> Each have quirks that make them a mixed blessing.

Right, but one has way more quirks. One of them adds a layer on top of the .NET framework that invents concepts that don't exist in .NET and one has more complexity and kruft than the other. That one is VB.NET.

One more example for the road: In C#, when I have my cursor on a method and I hit F12/Go to definition...I am taken to the actual definition of the code where I can see attributes on the method as well as the actual declaration. Do the same in VB.NET and it takes you to the Object Browser where you can't see any of that. So yeah - I'm sticking with my conclusion that Visual Studio is busted for VB.NET.

In BASIC there is no Begin.

Because they still have lots of "partners" that give them lots of money that develop VB.NET line-of-business (LOB) applications.

There is a fantastic 2010 blogpost[1] from the Visual Studio Languages Product Manager that explains the rationale for supporting VB.NET as well as C#, as well as the strategy for doing so.

Of interest: he states that both languages have (had?) "roughly equal adoption".

[1] http://blogs.msdn.com/b/scottwil/archive/2010/03/09/vb-and-c...

Even worse, they refuse to put a lot of resources into F#, which C# is only starting to catch up to. Even if MS just said F# was first class and on par with C# it'd make a huge impact. But they're too something, I dunno what, to admit that publicly and tell users it's OK to move. So F#, despite being a superior approach for essentially every user, keeps its niche status.

There are legions of VB programmers out there, you just don't hear from them. The ones I worked with a decade ago were not the types to wind up on HN, to read programming blogs, or to engage with the wider programming community. They were only really interested in programming to the extent that they used it to do a job (they were "Morts" [1]).

Mind you I don't think there's anything wrong with that as an attitude. Anyway, Microsoft puts resources into it because they probably have zillions of paying customers using it.

[1] https://web.archive.org/web/20080218051638/http://www.nikhil...

I am still a Classic Visual BASIC (VB 6.0) programmer.

Microsoft made it so VB 6.0 needed the Microsoft Java Runtime to install and it works with Windows 95 to XP, but in Vista and above it has problems installing. There are ways you can trick it to install but in the long run it is not worth it as it causes OS instability.

I got an XP Pro Virtual Machine in Virtualbox that I develop VB 6.0 apps inside of. GIT only works with XP and up, so Windows 2000 and under are out of the question. (Something about IPV6 support in the Git app and the first Windows to support that was XP so it fails in earlier Windows) So if you want to do legacy Windows programming and use Git, XP is your best choice. Visual Sourcesafe never seemed to work properly and I always had coworkers and management get in and scramble the files by accessing them directly on the NT Server or whatever and load them in MS-Word or MS-Frontpage that changed the formatting and then they saved bypassing source control. At least in Visual Sourcesafe 6 this was true, and I believe that Git is much better.

Since 1983 I have learned over 37 different programming languages on many different platforms. I only did Visual BASIC programming from 1995-2002 because in my area the IT shops were Microsoft shops and management decided to use Visual BASIC. While I knew Non-Microsoft languages, management never wanted me to use them.

I ended up on disability in 2003, and by that time Visual BASIC evolved into VB.Net influenced by Java and took a turn for the worse. Then Visual C# got used because it is more like Java than VB.Net is, and the high schools and colleges teach C# and Java so these new programmers learn it.

In high school I learned Pascal, in college I learned Pre-ANSI C, COBOL, FORTRAN, Ada, X86 Assembly, and others.\

Around 1995 I was learning Java and JavaScript. Then later Python and a few others. But on my spare time at home, because my managers didn't want me to use them.

I just recently took a Ruby on Rails MOOC and passed it with 100% on each programming assignment. I used to do VBScript ASP 3.0 programming. ASP.Net changed all of that apparently.

So yes I am one of the legions of VB programmers out there, got forced into disability, too old to work in my 40s (They only want young people), and read Hacker News because my interests are scattered all over the place in learning stuff.

The die hard Visual BASIC only programmers were the ones I had a coworkers who I had to hand-hold and teach Visual BASIC to them. Most earned university degrees but had no idea how to program. They secret handshaked their way to a job, while I had to pass tests and show code. I super debugged their code, and their code was sloppy and crashed systems and servers. They moved on without me into the Dotnet era and Visual C# and stick to Microsoft websites for their news using Bing as a search engine. They find me on social networks and ask me to apply for my old job so I could help them, but I cannot go back, I can only go forward. Work on my side-projects and do it as a hobby until I can get off disability one day.

I second that that C# and the .NET platform are a joy to work with. If you've never given them a shot, you may be pleasantly surprised.

This is all very nice, but what would make me truly excited is if they released their runtime for linux ... yeah, it's just a dream. would be a lot of work I expect and they wouldn't want to even if it was easy.

Well, Mono exists. At this point porting to Linux would just be duplicating a large amount of Mono.

Yes, I use it extensively and it's good. But the Microsoft runtime is awesome. Much faster and very stable. I do a lot of number crunching (distributed on a small cluster) and don't want to use Windows in this scenario for various reasons. Mono is good enough that I choose to compromise, but MS runtime on linux would be a dream come true.

If they genuinely open source Roslyn, then that could happen. The tricky bit would be porting the very Windows-specific OS features (overlapped IO, System.Windows.Forms)

It is? https://roslyn.codeplex.com

Roslyn is not the runtime, it is the compiler which emits IL code. Its different from the runtime.

This.

It'd be amazing if there was an official and well supported Linux port of .NET. Just imagine having C#, F# and .NET libs available in a Linux environment and talking to Linux tools.

They are working on .NET Native which does some of that. http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing...

I had use VC and VB a long time (15+ years) ago and have since moved to Linux + gcc, python, golang, mobile etc.

After watching this video for 20 minutes of all the fancy GUI details, I have couple of higher level questions:

   1) Do C#/VB still only build for Windows, Win Mobile? 
      Can they build targets for IOS, Android, Linux? 
      I heard the new CEO of MSFT suppose to be more supportive of cross platforms.   


   2) I began to like the concurrency model in golang a lot.   
     Does the C#, VB support that kind of concurrency in their language design?

1 - Mono still works well and Rosyln compiles and runs in Mono.

2 - Not at a syntax level, but there is good concurrency support in the .NET stack.

"Concurrency" at syntax level is kind of dumb anyway.

The way golang works seems to be follow the model of Unix pipe (stdio pipe) between process. They are simple channel between go-routines (kind of) light weight threads.

The concept is built into the language itself.

Anything wrong with that?

Yeah. Goroutines not backed by real threads (afaik there's also gorountine -> os thread), those "green" threads from Ruby and fibers are just ugly hacks.

Sorry but from my point of view, "real" concurrency is done at the OS level. The OS schedules threads to the CPU depending on their priority and "other" things. Having a single OS thread and runtime code that "yields" so another piece of code can run in the same thread, that's not concurrency...that's a toy.

Sorry for being so blunt.....but that's my opinion.

At least initially, the gccgo compiler implemented goroutines as OS native threads and am wanting to say it still does.

Switching goroutines is much lighter than switching OS threads. When this "toy" and "hack" becomes as heavy or slow and thus no more useful than OS threads, then you can make a point. As I see it, you aren't making a point right now, just explaining what OS threads do and calling goroutines names. So let me point in the direction of an explanation of what goroutines do: http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_Desh...

Here is a recent C#/.NET experience that I had: Some of my time is spent profiling/sampling/optimizing the pipeline at work. I decided to take a stab at a C#/.NET tool that is executed quite a lot throughout the day, only to find out some unexpected things - all variables in a functions would be initialized to defaults (used or not, covered or not)... So splitting large functions into smaller would (actually) help in this case for sure:

https://gist.github.com/malkia/ebf7f54063c5aec6d1b0

Some answers from Eric Lippert about it (declaration spaces) http://blogs.msdn.com/b/ericlippert/archive/tags/declaration...

And this stackoverflow: http://stackoverflow.com/questions/2976628/question-on-c-sha...

It's not something I've seen in other languages/vm's. And seems like "ngen install" with some attributes would help it:

  [MethodImpl(MethodImplOptions.AggressiveInlining)] 
  static int func1(int flag)

But I'm no longer able to think of C# as closer (not close) to the metal, because of this exactly. It'll affect me how I look at it and code in it.

The main problem is the GUI Windows Forms that Visual Studio uses that they won't allow for use on other operating systems other than Windows.

If they included libraries that could compile the Windows GUI Forms to other operating systems like GNU/Linux, *BSD Unix, iOS, Android, Mac OSX ect it would be used more for those platforms.

Instead you have an incompatibility and it prevents developers on Non-Windows platforms to take it seriously. How can you claim it is cross platform when the GUI parts won't even compile?

Visual BASIC 6.0 was the last version of Visual BASIC that didn't stink and add in a bunch of Java features. I consider it Classic Visual BASIC for version 6.0 and under.

This Visual BASIC is really VB.Net and not Classic Visual BASIC. I'd much rather use the BASIC based Jabaco http://www.jabaco.org/ to make Java Bytecode JAR files than use VB.Net to make binaries. At least the Java JAR files are cross platform better than VB.Net and C#.

There is another BASIC that compiles to Java and is more actively developed than Jabaco :B4J http://www.basic4ppc.com/android/b4j.html

Also for cross-platform development there are even dialects that compile to HTML+JS: http://pewtersoftware.com/browserbasic/

And other platforms: http://www.monkey-x.com

Thank you I'll look into them.

Monkey-X looks like Blitz BASIC rather than Visual BASIC. But I like the fact that it can go cross platform.

What's the use case for a getter-only auto property? I can't imagine how that would work, does someone have any insight?

edit: is it "same as a public readonly field, but it's a property"?

Databinding in WPF when you're not using INPC

I often write stuff like this:

public RxProperty<bool> IsFoo{get;private set;}

I could do without the private set.

Are you saying that it's going to be equivalent to a non-private getter, private setter automatic property as it is now?

It's not equivalent. The getter-only auto-property will not have any setter at all. Previously, it had to have at least a private setter, which means that you couldn't strictly guarantee that it wasn't being updated. I used to write read-only properties the long way just to guarantee that they were actually read-only.

Because a property is actually a method, so other, internal state could change what the property returns. Think of something like an "IsConnectionOpen" flag. The class' internals may change it as if it is not readonly, but to the consuming code, the IsConnectionOpen property should appear readonly.

That's clear - but that's not the case presented in the slides...

"Automatic" is clear, "getter-only" is clear, but "automatic getter-only" leaves me scratching my head.

Do you know where it is in the video? Are they not talking about something like this?

    public bool IsOpen{get; private set;}
    public void Open(){
        try{
            // do some complex work
            this.IsOpen = true;
        }
        catch{
            this.IsOpen = false;
        }
    }
    public void Close(){
        // do some other work
        this.IsOpen = false;
    }

Not sure about the minute, the video is prohibitively long...

It's on the 9th slide: https://view.officeapps.live.com/op/view.aspx?src=http%3a%2f...

I see. Maybe they mean "implicit private set"? Otherwise, one of the sibling comments has a good point about the binary compatibility issues with fields vs properties.

Yeah, it must be initialized in the constructor.

Similar to the JVM, the CLR can offer binary compatibility of libraries, which is something Microsoft cares a great deal about. Changing a public readonly field in to a public readonly property is source-compatible, but not binary-compatible. That's why properties are generally preferred, even when you don't strictly need one. The language was actively discouraging either immutability or binary-compatibility by making it more verbose to get a trivial readonly property.

Ah, that's the catch, it makes sense now.

A getter-only property can only be set on initialization of the class, so either with a fixed value or one from a constructor. That does make it the equivalent of a read-only field, but it's a lot easier to keep byte-level parity with future versions.

In its simplest form, it means you can do this:

    public property Foo { get; } = 5;

Your class now has a Foo property that nobody can set, not even methods in the class itself, but that can be publicly read.

These become a lot more useful with primary constructors (also a new C# 6 feature):

    public class MyImmutableClass(int usersFoo) {

        public property Foo { get; } = usersFoo;

    }

This will create a constructor on the class that takes the usersFoo argument, and immediately assign the value of that argument to your read-only automatic property. It makes immutable classes a lot easier to create, and guarantees that they'll stay immutable.

edit: Permit made it clear that primary contructors have been dropped from the C# 6 spec. You'll just have to assign your readonly properties from regular constructors then :)

Internally, .Net automatic properties are compiled with a backing field and a getter and setter method. In the case of a read-only auto property, they will omit the setter, so there is no public artifact that could be abused.

A bit messy, but an overview with code samples can be found at http://msdn.microsoft.com/en-us/magazine/dn683793.aspx

>These become a lot more useful with primary constructors (also a new C# 6 feature):

Primary constructors have been removed: https://roslyn.codeplex.com/discussions/568820

Aha I must have missed that news. I'll update my comment. Can't say I'm sad to see them go, they were useful but turn a complicated class into a clusterfuck.

thanks!

C# is neat and I used it as my primary language for a good 6 years from 1999 to 2005, and then a little bit since they -- maintaining legacy projects. But a platform specific language it isn't the future in my opinion, it is just too limiting. Python, JavaScript and other types of cross platform languages, even if slower and sometimes more annoying to debug, is where the money and the future is.

JavaScript, yes. Python? Python isn't particularly popular and there aren't many Python jobs around. It also isn't a particularly popular language on any platform but Linux (so while technically cross platform, if few use it on other platforms is that relevant?).

If you've been ignoring other languages to concentrate on Python of all things in the last few years then you have missed the gravy train. Object C, Java, and C are the most popular, and both Java and C are cross-platform (and better still actually used cross-platform unlike Python).

As an aside I see significantly more Java, PHP, and C# jobs than any other language (mostly for web-apps). Then after those I see pure mobile development (Java-Android, and Object C).

Python isn't particularly popular and there aren't many Python jobs around.

Where have you been looking? Maybe if you only focus on pure web-dev, but I see Python and Python jobs everywhere. But I will concede that many of those jobs are science, engineering or analysis jobs that primarily involved programming python, rather than pure programming jobs.

It also isn't a particularly popular language on any platform but Linux

That is not my experience at all. Of all the cross platform scripting languages (Perl/Ruby/PHP/Lua/Javascript etc) it is by far the most popular on Windows, and certainly the best supported. I can probably also name a half dozen big commercial Windows apps that use Python as its main scripting language.

> Where have you been looking?

The normal places you'd find developer jobs. I didn't check the Python forums or other Python specific job boards.

> Maybe if you only focus on pure web-dev, but I see Python and Python jobs everywhere.

That's strange. In what industries? Doing what?

I see C engineering jobs, tons of webapp jobs (PHP, C#, Ruby on Rails, etc), Java for all the things, VB.net for business desktop applications, and so on. I cannot think of the last time I ran across a Python job except they're occasionally listed as a "useful skill" in a SysAdmin job advert.

> Of all the cross platform scripting languages (Perl/Ruby/PHP/Lua/Javascript etc) it is by far the most popular on Windows, and certainly the best supported.

I see a decent amount of PHP on Windows and it seems to be very well supported. JavaScript I guess more so but that seems like an odd thing to list in that context.

> That's strange. In what industries? Doing what?

For one, Python is very big in the GIS space. Python is one of the main scripting language for ArcGIS, which is the main software platform that GIS folks use.

Python is rapidly overtaking R as the language of data analysis.

I am in the computer graphics industry and specifically I am usually operating in the visual effects market. Python is the main code used for custom tools in this market by far -- it is the glue that ties things together. The CPU intensive tools are C++ of course, but everything else is often Python.

The reasons: It is cross platform (VFX is a mix of Linux and Windows, leaning more towards Linux at the high end), there are Python integrations for each major desktop 3D editing tool, and there is Qt for the GUI. You write one and use in multiple different places.

Python is huge in this market. I guess it may not be elsewhere, but generally if you can use Python for a tool, you do. It avoids the pain of C++, which is really horrible across distributions and OSes.

According to IEEE, Python is nearly as popular as C#, 5th overall. http://spectrum.ieee.org/computing/software/top-10-programmi...

And TechPro rates it #1. http://tech.pro/blog/1885/top-10-programming-languages-to-le...

There are many surveys that may show other rankings, but it is very hard to argue that Python isn't popular.

I really like working with C#, .NET and the Microsoft platform in general because I don't have to cobble together my applications and workflows from dozens of questionable open-source tools and components (unless I'm building the front-end for an ASP.NET app!) I also wish building a rich, robust, high-quality web app were as easy as working in WinForms.

It is too limiting though. For now, the web (and native mobile) looks like the future. Although, I don't want the web to be the future because I think that HTML/JS/CSS is a horrible way to build an app. Hopefully a better "web" will come along with some kind of universal runtime. I could totally specialize as an iOS/Android dev and escape the current web, but I'm not a big mobile user - I'm surrounded by huge screens all day and I really don't use my phone much.

These additions are all nice but most of them really aren't more than syntax sugar. What c# really really needs is stricter reference handling of objects, such as const * const in C. Now when you send an object into a library function you don't have the slightest idea what the function will do to your object. Take the simplest case of void Foo(List<string> bar). What will Foo do with bar? 1. Iterate it once and calculate something based on the contents. 2. Iterate it once and store references to all strings in the list. 3. Mutate the list by adding or removing items. 4. Store a reference to the list itself and modify it two days later from another thread causing a race condition because you thought you held the only reference to that list.

Case 3 could be excluded by using ienumerable here but in many other cases its not that simple.

I'm not asking for c++ and manual memory management here, just some kind of constraints on what a function may do with its arguments. I've seen case 4 cause so many bugs its ridiculous, it doesn't even have to involve multi threading before it gets nasty.

Now when you send an object into a library function you don't have the slightest idea what the function will do to your object

There are more languages then C# which tend to have these problems, and for all of them these problems can be avoided in a number of ways merely by applying the typical good practices and well known design patterns. For instance just giving your functions proper names (examples 1. GetLongestString 2. StoreReferencesToAllStrings (still hacky, not sure if there are proper usecases for that?) 3. RemoveDuplicates 4. InstallList or so) and making sure functions do One Thing only will get you a long way in preventing problems. Not saying it is easy, but I've been using C# for at least 5 years and don't really recall problems with it. Did have problems with weak event handlers disappearing due to gc but after learning it it didn't happen again.

Letting NuGet packages inject domain specific tooltips and warnings sounds awesome.

Reply on news.ycombinator.com