Welcome to C# 9.0 (devblogs.microsoft.com)

And I used to primarily work in scripting languages like Ruby where you'd get this 'feature' out of the box (although usually ended up writing a 'Program' class and a constructor/main method anyway for the scoping)

Can you open a text editor and get going with C#? Now you easily can. iPython and python notebooks gained lots of traction from just this type of simplicity.

If you were to write a "script" using the language, doing some things just top level is simple. Very pragmatic. I ALSO like that it's an error to call to any top level functions outside of this, so it keeps this from exploding complexity everywhere.

- declare a namespace for the file (no indentation)

- declare that the file is a class and can only contain one (top level) class (still no indentation)

- `using` statements that don't import every symbol into my namespace :

    using System.Console;
    ...
    Console.WriteLine();

    using Sytem;
    ...
    Console.WriteLine(); // where does "Console" come from ? god/IDE only knows

But alreay with these few changes, I've saved 10% of the 80 columns width. I've made it easy to read a file without an IDE. You can start to write actual code at indentation level 0. I've made it easy to have one class per file and hard to have two class per file, in the spirit of making good pratice easy and bad practice hard.

> 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.

var p = Point(3,5).

For cases like this it's no big deal, but deep/complex initalizers (like expression trees, etc.) look horrible in C# unless you create static helper fn's to init objects.

Personally I think this is a better source: https://octoverse.github.com#top-languages

Or this: https://insights.stackoverflow.com/survey/2019#technology

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.

Many big projects roll out drivers for the JVM (Java/Scala/Kotlin compatible), Python, and Go first. I agree that C# is a 'nicer language' than Java, but at this point, that doesn't make up for the lack of ecosystem.

What .NET still is not really good in, is first party apps. There is no Kafka or Kubernetes programmed in .NET.

The only thing I don't miss is the lack of community. Many things you can get for free in Java/Python cost money in Microsoft land. Even common stuff like decent excel and PDF support. Its getting better but was still the case last time I looked.

What C# needs is Java interop. The VM and bytecode structures are similar enough for it to work. There was a guy maintaining a library for this until recently :(

Official CLR Java interop would kill Java. Within a few years every new project would be in C#.

The only other places I'm aware Java has a big advantage is GC and monitoring. C#'s GC is old school, has long pause times. Makes C# a no-go for many uses. Java also has better monitoring and profiling support.

Now developing in Python at work, I can find a multitude of packages for every need I have to meet, which is perfect for productivity, but I feel I can never understand the language enough because all I do is to import some packages and get work done.

I really hope C# gets more popular among devs. Where I live only large non-tech companies use it internally, which might explain why there are not many open source libraries in C# compared to other languages.

Though, with all the comments here saying C# is turning into F#, I'm tempted to try out F# as my first functional programming language now.

I think that with the latest improvements (from v7 to now) Microsoft is trying to "fill the gap" between F# and C#, and let C# developers embrace functional paradigms (at least, some of) without switching to F# itself.

If it returns null, what's the difference between:

>return foo;

and

>return? foo;

?

if(?foo){return null}

  while (!return? foo) {
    foo = get_foo();
  }

https://devblogs.microsoft.com/dotnet/windows-forms-designer...

Sadly only in Visual Studio and not Visual Studio Code. And yes, there is probably no one who used winforms that wouldn't be shocked by WPFs steep learning curve.

WPF is nice for fully customized UI where you want your application to look modern, but xaml can really be daunting. And it's not only xaml, but that whole MVVM thing can be a nightmare to teach and stick to in a large team and project. Moreover you probably need some designers or an external company to design your UI's to really shine.

I would keep a close eye on MAUI [1] and where it will go. The Model-View-Update (MVU) pattern looks interesting and the cross platform aspect could be really nice.

[1] https://devblogs.microsoft.com/dotnet/introducing-net-multi-...

    var (f, l) = person;

    var (x, y) = point;

    var (first, last) = person;

  var (f, l) = SomeMethodReturningAPerson();

  var person = SomeMethodReturningAPerson();
  var (f, l) = (person.FirstName, person.LastName);

  foreach(var (f, l) in enumerationOfPersons) { ... }

  foreach(var person in enumerationOfPersons)
  {
      var (f, l) = (person.FirstName, person.LastName);
      ...
  }

(the "Person" type would have to implement a "Deconstruct" method with two string out parameters, or alternatively someone could write an equivalent extension method)

Partial application can be one of those write-only code constructs unless used in very simple/canonical patterns. I'd also like to have a Scala like "hole" syntax with positional args -- this is also need to alleviate the need to write a (fun -> ...) when calling methods on object in a |> pipeline. And speaking of pipeline, they look nice, until you want to debug through them. (Need something like Ozcode's LINQ debugger for pipelines.)

F# also (last I checked) doesn't do the level of optimizations I'd like to see, such as removal of tuple creation between fn's when there never actually stored, etc.

Although I understand the rational for the Curried form for fn types, it seems a bit pedantic to present things this way by default -- seeing (int -> string) -> Foo -> (bar list -> baz -> qux) is IMHO harder to look at than the standard presentation. Although C# really needs seq and post-fix types -- "IEnumerable<Foo>" is an eye-sore compared to "Foo seq".

But it's hard to go back to any lang w/o DU's...

Put another way: if I'm going to use these features anyway (hint: now that they're in C#, I am) why wouldn't I do it in the language designed around them, rather than the one where they are bolted on?

When C# didn't have these features, there was ironically more reason to use C# because then these idioms could be argued to not be accepted by the community to the same degree.

https://github.com/dotnet/runtime

https://github.com/PowerShell/PowerShell

My understanding is that structs are not always a good choice depending on the size of the data contained within because they are put on the stack, so having an immutable class record does not necessarily overlap with the use cases for structs.

It seems like records are more of a syntactic sugar which gives you a number of pre-defined behaviours such as value comparison and immutability by default (vs. regular classes).

Mono as a project is a dead man walking. And honestly, that is good. Unity as the major other user is surely heading for .NET 5.

I would suggest to learn to embed .NET Core 3.1 and later .NET 5. Surely possible (see Unity, interop with WinRT etc, ..).