Hacker News Reader

Comment by sedatk | Hacker News Reader

Interesting because I observe the opposite sentiment among .NET developers for features added in C# despite that its backwards compatibility is also fully preserved. They say “the language is getting bloated”, “it becomes harder to learn”. I totally have your perspective on this, but the difference in attitudes is noteworthy.

View on HN

In the past ten years, here's a list of significant feature additions to the Go language itself:

     * Generics

And even that has not been the shocking revolution some people expected; it turns out to overall be a nice little addition rather than something that rewrote what good Go was. Nothing like the Python transition to "new style" classes, or the Python 2 -> 3 transition, or the Python async ecosystem transition, and that's just one language. For the most part a Go 1.4 programmer suddenly transported to today would not find it a terribly difficult task to read code using the generics.

And broadly speaking, the language didn't start with a lot of features either.

Go has had a lot of library improvements, it's had a lot of tooling improvements, but the language itself is extremely stable. I've seen a few people actually complain about Go moving too fast, to which I wonder what exactly would make them happy if even Go is zooming along too quickly for them, because I honestly don't know a language moving more slowly than Go, for all the advantages and all the disadvantages that incurs. I've honestly sort of wished I could sit down with them for 15 minutes and see if I could figure out what their real problem is, or if they really are upset that there was ever a major change.

The biggest problem has been the GOPATH → modules conversion, which broke lots of (or all?) tooling. For example, I had written a fairly nice program to analyse Go code and generate an OpenAPI document, but when modules came around quite a bit of that broke, and it's non-trivial to fix. It still works in "GOPATH mode", but few people use that these days.

I'm curious to learn what sort of issues you've seen when trying to use modules instead of GOPATH? Most of the migrations I've done have been pretty seamless and the few that had issues where all easy to resolve with a few replace directives or similar.

Anyone who has written any tooling that works with Go code saw issues because almost everything changed in this regard. I was maintaining vim-go at the time, and quite a few changes were needed there too. I don't have a list of issues at hand because it's been a while, but generally speaking the only reason things went "pretty seamless" is because people spent time updating the tooling.

C# mostly suffers from having way too many options to do something. The quality of the average codebase written in 10 layer-abstraction-heavy OOP style that does not leverage the language features for writing concise and understandable code does not help either.

This is one of the reasons people rave about F# - it's less about the language and more about not suffering from really bad tradition that has settled over the years.

Don't get me wrong, the situation improves significantly each year, but the developers who require extensive explanatory work to get any semblance of buy-in to stop doing things the painful and cargo-cult-y way are still in the majority.

Otherwise, I think C# is very approachable thanks to it being extremely forgiving language* in general and standard library offering easy-with-pretty-good-defaults shortcut options to do the basics like networking, file io, hashing, creating simple web servers and UI applications, etc. Its both CLI and IDE tooling is also top notch today.

* Forgiving as in, mistakes usually tend to decrease otherwise excellent (better than Go) performance rather than cause critical failures.

> The quality of the average codebase written in 10 layer-abstraction-heavy OOP style

They did not learn from Perl, it seems.

Why do you think Perl is abstraction-heavy?

Perl, itself, isn't but if you let lunatics loose on it for 10 years without adult supervision, you'll end up with people writing their own ORMs, their own object models, etc. and you have a fragile tower of abstractions that you can't even look at for fear of it imploding.

As opposed to Java, C++, ..?

>The quality of the average codebase written in 10 layer-abstraction-heavy

This meme needs to die. I've seen "10 layer abstraction heavy" code base only once

The code was simulating hardware/firmware behaviour when the real impl. was not available, and when the real impl. was delivered, then it was called instead.

So that was quite reasonable why they went with this like that.

Normal apps are mostly MVC-like where controller receives HTTP request (like 5 LoC?),

moves it to some handler which performs business logic / calls db and the returned stuff is either HTML or JSON.

That's your average web app.

The ten layer abstraction continues to exist in Java land. I see it every day at work.

You get a few layers for free by using Spring alone

> This meme needs to die. I've seen "10 layer abstraction heavy" code base only once

I dont think so. I like Go code because its usually pretty "flat" unless you find someone from a Java or C# background. C# code is similar to Java in that nearly everyone writes it with an IDE, so you end up with nested folders like 8 levels deep. it makes reading the code stupidly hard, unless you download and load into an IDE or something like GitHub with essentially a web IDE. so anyone used to just a normal editor like Vim or similar is basically out of luck.

While I agree that almost everyone uses IDEs when doing C#

then I'm not sure about this folder thing.

I've been shocked many times when seeing Java repos that they have like 5 empty folders nested just to have 3 java files. I don't see that in C# world.

>it makes reading the code stupidly hard, unless you download and load into an IDE or something like GitHub with essentially a web IDE. so anyone used to just a normal editor like Vim or similar is basically out of luck.

What does "normal editor" even mean?

Shouldn't "normal" be dictated by market share? so VS Code, Notepad++ according to SO Survey 22

> that they have like 5 empty folders nested just to have 3 java files. I don't see that in C# world.

This is because Java ties the package path to the filesystem, and C# does not tie namespaces to file paths. Typically in C# codebases you'll see the layers implemented as separate DLL projects.

That's not my experience, and I've been writing C# since .NET 1.1. Obviously though it depends on the scale of the app. If you have 1m+ LoC, you really need to have some sort of structure, regardless of the language.

Well I guess you've just been very lucky.

I've seen a codebase where half the features were implemented by inheriting the controller class and adding some behaviour and then that wqs wrapped in another layer adding more behavior. It had about 5-6 layers of that. I guess it's not 10 layers, but it was still extremely shitty code that was very not fun to deal with.

Which are valid fears -- C# has become a language with an insanely big surface area, almost comparable to C++'s. This surface area will get rough, unforeseen edges when multiple different features are used together (no matter how generally good C#'s design is), so on the end-user dev it is not even a linear-only weight to learn.

Java is a common butt of jokes among C# devs, but in my opinion its addition of features to the language while committing to backwards compatibility is simply the best in the industry and should be copied by every language pertaining to a similar status (not for research languages obviously, they should be the ones experimenting) -- they seldom add new features, only those that have been proven by others and trying to kill multiple birds with a single stone in each case.

Also, .NET does have a dubious past regarding backwards comp. from what I gathered, "its" frontend churn alone is remarkable, the only thing more spectacular is their renamings.

> Java is a common butt of jokes among C# devs....

And those of us Polyglot devs, have positive and negative arguments that go both ways.

Indeed, both languages have plenty positives and quite a few warts as well. While I do prefer Java personally, I consider C# an absolutely fine choice for almost every usecase.

Go on the other hand, I'm much less forgiving about.

C# is getting some strange design decisions of lately, see inline arrays, and interceptors.

Yeah, they had plenty of hindsight, and still....

Why are they strange? Interceptors seem to enable migration away from reflection, for better support of AOT compilation.

For example: https://github.com/DapperLib/Dapper/issues/1909

Interceptors are a hack, instead of a properly designed AOP framework, which Microsoft already has, although comes with Visual Studio Enterprise price tag, Microsoft Fakes.

Inline arrays are another hack, instead of properly designed language grammar, like in languages like D or Swift.

C# interceptors are a metaprogramming feature. AOP is a higher-level concept. An implementation of AOP can use these metaprogramming features to achieve aspect weaving.

Are a badly implemented, and clunky, metaprogramming feature.

Where a sound AOP framework, or macro system are much more sane.

Belongs to the same trash bucket as the C# 11 bang-bang operator, and I will vote for the same outcome, in all places asking for community feedback.

I lack experience to assess quality of C# interceptors, so that might be true. I'm just happy that C# ecosystem is slowly becoming less dependent on runtime reflection.

Which are both fine?

Which suck both.

I don't see any language advantages of Go if you know C# or Java already.

On the other side we use it for ops because new hire, regardless of what language they know, can learn it in a week or two and produce not-shit code and don't suffer any of the Python or JS problems.

>Java is a common butt of jokes among C# devs

Rarely are "jokes among X devs" for another language not a sign of ignorance and fanboyism.

I've seen this repeated a few times in online forums, but that's not my experience. Language itself has gotten bigger, but code has become much less bloated and elegant. To me, it's easier to read new C# code than the old one.

I'm probably biased as I use C# a lot. But I think that with advent of GPT tools, larger languages have become much less of an issue that they were in the past. They make it really easy to get explanation of code or feature you don't understand right there on the spot.

I haven't used C# in over a decade, but I was already feeling that way - there's just a lot in there. Go seems to start with a default no to things, so that might be why it has a relatively small surface area.

>I observe the opposite sentiment among .NET developers for features added in C# despite that its backwards compatibility is also fully preserved. They say “the language is getting bloated”,

I don't recognize this sentiment at all and I think it's almost non-existent among developers who use ReSharper or Rider that will both introduce useful new language features as a refactoring suggestion that is one shortcut away.

.Net developers can easily get away with not keeping up with new C# language features. A .Net developer who went into coma in 2012 after having learned async/await and ASP.NET MVC can return to a hypermodern ASP.NET Core 7 codebase and be almost instantly productive.

Reply on news.ycombinator.com