Live data from Hacker News

Welcome to C# 9.0

devblogs.microsoft.com

61–70 of 196 posts

Re: Welcome to C# 9.0

#61
Look - I don't have anything deep to say here. I can only say that between 'records' and 'with-expressions' now in C#, I as a hobbyist F# developer feel like I'm being shaken down by the mafia.

C# designers: "Hey, nice language features you have there. I'll just borrow them for a bit ok, it'll be fine..."

Later, C# programmers: "why would I learn F#, C# does all the same stuff!" (even though it doesn't)

Edit: I admit being both glad that C# is gradually migrating to the ML-style coding which will make F# more mainstream, and nervous that C# will get close enough to kill F# adoption yet too far away to actually get all the benefits of F#.

Some examples of this include the Hindley-Milner type system, partial application, discriminated unions, and all of the compile-time goodness the F# compiler gives and the C# compiler ignores.

Re: Welcome to C# 9.0

#62
post #27

Damn, this is fantastic. One big syntactical thing I should really put in a proposal for is null-conditional returns. Turning if(foo != null) return foo; Into return? foo; It fits perfectly with the existing null coalescing operators and such, while really cleaning up a lot of code.

Better not.

Re: Welcome to C# 9.0

#63
post #10

Well, we're getting closer to F#. Still waiting on discriminated unions and expression blocks. (Yes, I know, discriminated unions in F# are just implemented in the class hierarchy. But it's awfully nice syntactic sugar.) > Point p = new (3, 5); At first glance, not impressive, since you could just do: > var p = new Point(3,5); However, it would clean up code like: > graphics.DrawRectangle(RedBrush, new(3, 5, 2, 2))

> graphics.DrawRectangle(RedBrush, new(3, 5, 2, 2)) > graphics.DrawRectangle(RedBrush, new Point(3, 5, 2, 2)) what's the advantage of the first example? i prefer the second, because i don't have to look at the definition of DrawRectangle in order to know that the second argument is a 'Point' object.

Tooling can show it. Rider will show it for you, I'm sure.

Saves some typing but it also has refactor implications too. If you change the parameter type, it would change the object being constructed.

Re: Welcome to C# 9.0

#64
post #42

Earlier quoted context omitted.

Some languages even have syntax sugar for it built-in, cough Kotlin cough class Foo(b: Bar) : Bar by b

This is the most controversial feature of Kotlin. The delegation is better than inheritance because you don't get all the methods from the base class if you don't need them. At my company, we have banned it, because if you add a method to Bar the method is automatically added to Foo which makes the delegation as fragile as the inheritance.

Go has a similar feature, and while I don't know that I would say it's especially controversial or frowned upon, it's good form to only use it sparingly if at all. I still wouldn't say that it is anywhere near as fragile as inheritance; however--I think inheritance's fragility comes from its polymorphism (not sure about Kotlin, but in Go, the wrapper class/struct can't be passed into a function that expects the component's type).

Re: Welcome to C# 9.0

#65
post #38

Earlier quoted context omitted.

To me C# is the second best designed language, the first being IMHO Kotlin. I'm very interested in what you think would make C# more well designed than the latter :}

May I ask why do you think kotlin is best designed?

It has the benefit of 15 years more hindsight.

As an example, during this time the development community figured out that using immutability as the default brings benefits.

Kotlin is designed with this in mind, but C# isn't - e.g. C# has this cool feature for object initialization which is so handy and all developers use it. Except for - it doesn't work with immutable classes (the ones with readonly fields). As an effect developers dislike to use immutable classes since it's not ergonomic in C# and instead use standard POCO.

Another example is that C# still in this age does not support readonly parameters and local variables (which even Java and JavaScript (!) support). In Kotlin "readonly" local variables is the idiomatic code practice which doesn't make code any more verbose. And in the case they decide to add it to C#, it will have to be at the cost of verbosity (similarly to how Java does it) because of backwards compatibility.

Re: Welcome to C# 9.0

#66
post #42

Earlier quoted context omitted.

Some languages even have syntax sugar for it built-in, cough Kotlin cough class Foo(b: Bar) : Bar by b

This is the most controversial feature of Kotlin. The delegation is better than inheritance because you don't get all the methods from the base class if you don't need them. At my company, we have banned it, because if you add a method to Bar the method is automatically added to Foo which makes the delegation as fragile as the inheritance.

> At my company, we have banned it, because if you add a method to Bar the method is automatically added to Foo which makes the delegation as fragile as the inheritance.

Delegation does not remove the need for interfaces.

Re: Welcome to C# 9.0

#67

Earlier quoted context omitted.

With Kotlin and Scala in existence, that ain’t going to happen. C# is as verbose as it was years ago. After years of Scala collections, eithers, options, why would anybody consider C#. Just look at plumbing with init, data records and with. That is what a case class with val properties in Scala gives. But congratulations to the team on shipping v9.

Because Scala takes mind-boggingly long to compile. Because Scala has so many features that anything has at least 3 different ways to implement it. Because it’s very easy to write unreadable code in scala, not so much in C#. Because Scala uses JVM, while C# has access to .NET (yes this is an advantage for many developers).

What are the last Scala/sbt versions you’ve used? Scala compilation times (and sbt startup times) have improved dramatically over time, it’s reasonably fast now. In the past 3 years, the Scala compiler has gotten literally twice as fast. I don’t have hard numbers for sbt, but it feels like it has improved by much more than that.

For a mid-sized web service (tens of thousands of LOC), a clean compile might take ~30-40 seconds, but you rarely do those. Incremental compiles take more like single-digit seconds, and for most projects you can have a solid “compile on save” type setup that makes it pretty unnoticeable. And sbt itself, which used to be very slow to startup (sometimes 10-20 seconds), now starts up in a couple seconds.

It’s not lightning fast like Go, but it’s way faster than it used to be. Not much of a pain point anymore unless you’re dealing with truly huge projects.

Re: Welcome to C# 9.0

#68
post #61

Look - I don't have anything deep to say here. I can only say that between 'records' and 'with-expressions' now in C#, I as a hobbyist F# developer feel like I'm being shaken down by the mafia. C# designers: "Hey, nice language features you have there. I'll just borrow them for a bit ok, it'll be fine..." Later, C# programmers: "why would I learn F#, C# does all the same stuff!" (even though it doesn't) Edit: I admit…

Well F# obviosly never gained enough momentum and C# has to grow somewhere so why not in this direction. All "big" languages are gaining more and more functional and declarative features each version. I always remember this chat by Simon PJ, the "father" of Haskell about convergence of languages in features https://m.youtube.com/watch?v=iSmkqocn0oQ

Re: Welcome to C# 9.0

#69
post #27

Damn, this is fantastic. One big syntactical thing I should really put in a proposal for is null-conditional returns. Turning if(foo != null) return foo; Into return? foo; It fits perfectly with the existing null coalescing operators and such, while really cleaning up a lot of code.

This look so very prone to cause bugs. Why would you even "return if not null"? I don't think I've been in this situation before. What I do see is if x is null then return something else, but this never

Re: Welcome to C# 9.0

#70
post #17

How does the .NET ecosystem fare these days compared to Java's? Whatever the differences between the languages, on the surface of things it looks like one must be insane not to use Java: https://projects.apache.org/projects.html?language

.NET ecosystem is large, but still windows-centric. If I was choosing between java and C# for a startup, I'd definitely consider C# because it does seem to be a better java (properties and LINQ are the first 2 things that come to mind). But realistically if you're not doing .NET on windows, you're still an early adopter who's going to run into weird issues that you won't have to deal with on java.

> But realistically if you're not doing .NET on windows, you're still an early adopter who's going to run into weird issues that you won't have to deal with on java.

As someone with background from Java but who has worked a lot with .Net Core lately, I guess it might depend on what part of .Net you talk about.

.Net Core worked extremely well on Linux for all use cases I saw, mostly web applications, cli tooling and batch/queue processing. I cannot remember a single case where we had actual problems because of Linux.

In fact, FWIW for small console applications it ran extremely much faster on Linux than on Windows, on the same hardware.

Post reply on HN