Hacker News Reader

Comment by Philip-J-Fry | Hacker News Reader

Is it incredible features, or is it more compiler magic that infects codebases and requires a literal language glossary to navigate?

View on HN

I feel it's getting really hard to keep up. They are adding a lot of piecemeal improvements but it seems there is no coherent strategy,

I don't think that's true by and large. C# started purely object-oriented, and it progressively started extending it's usability into functional programming domains (pattern matching, null coalescing, tuples, lambdas), lower-level code (return ref structs, memory spans), and relational programming (LINQ).

So basically, C# is incorporating diverse programming idioms with different strengths from OOP so you can choose the right one for the problem at hand.

In the past they released every three years. Now they release every year. So it is a piecemeal. But there are very strong themes active right now

- simplification for newbies (global usings, top level statements)

- better memory management for performance (ref, readonly, in, value task, custom task providers, ..)

- bring functional structures loved by many (tuples, records, pattern matching, generic math)

- code generation for aot and simplicity (code generators)

- and always productivity (many small things)

In the past we had themes about asynchronity, linq, generics (think also co/contravariance), etc.

I do once a year a training for my fellow engineers. The churn is not too big if you keep up to date once a year and start using it a bit.

A lot of the improvements are just logically extending the language to remove arbitrary restrictions. That's what most of C# 10 and 9 appear to be. So most of the features you wouldn't go out of your way to use, but instead stuff that used to be impossible is now possible. I can't say that I've ever wanted a generic attribute, or a constant interpolated string, but if I did want them, I'd be surprised when they didn't work. C# 8 was the last major new language features.

But a lot of them seem totally arbitrary and inelegant. CallerArgumentExpression requires a lot of attributes. CallerMemberName gives you the name of the caller but not the class name. This is hard to explain. It just seems random.

It's not hard to explain, it's a logical and small extension of other compiler-driven attributes. Just because you don't like it doesn't mean it's a bad change to the language.

Yeah I used to love these releases as a c# developer but now I think they're doing more harm than good. I guess it's my time as a go developer that has changed me.

go development surely affects your taste a lot. This is to me one of the greatest benefit of this language : realizing how much better your code becomes when you spend 90% of your time thinking about the problem and 10% on which language feature you're going to use.

Conversely, for me, trying to write anything in Go is an exercise in frustration: "this could have been so much easier if I could only use X".

The sheer amount of code generators for Go is also a huge red flag.

I just wish go had better json support.

I love the language, but I always end up going back to nodejs for API development because of how ridiculously easy it is to implement json based http APIs.

I'm curious, what is wrong with json support in Go?

I intensely dislike the need to define a rigid type to serialize / deserialize.

And go's libraries and syntax for dealing with dynamic json are pretty painful.

>I intensely dislike the need to define a rigid type to serialize / deserialize.

You can deserialize to a map, without having to define rigid types upfront. But for me, it's more painful to use, because instead of writing something simple like "person.Address.City" with "rigid types", I have to retrieve values by key and cast them to target types.

But pretty much all JSON I have dealt with had an implicit schema, so I see no problem with defining a schema using Go's type system. For me, it's a plus, and defining a type takes, like, 30 seconds? There's also the handy json.RawMessage which you can use to skip certain parts, or defer parsing to a later time.

>And go's libraries and syntax for dealing with dynamic json are pretty painful.

I don't remember having to deal with "dynamic JSON" in an API, can you give an example?

The problem with the typed interfaces are the many cases where the JSON isn't strongly structured, so you end up jumping through all sorts of hoops to make it work, or using a sub-par API like you mentioned, and casting everywhere.

Maybe it's just unavoidable with strong typing, I've had pleasant experiences with C# dynamics with JSON data, but nothing is as easy to me as "let thing = JSON.parse(stringstuff)" and then being able to just do "thing.?someprop" for consumption.

Sure, it only takes 30 secs to add a new type, but the issue is that it has cascading effects. Then build and deploy, etc... whereas with Node, I can just do runtime checks and fail softly.

Sorry, I don't mean to resurrect the old strong vs dynamic typing debate, they each have their use - but for REST APIs specifically I find JSON + dynamic types to be a lot more effective.

Java strikes a sweet spot here.

Reply on news.ycombinator.com