Hacker News Reader

Comment by jimmy1 | Hacker News Reader

I really don't see how C# is decent anymore, can someone change my mind? I was all about it in the 2010-2013 days, but over time it just became more bloated and bloated. It's the new C++, where it tries to be everything for everyone.

Every time a new version comes out theres a 500 page tome of all the new features added. Did we really need all those features? I would love it if I saw a new version of a language come out and it removes language features, wouldn't that be a change!

It still has all the annoyances of java (the first thing you see in any C# file is a laundry list of imports), I am not convinced the profiling tooling is better. I will preface this with I am still bitter about the initial .NET core rollout which was a crapshoot and had no parity whatsoever with .NET Framework.

View on HN

You are obviously free to dislike C#, but it seems silly to say they should stop adding features or should remove features.

> Did we really need all those features?

If you don't need them, don't use them. I've found the new features to be great. nameof, string interpolation, property initializers, exception filters, static imports, null propagator. And if you haven't used the language in awhile going back to 5.0 the async await features are fantastic. 7.1 introduced async Main which we've started using in console apps. I use all of these features every day.

> I would love it if I saw a new version of a language come out and it removes language features

Why, exactly?

1. Some people dislike languages with a large instruction set

2. I will propose that programming languages are like anything else created by humans - some parts great, some parts not that great. Furthermore some parts of a language are used more than other parts, it should be hoped that the parts least used in any particular language are parts of that language that are not that great. Given these things it might be reasonable that some time you saw a new version of a language in which they said Feature X really sort of didn't make sense and anyway hardly anyone ever used it so we are removing Feature X. Adjust code accordingly. (probably there should be deprecation stage of a year or so with warnings)

Even human languages aren't not fully used.

There are multiple levels of understanding, regionalisms and specialized technical terms that few get to use.

And that works in language -- its terrible when you are trying to make computers do very specific things in specific scenarios. It leads to hiring nightmares as well. "Oh I write language X in this style, not familiar with your style"

My simple go-to example is tuples. They are on the third attempt to introduce that feature. First was generic Tuple.Create. Did not support naming individual fields. Then came anonymous classes. Those could only be used where type is inferred. The latest are using braces... most powerful, but also syntactically quite different from what came before.

I like C# adding new features, and understand some try-and-see-what-sticks is unavoidable. But I don't understand them not deprecating the old versions. And still wonder if improving an earlier version would have been possible/better.

> Every time a new version comes out theres a 500 page tome of all the new features added.

That's not really true, the list of features in each version is pretty tight and focused:

https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

I just realized maybe op was thinking about .NET release notes? They are lengthier. https://docs.microsoft.com/en-us/dotnet/framework/whats-new

But .NET is a framework that is written in C# and extensively used by C# and not a language.

Agree. I have some beefs with the fragmentation of the framework though. I kind of hope that in the end we will end up with only two frameworks: mono on wasm for clients, and .net core for server/high performance clients.

But what is true is that there starts to be a lot of overlap and inconsistencies between multiple generations of the framework. You have object methods vs generics. You have async/callback methods vs async/await. You have ref/out returning methods vs valuetuple returning functions. etc. The language is starting to show its age even though the .net team has been adding to the syntax sparingly.

"I would love it if I saw a new version of a language come out and it removes language features, wouldn't that be a change!"

"I am still bitter about the initial .NET core rollout which was a crapshoot and had no parity whatsoever with .NET Framework."

Those two statements seem to be in direct contradiction with each other. Would you like iron-clad parity, or would you like to break compatibility in an effort to shed bloat?

C# release notes are very focused and definitely not 500 pages. You can look at the major features per version in a single page and there are now point releases for smaller and faster iterations.

Many changes have also made C# much more productive and expressive by letting you do more with less. Every language has imports but the strong typing and amazing tooling makes it a non-issue. Use VS or Rider and you can type out entire programs in a few minutes without ever worrying about imports.

> I really don't see how C# is decent anymore

How come it was decent once but not anymore? As others said, you are probably exaggerating by saying new version comes with 500 page tome.

However it is a joy for me to program in C#. Super-consistent language. And my favorite feature "LINQ" really gets rid of loops and loops and maybe more nested loops. Interfaces, generics - all great features, decently implemented under the hood.

Calling LINQ a "feature" still feels very off to me. It's a set of library functions with some very strange and, at least in my neck of the woods strongly discouraged, SQL-ish syntax that you can use if you like making it harder to understand what your code is actually doing. The library functions are...fine, to be clear, aside from the inconsistent-for-the-sake-of-inconsistent naming (and I know they want to ape SQL, but 'Select' is a map function, sorry). But...they're library functions. You should expect that stuff to exist in a programming language worth a fart.

C#'s feature changes over the last few years have been marginal. They nibble at the edges while stuff like record classes--an actually and materially valuable thing that significantly improves the writing of immutable and functional code--have been punted for multiple versions now.

C# is Java now, in a way it wasn't when it was younger. It's afraid of change and in being afraid of change has slowed to a crawl. Such is probably the way of most programming languages and ecosystems. But it is a little sad for me to see.

LINQ is pretty basic if you are just using the IEnumerable overloads. It get's more interesting when you use the IQueryable versions of things. LINQ to SQL and Entry Framework provide IQueryable implementations that turn C# code in to SQL. This code snippet demonstrates the C# feature these frameworks relies on:

    using System;
    using System.Linq.Expressions;
    class Program
    {
        static void Main(string[] args)
        {
            Expression<Func<int, int, int>> expr = (a, b) => a + b;
            Console.WriteLine(expr);
            Func<int, int, int> fun = expr.Compile();
            Console.WriteLine(fun(1, 2));
        }
    }

When run, this outputs:

    (a, b) => (a + b)
    3

When a Expression<T> variable is assigned to or a method taking an Expression<T> parameter, the C# code is not translated into MSIL (normal C# is compiled to MSIL). Rather it is translated into an AST. In my example I just compiled it to MSIL, however LINQ-to-SQL and Entity Framework translate the AST to SQL. This macro-like capability is the true power of LINQ. The rest is syntactic sugar (though very delicious sugar).

If I were to try to critique LINQ, it would the normal ORM complaints. Sometimes you have to care about what is going on underneath in the C#-to-SQL translation. Your code may compile, but at runtime the generated SQL might have terrible performance.

You can call it a library, but for LINQ to work at least four major features had to be added to the language or runtime:

-anonymous types -implicitly typed variables -object initializers -lambda expressions

It's interesting that all of these features are very widely used (except maybe for anonymous types) outside of LINQ, but LINQ was the driving force for adding them to the language.

Anonymous types were needed to do the equivalent of "select field1, field2" that are familiar to SQL programmers, or to have intermediate values in a chain of Select/Where/Select operators. Implicitly typed variables (var) were needed to refer to the above types. Object initializers are needed so you could create the anonymous types, and non-anynymous ones too without breaking the LINQ chain. Lambda expressions of course were needed. All of the above are used outside of LINQ.

This was done in 2007. Java got streams and lambda expressions in 2014. JavaScript got it in 2015.

The SQL like syntax - well it exists. I think many people don't realize it's there. Everyone uses the method/lambda syntax.

All true! But, as you note, they're prerequisites for LINQ, not LINQ. Thing is, though? These days, I would say that all four of the features you describe are barely table stakes. Having lambdas made C# cool in 2007, but it's not 2007 anymore and that the four features you listed are probably the important new features I can think of since 2007 is why I like C# a lot less today.

As is probably obvious from my reference to them, I believe that record types would be a contender for "most important new feature"--even moreso than async/await--after spending a lot of time with Kotlin and data classes, it is nearly impossible to go back. C# provides you with the choice of manually-updated boilerplate or mutable objects through your whole stack. That's what has generally kept me away from C# since exposure to first Scala, later Kotlin, and most recently TypeScript. And, while I now work at a C#-first company (not on the C# backend), I don't see a real reason to change that for me personally until they make writing correct code easier.

In many ways, TypeScript seems to me to be a wiser future than what C# is presenting, but that's a whole other kettle of fish.

> Having lambdas made C# cool in 2007, but it's not 2007 anymore and that the four features you listed are probably the important new features I can think of since 2007 is why I like C# a lot less today.

It's not lambdas but expression trees that are the key feature that made LINQ possible. That is pretty unique feature among programming languages. So you might want to reevaluate your opinion about "table stakes features".

Seeing as how every use of expression trees I've ever seen in C# is something like "try in vain to make it so people don't have to understand SQL", perhaps you will forgive me for not being particularly impressed by it.

I view C#'s expression tree stuff as a neat experiment. It's cool. But it doesn't and shouldn't change one's programming life.

Perhaps that's just what you've seen then and not really representative? For example the Roslyn compiler service written in C# uses expression trees to do what it does, and it opens up an entire field of possibilities for meta programming in C#.

> But it doesn't and shouldn't change one's programming life.

What's an example of something that would?

Nice moving the goalpost there (table stakes -> changing one's programming life).

I uh. I don't think any goalposts have moved? When introduced, stuff like lambdas and the libraries that could build on them did do exactly that. But they're table stakes today, in 2018. Where's the movement?

Expression trees, as they are in C#, have never become table stakes and remain pretty unique and advanced language feature. When I and several other commenters pointed that out, you sad something like "yeah, but they don't exactly change programmers life". That's called moving the goalpost.

I mean, if you choose to ungenerously parse it as "table stakes" being the important part of the comment instead of, yanno, that these things that are table stakes are the thing that people actually care about in that whole ball of features, sure?

Hermes Conrad is not aspirational, my guy.

It's not lambda expressions necessary for LINQ but the ability to access the expression tree and translate C# code into other languages (like SQL). There are not many languages with that feature.

I agree with everything you said, except "JavaScript got it in 2015". JavaScript had first-class functions since its inception in 1995 before any of Java or C#, and methods like `array.map()`/`filter()` etc since ES5.1 in 2011, which were already widely used long before the `=>` syntactic sugar was added in 2015.

But those functions only worked on arrays or maybe "array-likes" if you're lucky. Notably, they do not work on lazy enumerables, like LINQ does. And then linq goes farther, and allows them to used on queryable data sources that aren't even enumerable.

JavaScripts stdlib is smaller, C# has a huge stdlib. map/filter on Iterables is just an npm install away, e.g. https://www.npmjs.com/package/iterare

When I mean LINQ, i don't necessarily mean querying SQL. Working, filtering, grouping, selecting from collections in memory works very well. And i don't necessariliy also mean LINQ query syntax, but it can also be method syntax: .Where().Select()...

And the power of ExpressionTrees that allows you to interpret code your own way. For example, substituting SharePoint CSOM library

  .IsPropertyAvailable(string)

with

  IsPropertyAvailable<T>(this T clientObject, Expression<Func<T, object>> propertySelector) [0]

is neat. Instead of magic strings you now have compile-time checking. Now you write

  .IsPropertyAvailable(s => s.ServerRelativeUrl)

instead of

  .IsPropertyAvailable("ServerRelativeUrl")

As for SQL, it may sometimes be a blocker, yes. But EF Core, for example, provides a FromSql method to use for complex queries.

[0]: https://github.com/SharePoint/PnP-Sites-Core/blob/206ee97d4b...

LINQ is not just library functions. It stands for "language integrated query" and is a full data modeling and querying system designed around lambdas and expression trees.

It can be easily translated to other query languages (like SQL) or functional paradigms, and is much more advanced than some map/iterate operators on generic types (which languages like Go dont even have).

The LINQ query syntax (from x in list select x.a) is syntactic just sugar to easily write complex expressions that the compiler turns into the same standard list.Select(x => x.a) method calls.

I promise you that I understand the idea; I have run in .NET circles, particularly Mono, for a long time. It is an interesting goal, but I prefer to stay somewhat in the land of what is--and so I am talking about what is actually done with it in the wild, not what architects blog about. It's map-reduce-fold in the majority case, and when it's not (getting into the IQueryable minefield) I often have found myself going "oh, no."

The weird special-case LINQ syntax appears to have receded and I don't recall seeing it in the wild for some time. Hopefully we can just all agree that was a bad idea and it can get officially deprecated and go away in future versions.

Yeah, I mostly use the methods to do LINQ and rarely use the linq syntax -- but -- it's actually quite powerful and if you have to do a reasonably complex query it's much easier to compose and read in that syntax than the alternative mess of method calls and lambdas.

Umm, the special-case LINQ syntax actually it is nothing special on itself, it just calls those methods anyway. You can actually extend LINQ by providing your own Extension methods for IEnumerable or IQueryable

Right. Which is why it's jarring seeing these blocks of non-idiomatic almost-SQL DSL embedded in otherwise consistent C#. Particularly when you have to materialize a query by calling ToList() or similar - you end up with an extra unsightly mix of query and method syntax with the query wrapped in parentheses. Or else cluttered up with defining intermediate variables that need to be named.

Much better in my opinion to just stick with the fluent method chaining style of using LINQ methods.

You'll never get me to agree. I still use it when I need a `let`.

It’s not, not really, but it runs a lot of enterprise and reschooling developers is really expensive. I know, because we’re in the process of going from almost exclusively c# to mostly node.js and powershell scripts with orchestra and SSIS.

The fact that Microsoft keeps doing things like core 1, the 2, xamarin and now this web assembly stuff made the business case for changing better though. Because staying up to date on c# has also become expensive.

Still, stuff like AD and ADFS, msSQL and windows servers are the backbone in a lot of enterprise, and C# integrates really easily in that environment. I still think node.js, powershell and SSIS does it better, but I can certainly see why c# is still a thing.

I mean.. I really like TypeScript and nodejs as an every language that I can use and promote without too much push back but "Does it better" isn't a qualifier that comes to mind. Sure I can come up with specific areas that I enjoy more about nodejs/TypeScript, but I can also come up with just as many for C#/.Net:

* Async/Await implementation is pretty much superior

* Real threading; great for task pools as well

* Task local storage; something the nodejs community is very interested in but thus far only lives in hacks on obscure run-time features

* Speed?

* Integers?; come on man

* Linq/Entity Framework(though these should mostly be possible to implement in TypeScript now)

If I had my druthers I'd be using F# though, TBH.

I don’t think C# has superior async functionality, it used to, and certainly had for a long time, but not today.

Threading and tasks add unnecessary complexity.

Speed? What speed, this web assembly example is more than 5mb of .net libraries. We make apps for people on less than 3g.

Entity is one of the worst, least productive and most error prone frameworks we’ve ever had in our stack. Especially code first.

Linq almost made us stick with C# forever.

> Entity is one of the worst, least productive

I think that hits the nail on the head; I never got why anyone used that. We never did and we have been using c# for a long time (all over to Core now) and all the horror stories never applied to our work, I think, because we never touched entity.

That's... Odd. I have used a LOT of different ORMs and nothing else came even close to the experience of Entity Framework with its fantastic type inference and Linq integration. Bring your contexts into linqpad and you have one of the most transparent and streamlined ORM development sessions I could possible imagine. This was all with 6 though(IIRC) and code first; not with Entity Framework Core.

There were certainly a couple gotcha's and quirks to get used to, particularly around initial modeling, but the unit of work pattern made possible with task local storage was spot on.

They have some projects to reduce the binary size (it is still an alpha project), like doing tree shaking.

JavaScript isn’t light either, if you look at the amount of stuff a major website loads.

I don’t, I look at what we load.

I'm curious what issues you had with entity framework?

Webassembly is a brand new runtime, it has nothing to do with C#. Blazor is alpha stage and hasn't even finished designing functionality yet.

C# on the server running on .NET Core is one of the fastest web stacks, and the async and threading help greatly with that. You can keep everything synchronous if you want, but it's good to have the flexibility when needed.

How is EF unproductive? What options are better?

.Net core isn’t faster in a way that’s relevant to us. You have to keep in mind that being productive is what’s important when your primary focus is supporting the business.

Whether we gain a little efficiency or not from core is relatively irrelevant if it takes longer to produce the solutions.

We’re not Netflix, our max load is 60.000 concurrent users, and that’s relatively rare.

What isn’t rare, is someone loading an app in a remote area, where the mobile coverage is terrible, and if it had to load .net libraries in that setting, they’d frankly never be able to do their jobs.

So the speed of .net core is irrelevant to us, and to most people really, I mean, Netflix runs on node.

If you don’t know why EF is terrible, I’d wager you’d never used it. We use LinqToSql in our C# apps. Why? Because it’s productive, and again, it may be slower than entity, but it’s slower in a way that really doesn’t matter to us.

I mean, the video highlights it so perfectly when the guy goes “look how fast it compiles”, as if that’s ever useful when your application takes much longer to load for the user.

Sure, use whatever is more productive on the server-side, although in my experience the strong-typing and full classes and namespacing make it much easier than JS.

I don't get the comparison on the client-side with webassembly though. This is an entire UI framework, and hasn't been fully designed and optimized yet, as stated. It's no different than using React and neither would be good options if optimizing for low-bandwidth remote areas.

I've used EF since it was first released, and we haven't encountered any major issues. We migrated from nhibernate a long time ago and fallback to Dapper occasionally for complex SQL and performance. What do use instead? Or is the argument to not use ORMs at all?

GraphQL is strongly typed though, and you can always use typescript, I wouldn’t personally advice it unless it works for you.

We’ve not really seen any real trouble moving to dynamic types, possibly because we utilize stuff like SOLID. When you’re not really using object oriented to its fullest, because it’s fullest adds complexity and complexity costs a lot of money and you’re already pretty fascist in your approach to how responsibility and changes are handled in your systems, dynamic types aren’t really a problem.

If I was building a huge system with a lot of complexity, I wouldn’t pick JavaScript, but I probably wouldn’t chose C# instead of JAVA either. And that’s not the way I would’ve viewed the world 5 years ago.

Anyway, I think people should use what works, I just think C# has lost its usefulness compared to other technologies and I really think web assembly is s terrible move for Microsoft.

But I’d love to be proven wrong.

Parts of Netflix run on node, lots of major back-end infrastructure does not. This isn't even really a nit IMHO, I just feel that's a gross miss-characterization of their system: http://nebula-plugins.github.io/ .

Javascript still doesn't have 64-bit numbers or real multithreading or serious async or proper namespaces and modules.

C# the language is also not the same as the .NET runtime and framework, but Microsoft is the best organization in the world when it comes to backwards compatibility and the C# code you wrote a decade ago will still work flawlessly today.

I don't understand how you're switching to Node.js and shell scripts(?!) to take over all that functionality.

Node.js is better at web apps, and for us it’s been much faster to get stuff out too. The ability to quickly prototype is instrumental when you’re doing service design, and node excels at that.

SSIS is better at moving data.

Powershell has come really far, it’s certainly not C#, but where it really excels is when it’s integrated into our Azure orchestra giving us faster error reporting and making us capable of addressing those errors quicker. It’s also a language that’s shared between developing and operations. So while C# is better technically, powershell is better organizational and that means it’s better.

Simply put C# has become an unnecessary burden, in our setup. I’m not sure I’d use node for huge projects, but our backends are mostly simple frameworks for manipulating relatively small amounts of data.

We’re not leaving .Net or Microsoft, our node server runs behind an IIS with IIS node. SSIS, powershell and Azure are obviously Microsoft. Our entire security model is based around AD and ADFS.

In the newer C# features there is a lot of syntax sugar, and you don't really have to use them. I don't think it is any more bloated than in 2013, and most C# code bases wont look much different to back then.

> I would love it if I saw a new version of a language come out and it removes language features, wouldn't that be a change!

That is exactly .NET Core

That didn't really remove language features though. That removed framework features.

What language features would you like to see removed?

We detached this subthread from https://news.ycombinator.com/item?id=18136654.

C# has a super solid feature set, built up over years of development. When you know C# well you can really lean on it - today I was applying list operators to iterators over the results of database queries that hadn't even been evaluated yet, so that I could apply them just to a specific page of the result set. That's pretty cool - LINQ is a beast combined with the ienumerable/iqueryable interfaces.

C# might have minor drawbacks (ok single inheritance is a pain) but it works better than most languages in its class. The only thing that makes me feel inadequate is seeing some really advanced level Haskell code :o

C# is still very much a decent language, but it's not as shiny as it used to be. I have worked professionally with .NET and C# since the 1.0beta and I have to agree: it's not that good any more. Not because it's gained so much bloat or because it has gotten worse, but because its ecosystem has been fractured so many times I stopped counting. The core ordeal is just the last in a series of disruptions and the previous one was Roslyn. These aren't bad initiatives, it's just that they aren't ready. Roslyn is barely working in VS together with the project system (which is odd given it was shipped first in VS2015)! I applaud ms for developing more in the open, but the constant renaming and churn of everything is tiring.

But all that aside, C# is still decent, the only thing making it less shiny now is that we realized that OO is a promise that didn't deliver. I don't want to program another line without proper algebraic types for example - yet here we are.

I’m not sure who’s downvoting you, but it sure isn’t managers who’s paid for people getting re-educated in asp, then mvc and razor, then web-api, then xamarin, then core 1, then core 2 and that’s just to name a few.

Hell, it’s still not easy for people to deploy a .net core web api and run it in an IIS installed with basic settings. You can laugh at it, but that’s 80% of the damn workforce who doesn’t know how to do that.

I mean, the JS environment changes, but I haven’t had to pay for anyone getting reschooled since we swapped to JS.

Reply on news.ycombinator.com